I think it's good to think about metrics for KPI's versus as a "pulse check" or "health check". Some metrics are meant to be maximized or minimized whereas others are just meant to be stabilized.
Cycle Time I think is a sort of pulse check. If you measure it and it makes a surprising move this might tell you there's something to investigate.
Another aspect to look is Cost Of Delay. Without knowing how much an organization will make by reducing cycle time and how much it costs to reduce cycle time etc, even if value is delivered over time, it would be mere out of luck. This is intelectually demeaning. Reinertsen briefly, explains how to calculate cost of delay in this video- https://www.youtube.com/watch?v=du2WV1IbULU. If an organization wishes to deliver more, but cannot, in other words, if their backlog queue is huge, it gives the reason to act and implement the same changes that they will do after measuring cycle time. Here is another video by Donald Reinertsen https://www.youtube.com/watch?v=KmvUyPDgquc describing cycle time vs queues. Also measuring cycle time systemically and at scale is not easy. So why spend time measuring, while there is a large queue.
These are such wonderful points, Badhree! Thanks for sharing them.
I agree that Cost of Delay is needed to put an actual business cost around "slow cycle time". And I also agree that measuring cycle time at scale is not easy, nor practical.
This is an interesting take on cycle-time. The lack of numbers on your Value Delivered/Cycle Time graph suggests that it is an intuitive perception drawn from your experience. If this graph is data driven, can you share anything about your data sources. I understand that data might be confidential.
I like the suggestion of measuring toil (friction experienced by developers). This is something we are thinking about. Any suggestions on how to measure that?
I think it's good to think about metrics for KPI's versus as a "pulse check" or "health check". Some metrics are meant to be maximized or minimized whereas others are just meant to be stabilized.
Cycle Time I think is a sort of pulse check. If you measure it and it makes a surprising move this might tell you there's something to investigate.
Another aspect to look is Cost Of Delay. Without knowing how much an organization will make by reducing cycle time and how much it costs to reduce cycle time etc, even if value is delivered over time, it would be mere out of luck. This is intelectually demeaning. Reinertsen briefly, explains how to calculate cost of delay in this video- https://www.youtube.com/watch?v=du2WV1IbULU. If an organization wishes to deliver more, but cannot, in other words, if their backlog queue is huge, it gives the reason to act and implement the same changes that they will do after measuring cycle time. Here is another video by Donald Reinertsen https://www.youtube.com/watch?v=KmvUyPDgquc describing cycle time vs queues. Also measuring cycle time systemically and at scale is not easy. So why spend time measuring, while there is a large queue.
These are such wonderful points, Badhree! Thanks for sharing them.
I agree that Cost of Delay is needed to put an actual business cost around "slow cycle time". And I also agree that measuring cycle time at scale is not easy, nor practical.
Hi Abi,
This is an interesting take on cycle-time. The lack of numbers on your Value Delivered/Cycle Time graph suggests that it is an intuitive perception drawn from your experience. If this graph is data driven, can you share anything about your data sources. I understand that data might be confidential.
I like the suggestion of measuring toil (friction experienced by developers). This is something we are thinking about. Any suggestions on how to measure that?