Friday, August 04, 2017

What metrics should we use for our visual management board?

I sent this response to someone asking "What metrics should we use for our visual management board?". I think the advice is generally useful, so I thought I would post it here. 

Metrics are hard, but they should be driven by your goals.

If you are trying to improve a system, first you need to focus on quality, then predictability, and then throughput.

To improve anything, though, you need to be making changes, so the first metric is "Rate of change" ... "How many things (no matter how small) have we improved this week?". Once you have a focus on 'we continually improve', then you need a metric driving the direction.

For Quality I'd measure the bounce rate (how often is something rejected as needing more work).

For Predictability you need to identify variance in your system and remove it. Measure the time from 'committed' to 'done' for each piece of work. Then based on that define a SLA "We deliver 80% of our work within 2 weeks". Then Pareto anything that goes outside that SLA and fix the root cause of these issues.

You have got rid of variance when the rate your team is delivering work is steady.

Little's Law defines a relationship between the amount of WiP (work in progress) in a system, the TiP (Time in Progress), and the "Throughput" (or Delivery Rate) of your system. In effect the less WiP the better the throughput. This only applies if you system has very little variance, hence we have to make it stable first, then optimize.

For Throughput, you can start by reducing the amount of work in progress (striving for single piece flow).  You can do this by focusing on collaborating on work over starting new work.

The rest of throughput is identifying the point in your process where work piles up. That's probably your bottleneck. Follow the ToC Focusing steps. (http://blog.nayima.be/2009/04/16/the-theory-of-constraints-five-focusing-steps-in-action/) to identify and fix bottlenecks and throughput will improve.

Originally I put 'efficiency' instead of 'throughput' but efficiency is not important, in-fact it can be bad.  Deriving for efficiency typically leads to maximizing 'utilization' so everyone is busy. This reduces the ability of a team to deal with fluctuation in the work loads and increases the work in progress which reduces throughput and introduces bottlenecks. It also has the side effect of removing the opportunity for people to reflect and apply improvements, which is how you ever get better.  As I said... metrics are hard.

Good Luck.

Post a Comment

GitHub Projects