Why SCRUM Sprints slow you down
I believe that if we want to create software as efficiently & effectively as possible it is about time to move away from SCRUM sprints and look for modern alternatives.
SCRUM Sprints add unnecessary Overhead
Even with tools like sprint velocity and planning poker it is incredibly hard to estimate what can be done during the next sprint. But it isn’t surprising that sprint estimation is such a pain.
Basically SCRUM sprints set you up to commit to something you can’t possibly deliver on. The only way to reach predictable performance in SCRUM sprints is if …
- … your team’s performance doesn’t change ever
No people leaving, no people joining, no knowledge gained over time, no vacations, no motivation highs & lows, … - … the items you are working on are highly predictable
You’ve done them many times, know which problems to expect & how to solve them, no external dependencies, no collaboration with others, no changes in scope even if they would make sense, … - … nothing else comes up that’s more important
Server down, bug in the payment system, a security vulnerability that needs to be closed ASAP, incredible marketing opportunity if implemented & shipped in the next few hours, …
Considering this it is quite obvious why reaching predictable SCRUM sprint performance is almost impossible in most real world situations no matter how much time and effort you put into sprint planning and estimates.
But the main problem is that SCRUM sprints force your team to optimize for predictability (“how much of what we’ve committed to can we get done”) instead of optimizing for value & agility (last responsible moment).
This made me wonder if there are better alternatives and if we can find a way to get rid of the planning overhead.
Modern Software Companies are adopting Continuous Delivery
Fortunately we do have very lightweight alternatives to SCRUM and time-boxed sprints by now.
Some software companies are starting to embrace continuous delivery and feature pipeline visualization tools inspired by lean manufacturing concepts and Kanban.
This helps them to release improved versions of their software as soon as they are ready. On top of that it enables them to drop arbitrary sprint time-boxes if they want to.
By using Kanban and feature pipelines you pull new work items into your process once space (focus) frees up on the board.
This enables you to defer decisions & commitment to the last responsible moment, a time when usually more information & context is available allowing your team to be more agile compared to SCRUM time-boxes.
TiP (Time in Process) Charts
But dropping SCRUM and sprint planning with it doesn’t mean that you have to fly blind. There are easy ways to track performance and to make estimates using historical data even if you ship on a continuous basis.
TiP (Time in Process) Charts help to visualize when a certain feature was shipped and how long it took from inception until completion.
This means that when you want to estimate how long a new feature might take to complete you can have a look at features from the past with similar complexity.
Visualizations like TiP Charts not only save time compared to SCRUM’s planning overhead, they are also a great help for retrospectives and getting a sense of previous accomplishments.
I think it is about time to move away from time-boxed sprints to continuously delivering value. What’s your take on this?
