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 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.