Tag Archives: Cycle_Time

Can we PLEASE have some simple measures for our Product Development group?

Estimated Reading Time: 1 minute

A lot of our clients at AgileSparks ask us how to measure their effectiveness. Some of them are already using Agile styles of product development, others are not yet there, and another important variant is the Enterprise with mixed ways of doing things, that wants to get more visibility, and use measures as a way to drive towards improvement. 

As we all know, we need to be very careful what we measure, and on top of that a lot of measurements require a lot of work – and people don't really like to feel they are working for the measurements. They want the measurements to work for them. 

Be very careful of reports for Management that require the team/production floor to go out of their way. 

Having said that, ever since we started to focus more heavily on Kanban and Lean thinking, a couple of simple KPIs have emerged, with the added attribute that if you're already using Kanban to manage your work, you get most of them for free. 

Chris Hefley, one of the guys behind LeankitKanban, was interviewed recently to SPaMCast 100 (which is a very good podcast, worth listening to), and some of the discussion is around this point of Kanban providing great metrics that don't require any effort other than managing the work. 

I've been presenting these kinds of metrics to a couple of clients lately. Here is my presentation. Notice it mainly references Lean/Kanban concepts but doesn't describe them in detail. Go to www.agilesparks.com/kanban or www.limitedwipsociety.org for references to resources about those concepts. 

Kanban early warning using a predictive variant of SPC

Estimated Reading Time: 2 minutes

A Confession. While I'm a great fan of using SPC charts to explore specific cycle times and reduce variation / continuously improve a Kanban System (a great blog by benjamin mitchell), I'm only seeing preliminary results in the field with teams I'm coaching. The main reasons are lack of tooling, lack of incentive to manually manage this, and the fact that teams are not yet mature enough. I'm hoping this will change in the near future. 

With that in mind, a constant concern I'm hearing is that finding out that there was an exception based on SPC is too late. Why is that? Because a classic SPC looks at final cycle time. And Final by definition means the action is over…

A couple of months ago, I read about "average cycle time in column" in the GSK R&D Case Study by Greg Frazer

A couple of days ago, I had the idea that perhaps using the collected history of cycle times in columns/lanes, a current prediction of final cycle time can be calculated for each card in the system. This prediction can be then traced on an SPC-like chart, and exceptions can be identified more clearly (see illustration below for an example)

This reminds me of charts used to track "Due Date Performance" on releases/milestones, which I saw at one client of ours. I later learned they are called Slip Charts

The main difference is that the SPC Y-axis is by cycle time length. In the Due Date tracking chart, its by actual date. I think its probably sufficient to just rely on the SPC charts. I would urge organizations tracking due date performance on releases and milestones to start doing an SPC at that level, even if they don't use Kanban/Agile at the Feature/Story level. They might learn a few things that can help them bring their process under control, and improve their predictability. 

Back to the predictive SPC – no tool that I'm aware of currently offers this capability, but one can always hope. 
I see capabilities such as identifying struggling work items based on exceptions from "average time in lane" as well as overall exception in predicted cycle time key to taking the "early feedback and action" one step forward, and scaling Kanban to be something project managers swear by. 

If you are aware of any of the Kanban tools that provide this – I'll be happy to hear about it.