“If you cannot measure it, you cannot improve it” – Lord Kelvin
I always thought that quote came from Jack Welch of GE fame – apparently not. Like all good aphorisms it has many fathers/mothers, but the sentiment says it all: what drives our desire to measure things is our need improve.
Improvement lies at the heart of the agile philosophy; it is burned into the retrospective rituals in Scrum and XP; it is the starting point for Kanban; and has its own word in Lean – Kaizen.
However, without measurement what exactly are you improving? How do you know if your improvement initiatives are having any effect?
This is why we measure.
Our journey has been an interesting one from “on-time, on-budget” to flow of work. Along that journey we have had to disassemble the orthodoxy around waterfall planning, engage our stakeholders in backlog grooming, get our teams organized along agile lines, capture our work in small deliverable increments and introduce statistical concepts and the scientific method as a way of approaching change.
No small feats.
Not surprisingly this journey has taken a while – we’ve been actively measuring for about 18 months. What did surprise us though, was that measurement was a foreign subject to most IT folks when we started. It was seen as an unnecessary and burdensome overhead and we were met with the normal resistance to change.
So, we started by measuring the simplest and most common things that are available and visible across all of our work:
- When it was initiated by the “customer”
- When we started work on it
- When we finished work on it
- When it became available for use – when the value was yielded
Then, we counted how many such things passed through the teams in a month.
We also set up monthly reviews – after all, inspection is how you initiate the improvement – and created a template for displaying what was going on that we asked all teams to follow. Within that template were histograms and concepts around the distribution of the data. These ideas were also new to most IT folks.
Lord Kelvin and the Importance of Measurement
Our first improvement happened when teams realized that they didn’t have a really clean way of demarking the work or capturing its state.
Next: teams concluded that their work was connected together, so value streams started to emerge with hidden queues.
Then, they realized that their metrics showed different bits of work were being handled differently. This led to understanding the classes of service.
Another improvement happened when teams learned there were better ways to display what was really going on in their world. As a result, they began to create control charts and cumulative flow diagrams as well as experiments with WIP limits.
The experiments started to take the shape of hypotheses and be articulated in a way that understood the need for independent action and measurement.
As a result, the teams began to suggest reallocation of resources to better suit the work flow and to improve the lead time to their customers. Together, all these things set into motion a different set of conversations and decision-making based on what we saw in our data rather than just our hunches.
Our journey continues.
The nature of improvement is that it is continuous – it must be because the work and environment constantly changes too. But I like to think that if Lord Kelvin witnessed our journey – which is proving to be just as valuable as the destination – he might just give us a smile and a nod.