My last post, On WIP Limits, Velocity and Variability, explained how variability can combine with certain habits and the ignorance of pull systems to create a situation where a Scrum team repeatedly delivers roughly half of their user stories committed to the iteration. This leads to the questions, should they commit to fewer stories, do away with commitment, replace it with forecast, or do something else?
Before we dive into that question, let’s introduce Toyota Kata. Toyota Kata (which is actually a combination of two katas, improvement and coaching) is a systematic technique for discovering improvement opportunities, quickly capitalizing on them, and building the organizational capability to do it. Application of Toyota Kata in the manufacturing sector was documented by Mike Rother in his 2009 book. A trend that emerged in the software/IT Kanban community in 2012 is to adapt the Toyota Kata approach to the knowledge work. Hakan Forss, a Kanban coach from Sweden, experiments, blogs and speaks about it a lot. Yuval Yeret, an Agile and Kanban coach from Israel, writes about it in his book, Holy Land Kanban.
One of the important elements of Toyota Kata is finding the improvement direction, which is usually done with a help of a shared vision. The vision is usually unattainable, like zero defects or a very small batch size that is wildly uneconomical given the current changeover times. However, the unattainable vision helps find the next target condition, which is attainable and lies in the direction of the vision. The improvement then focuses on solving the problems that prevent the system of work from reaching the target condition. This is dramatically different from the “suggestions” method, where the suggestions can lead in various directions from the current condition. Some techniques used to select suggestions, such as voting, can further reduce the problem-solving focus.
Commitment as an Unattainable Vision
The struggling, unlimited-work-in-progress, over-committing, under-delivering Scrum team from the start of this post (and the previous one) could benefit from this approach. While acknowledging that the commitment is unattainable every iteration due to the common-cause variation, they can use it to find the next target condition. The problem-solving then could focus on the real problems – user stories too large to flow well, expanding work, lack of knowledge sharing through pair programming, division of work that prevents thinly sliced stories, etc.
By contrast, replacing the commitment with forecast, or reducing commitment to “velocity” can have the effect of covering up those problems and hindering improvement.