There’s a misconception out there that metrics will save us. KPI’s (Key Performance Indicators) are the magical saviors of projects and Teams (and budgets if you ask certain influencers). That’s not really the case. Metrics inform decision making. The question is, who’s doing the deciding? Often it’s the metric that’s the decider, rather than the human. And frankly, “The metric made me do it!” response won’t cut it when things go sideways. (Unless someone’s actually got a way to make that work for them. In which case, I’d like to know the circumstances. Seriously!)
What can make matters worse are metrics that can be a little (or a lot) nebulous in themselves. Take, for example, the case of Lead and Cycle times in Kanban. These two concepts may seem pretty simple, except for a couple of things:
The Origins of Lead Time And Cycle Time
The issue most folks will have when first encountering this subject, is that these two phrases are commonly misused. The “overloaded nomenclature” doesn’t help any either. If you ask Lean Manufacturing people, they’ll give you one view of Lead Time that goes back to the point of a request from the actual end user or customer; until the moment the Product is in the customer’s hands. This thinking harkens back to the earlier days of manufacturing when you literally ordered something, and it was built, for you. Some practitioners will call this “Customer Lead Time,” since it’s the time that passed from the customer’s perspective. This distinction is important because, in this scenario, the customer was for the most part, hands-off.
In the environment I’ve just described, Cycle Time means the time it took to build the thing you ordered. Stated another way, the Cycle Time referred to the time it took the manufacturer’s process to make the actual thing so it could be put into the customer’s hands.
Kanban And Get To Done® Time
Moving forward several decades, with the introduction of the Kanban Method, there’s a more pragmatic approach to viewing Lead Time. Looking at the work coming to any given Team using Kanban, Lead and Cycle Time are effectively the same. It’s the moment when we can commit (or accept) undertaking a Story until that Story is Done.
The reason for this approach is simple. Software isn’t just “a program” today. It’s a system of interconnected, and more than likely interdependent, services. From this perspective, to manage the work more efficiently, it’s necessary to have a simple mechanism to guide delivery of the Stories any Team works on. This is Lead Time/Cycle Time; the time to get a Story to Done.
In the Get To Done tool, there is “Get To Done Time.” Get To Done Time equates to the time from the first commitment point of a Story (accepting the Story, figure 1) to the moment the Story is considered Done (all criteria have been met for delivery of the Story, figure 2) and accepted by the Service Delivery Manager or Team. This is captured on a per Story basis as a “Time to Done” field that’s automatically calculated as the Team uses the tool.
Figure 1
Figure 2
Applying both the Kanban Principle of “Start with what you do now” and Get To Done Time, provides a simple place to start to improve your Team’s delivery. We’ll be talking more about the importance of Get to Done and what it means to Teams in today’s knowledge work environments. Stay tuned to the 3Back blog for more on how you can utilize Get To Done to make Teams better.
Want to know more about how Kanban works with Lead Time and Cycle Time?
Register for 3Back’s Certified Kanban Training.
As Always, Stay Agile.