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?
You can actually see sprints as mini-Waterfalls. But the point is to fail and learn from it. I am sorry you had no Scrum Master with responsibility.
Not finished on Friday? So be it! Find out why and try a solution. You had distractions, complexities during the sprint: reduce them!
You planned wrong: why? Were you forced to, by people outside of your team? Put the decision making back to the team, where it belongs. Nobody else.
Embarrassment at the review? Don’t cover it up because no one will learn from it. Dont fix something in secret over the weekend. Someone will not notice something was ever wrong.
I started doing Scrum more than 15 years ago and I’ve worked on teams with full-time Scrum masters / project managers where the team genuinely did want to make the process work, but I have yet to be on a team where we did Scrum and figured out how to make it run like a well-oiled machine.
I have indeed failed and learned from countless sprints over the years, and the main thing I’ve learned is that time-boxing doesn’t work. I have had success with Kanban / “Scrumban” that dispenses with the time-boxing, but does have planning, pointing, stand-up, retrospectives, backlog grooming, review and demo, etc.
I guess I fundamentally reject the idea that a team should be able to plan and estimate weeks worth of work and if everything doesn’t go according to plan, then you did something wrong and need to figure out how to do better next time. Software development is design, which is always going involve a lot of exploration and learning, not manufacturing, so things not going according to plan is normal because if you’re doing it right, then you’re more knowledgeable today than when you made the plan weeks ago.
With Kanban, if a 3-point story runs into unforeseen issues and you end up spending an extra day, no big deal. Maybe someone will even swarm on it with you. With Scrum, if that happens one or more times, you’re either putting in extra hours or not fulfilling your commitment for the sprint.
The problem is that committing to a fixed scope in a fixed timeframe with a fixed team size is always bad idea, and Scrum makes an entire process out of this bad practice. It’s an improvement compared to full-on waterfall, but it’s still a flawed process, and getting rid of the time-boxing makes all the difference in my experience.
I guess I fundamentally reject the idea that a team should be able to plan and estimate weeks worth of work and if everything doesn’t go according to plan, then you did something wrong and need to figure out how to do better next time.
And you wouldn’t even disagree with scrum here. Whoever taught that, misinterpreted the scrum guide. You don’t need to figure everything out. See scrum as an instrument that shows you a result, nothing more. You as a team interpret the result as you like. If you see no problem in the result, fine. Nothing to do, move on.
The way you say it sounds like someone put disappointment or bad energy into ‘failing’ a sprint.
The point of scrum is that you can not plan perfectly and expect funny results. A good SM might ask: “do you see this as a problem?” and let the team decide.
Scrum actually doesn’t even mind spill over or unfinished work, etc. At the end of the sprint we check out the outcome and then talk about the next opportunities. Half finished work is no problem and not even mentioned in the scrum guide. If there was disappointment or bad feelings about it, then some one among you did that on their own. As a team you can literally decide that you don’t mind spill over from sprint to sprint because you see no problem in it and move on without worry.
estimate weeks
In my opinion, time estimations are a distraction to everyone involved and never work. I’d recommend to estimate in complexities. To talk about them. Nothing else.
The problem is that committing to a fixed scope in a fixed timeframe with a fixed team size is always bad idea and Scrum makes an entire process out of this bad practice.
Again, misinterpretation. The sprint length is just for consistency, like planning meetings is easier that way. And measuring is easier too.
Scrum even allows you to renegotiate the scope dureing the sprint. It even says that in the scrum guide…
That’s fair, and having no consequences for unfinished work certainly takes the pressure off, though you’re correct that I’ve been on teams where there certainly were consequences for not getting done what you “committed to” for the sprint, which really made me resent the process. I’ve also been on teams where we happily moved unfinished work over each sprint, and it largely felt like we were just going through the motions. To your point, I suppose the latter is perfectly acceptable, though it felt wrong based on my previous experiences. In either case, I always wonder what the point is of time-boxing in the first place when you can just take it one backlog item at a time with Kanban while still engaging in the other useful practices.
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
the mini waterfall is kind of the intention of a sprint. The whole idea is to reduce the huge waterfall and its horrible surprises at the end when it is way too late. Have those surprises early by doing small waterfalls. But everybody is splitting it wrong so all the small waterfalls have no outcome until the whole thing is done, just like you do without sprints.
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?
You can actually see sprints as mini-Waterfalls. But the point is to fail and learn from it. I am sorry you had no Scrum Master with responsibility. Not finished on Friday? So be it! Find out why and try a solution. You had distractions, complexities during the sprint: reduce them! You planned wrong: why? Were you forced to, by people outside of your team? Put the decision making back to the team, where it belongs. Nobody else.
Embarrassment at the review? Don’t cover it up because no one will learn from it. Dont fix something in secret over the weekend. Someone will not notice something was ever wrong.
I started doing Scrum more than 15 years ago and I’ve worked on teams with full-time Scrum masters / project managers where the team genuinely did want to make the process work, but I have yet to be on a team where we did Scrum and figured out how to make it run like a well-oiled machine.
I have indeed failed and learned from countless sprints over the years, and the main thing I’ve learned is that time-boxing doesn’t work. I have had success with Kanban / “Scrumban” that dispenses with the time-boxing, but does have planning, pointing, stand-up, retrospectives, backlog grooming, review and demo, etc.
I guess I fundamentally reject the idea that a team should be able to plan and estimate weeks worth of work and if everything doesn’t go according to plan, then you did something wrong and need to figure out how to do better next time. Software development is design, which is always going involve a lot of exploration and learning, not manufacturing, so things not going according to plan is normal because if you’re doing it right, then you’re more knowledgeable today than when you made the plan weeks ago.
With Kanban, if a 3-point story runs into unforeseen issues and you end up spending an extra day, no big deal. Maybe someone will even swarm on it with you. With Scrum, if that happens one or more times, you’re either putting in extra hours or not fulfilling your commitment for the sprint.
The problem is that committing to a fixed scope in a fixed timeframe with a fixed team size is always bad idea, and Scrum makes an entire process out of this bad practice. It’s an improvement compared to full-on waterfall, but it’s still a flawed process, and getting rid of the time-boxing makes all the difference in my experience.
And you wouldn’t even disagree with scrum here. Whoever taught that, misinterpreted the scrum guide. You don’t need to figure everything out. See scrum as an instrument that shows you a result, nothing more. You as a team interpret the result as you like. If you see no problem in the result, fine. Nothing to do, move on.
The way you say it sounds like someone put disappointment or bad energy into ‘failing’ a sprint. The point of scrum is that you can not plan perfectly and expect funny results. A good SM might ask: “do you see this as a problem?” and let the team decide.
Scrum actually doesn’t even mind spill over or unfinished work, etc. At the end of the sprint we check out the outcome and then talk about the next opportunities. Half finished work is no problem and not even mentioned in the scrum guide. If there was disappointment or bad feelings about it, then some one among you did that on their own. As a team you can literally decide that you don’t mind spill over from sprint to sprint because you see no problem in it and move on without worry.
In my opinion, time estimations are a distraction to everyone involved and never work. I’d recommend to estimate in complexities. To talk about them. Nothing else.
Again, misinterpretation. The sprint length is just for consistency, like planning meetings is easier that way. And measuring is easier too. Scrum even allows you to renegotiate the scope dureing the sprint. It even says that in the scrum guide…
That’s fair, and having no consequences for unfinished work certainly takes the pressure off, though you’re correct that I’ve been on teams where there certainly were consequences for not getting done what you “committed to” for the sprint, which really made me resent the process. I’ve also been on teams where we happily moved unfinished work over each sprint, and it largely felt like we were just going through the motions. To your point, I suppose the latter is perfectly acceptable, though it felt wrong based on my previous experiences. In either case, I always wonder what the point is of time-boxing in the first place when you can just take it one backlog item at a time with Kanban while still engaging in the other useful practices.
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
the mini waterfall is kind of the intention of a sprint. The whole idea is to reduce the huge waterfall and its horrible surprises at the end when it is way too late. Have those surprises early by doing small waterfalls. But everybody is splitting it wrong so all the small waterfalls have no outcome until the whole thing is done, just like you do without sprints.