Agile and Scrum have come a long way towards improving time-to-market but is it possible that we can make our typical agile techniques even more lean?
There is a common training game in the agile community called the “penny game”. In the penny game, you have 4 players lined up and their jobs are to flip pennies and hand them off to the next person in line. In the first round, the first player must flip 20 pennies all to heads before passing the entire batch to the next player who then flips them all to tails and so on. You can measure how long it takes to deliver the first penny and last penny all the way to the end of the line.
If you have ever played the penny game, you have seen how it takes much less time to deliver the pennies to market, as transfer batch size decreases. In other words, working in batches of 20 pennies will be significantly slower than working in batches of 10 pennies, which in turn is slower than flipping in batches of 5, and so on. As we move closer and closer to continuous flow, we get faster and faster in our delivery.
In the software development world, we have traditionally been operating in large transfer batch sizes where we analyze all of the requirements for an entire system before handing the entire batch over to development where we then write all of the code and then hand that huge batch of code over to testing, etc. As the penny game teaches us, this is the slowest method of delivery.
In the agile community, we focus on decreasing that batch size down to just a few weeks worth of work at a time and by reducing the batch size, we greatly improve time to market. It is common in Scrum to focus on batch sizes of 2 – 4 weeks worth of work that is organized into time-boxed iterations. At the end of each iteration we stop the line and re-plan for the next batch delivery. For many organizations, this results in huge improvements in time-to-market. But what next? Once teams have reached the benefits of scrum, where do they go next?
In Scrum, Batch Sizes Can Be Further Reduced for Faster Delivery
Organizations that have successfully used short iterations may be ready to take the next step. As we move closer to a batch size of 1 and closer to a state of continuous flow, our time-to-market will improve yet again. This is where “scrum-ban” comes in. The word scrum-ban comes from the Japanese word “kanban” combined with Scrum. In Scrum-ban, we move even closer to the ideal:
- We do not need to stop the production line every 2-4 weeks for rigorous re-planning of the upcoming iteration. As work requests come in, we prioritize them, give them very rough estimates in real-time, and then put them into the queue at their appropriate point in the backlog. When the team finishes a piece of work, they pull the next highest priority item from the backlog and focus on delivering it.
- There is no need for iterations with batch sizes of 2-4 weeks worth of work. In scrum-ban, we aim towards continuous flow and continuous delivery.
- In Scrum, we put significant emphasis on estimation because we need to commit to a batch of work that will fit into the 2-4 week iteration boundary. In scrum-ban, we have no such artificial boundaries so we can reduce the effort required to create estimates even further.
This article just touches on the ScrumBan concept, and putting the concept to work is non-trivial, but even with this short introduction I think that you can see that we can make another leap in productivity and speed to market by moving towards even smaller batch sizes, reducing the need for time spent on estimation, and eliminating the need to stop the production line for iteration planning.
