Flow. Discover Problems and Waste in Kanban
You Kanbanized your development process and setup a perfect flow. You see the flow and feel its power. You even measure cycle time and want to reduce it. But it is not as easy as expected. Some problems in your development process are hard to find and are revealed on team level. Here I’ll describe an interesting technique that may help you.
The idea is quite simple. Take a single user story and visualize its states transition from start to finish, thus you see the whole flow of a single story. Draw all available states on Y-axis and days on X-axis. As a result, you will have a chart like this.It is a real user story from TargetProcess project. It was quite complex and its cycle time was 19 days. Let me provide some comments.
User story has been in Planned state during just 1 day, then developers took it and moved to In Progress state. So far so good. 4 days of development and user story is moved to Coded state, but it sits there for 2 days. Why? Why testers did not take it immediately? Clearly, we found 2 days of delay and the reason of the delay should be investigated, since it increases story cycle time.
Then testers took the user story and tested it for 2 days. Then the story was moved to In Progress state again and developers worked on it for 2 more days (including Saturday). Why? It is a half of the initial development time. It is a clear sign of a waste, but we need more details. It appeared, that testers found 11 bugs. Half of the bugs were caused by unclear user story specification, other are subject to investigate. We should apply root-cause analysis here to find the real problems.
OK. Then testers have verified the user story for 2 days and moved it to Ready to Merge state. It was merged quite fast (in 1 day), but still there may be a waste to eliminate. Finally, the user story have lived in Merged state for 5 days and was released Jan-29.
In total (and as a minimum!) we discovered about 9 days of waste. It means we can reduce cycle time significantly by eliminating this wait time (waste). If you check several user stories using this technique, I believe you will find comparable results for simple and complex stories.
Here is another example for a quite simple user story. Still we
clearly see wait times in our flow! We can reduce cycle time to 2
days instead of 6 by just eliminating waits in the flow. But
it is not easy 
This chart is a really powerful tool. It is easy to create and you could
use it to find waste in the development flow.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Neil Watson replied on Tue, 2010/02/02 - 10:51am
If you would like an alternative approach, have a look at Eliyahu Goldratt's books, especially "The Goal" then "Critical Chain". Neither match software development exactly, but the principles apply.
Sindy Loreal replied on Sat, 2012/02/25 - 10:16am
Theirs is no context at all. It could be, that the user story was amazingly fast developed? Or very slow? Why is development and testing decoupled at all? At our shop we believe testing and development should be happen parallel.
To call delays as waste days, is a little bit overstated. I totally believe an measurement of software processes and effectiveness and Kanban is nice but "Wait time, waste, and a value stream" are interesting metrics, but as many metrics don't provide much value without context, culture and "soft" goals.