BY| April 8, 2014
As our customers have dug in deeper with their implementation of Kanban systems in a variety of domains– most often IT Ops/ DevOps and software development, but also general business operations, it has become clear to us that they are not just looking at the standard Kanban metrics, they are looking for additional insights to help understand why and how something happened and where they can start to look for improvements.
It is the ‘why’ and ‘how’ and ‘when’ and ‘where’ aspects of these questions that start to make Kanban systems truly interesting as information radiators. So, for example, a standard Average Cycle Time chart in a Kanban system will provide information that the average cycle time of a Kanban system went up or down. But the natural follow up to that from a management point of view are questions such as – why did it go up or down, wherein the system did the delay build up, which stages of the Kanban workflow contribute to the delay or the improvements the most, and so on.
I thought I would take data from our own development team to illustrate some insights that we find very interesting!
A “Lane-wise Average Cycle Time” chart such as the one below helps provide an immediate grasp on which lanes contributed to the change the most. Highlighting the lane types also provides additional input on whether cards spent more or less time waiting or some of the in-progress lanes showed an improvement or degradation. This then helps managers zoom in on those lanes to dig deeper. Comparing this across multiple time periods also provides a visual on whether there is a trend or instability in one or more lane’s cycle time performance!
Another area that we wrote about in a previous blog post – Pareto Analysis of Blocked Cards – is understanding why cards are Blocked on a Kanban board. It is not enough just to understand which are the most frequent blockers – that is a good initial place to start to understand which reason impacted the most number of cards. However, more interesting might be to determine which of them had the most impact on the Cycle Time. So, the data to look for is the total amount of time consumed by various blockers and try and understand how to minimize those blockers that are having the most impact on board delays and elongated Cycle Time. Both of these can be tracked in charts such as the one below.
We did this Blocking Analysis for our own development team – and we found an amazing insight – something that is at the heart of Kanban’s ‘limit your WIP’ and ‘Stop Starting, Start Finishing’ principles! While the number of cards blocked was highest when someone simply put them ‘On Hold’ as you see from the pie-chart on the right, the factor that caused the most amount of lost time was Task Switching (when someone was asked to work on something other than what they were currently working on) or context switching, as you see on the left! While we had suspected this for some time, which is why we decided to track it, having it in front of us so clearly was dramatic.
We have now issued revised guidance of when engineering managers may or may not ask team members to switch tasks – and to developers and testers on how to say no when needed!
As we continue our discussions with our customers, we expect to go after more such insights that provide real business benefits to our customers in meeting their service commitments and help them develop a winning environment for their teams. Stay tuned! (Also, if you have any analytics you would like to see from a Kanban system, do let us know!)
As always, if you like these metrics, please do share this blog post with others!
Cofounder, Sr.VP – Marketing
PS: These and other new insights are available in our just released v3.5.3 of SwiftKanban. If you’d like to learn more, please click here.