Scrum feels like a miniature waterfall. In the worst cases, a sprint is a race to make something that won’t be embarrassing at review and demo on Friday, and then you finish it over the weekend because it’s getting released Monday (with an incident in prod on Tuesday because you had to half-ass some things). Afterwards, the SM is nagging you to enter your actuals in JIRA “so we can track velocity”.
Kanban is better in my experience since it at least does away with arbitrary deadlines, while still encouraging practices like backlog grooming and breaking down work into small units that can be completed in a week or less and then shipped. If you do a group pointing session and the consensus is that it’s going to take more than a few days, you go back and break it down further. If you run into issues with a work item and it takes a little longer than expected, no biggie, because quality is speed, unlike with Scrum where back-to-back sprints would force you to be working in the next thing because you’re now in a new sprint and last sprint’s work should’ve already been done. Didn’t you already show that in review and demo, so why are you still working on it?
Scrum as mini waterfall isn’t supposed to happen, but it usually does. The idea is everyone can help the people will are currently busy
The problem is test and build can’t do much to help the system analysts; the analysts and testers can’t help build because they don’t usually know how to code, so all that happens is everyone tests when build is done
As an analyst I don’t do any testing because I had a bad team leader in a past job as a function tester which soured me on the job, so it’s pretty much mini waterfall to me
Scrum feels like a miniature waterfall. In the worst cases, a sprint is a race to make something that won’t be embarrassing at review and demo on Friday, and then you finish it over the weekend because it’s getting released Monday (with an incident in prod on Tuesday because you had to half-ass some things). Afterwards, the SM is nagging you to enter your actuals in JIRA “so we can track velocity”.
Kanban is better in my experience since it at least does away with arbitrary deadlines, while still encouraging practices like backlog grooming and breaking down work into small units that can be completed in a week or less and then shipped. If you do a group pointing session and the consensus is that it’s going to take more than a few days, you go back and break it down further. If you run into issues with a work item and it takes a little longer than expected, no biggie, because quality is speed, unlike with Scrum where back-to-back sprints would force you to be working in the next thing because you’re now in a new sprint and last sprint’s work should’ve already been done. Didn’t you already show that in review and demo, so why are you still working on it?
Scrum as mini waterfall isn’t supposed to happen, but it usually does. The idea is everyone can help the people will are currently busy
The problem is test and build can’t do much to help the system analysts; the analysts and testers can’t help build because they don’t usually know how to code, so all that happens is everyone tests when build is done
As an analyst I don’t do any testing because I had a bad team leader in a past job as a function tester which soured me on the job, so it’s pretty much mini waterfall to me