Before it Gets Better, It May Need to Look Worse
Another example of how Workflow Metrics lead to improvement
Hello again. I coach leaders and teams on how to improve the way they deliver value to their customers in ways that work for their business. My promise has always been to give you real world examples, not textbook advice or platitudes from an armchair quarterback.
One of my favorite improvement tools is Workflow metrics. Over the last few years, I have fallen in love with seeing people’s eyes light up when they see the data behind the way they work. However, one thing I was surprised to hear quite frequently was, “We can’t use metrics until we are doing things right and the data looks better.” It has become the single most common refrain whenever I coach leaders and teams to use Workflow Metrics. And yet it is the single most incorrect thing they can think. That’s like saying, “I won’t start weighing myself until after I’m eating right and lose a bunch of weight.” In today’s Tidbit, I have a story about a time I introduced a team to Workflow Metrics BEFORE they “lost the weight”, and it helped them improve the way they managed work. And their data wasn’t pretty. And that was the point.
The Story
Once upon a time, I was coaching Jane (the names have been changed to protect the improving). Jane was a Scrum Master on a cyber security development team. She had asked for my coaching expertise on how her team could eliminate the constant unplanned support work that was a frequent hinderance to their flow. I believe the phrase she used was “they were inundated". I spent a few days reviewing the data behind their workload and that was all it took to show me exactly what the next course of action was. I immediately told her and the team’s leaders our goal needed to be, “to see a rise in the number of support tickets in the metrics.”
They immediately tried to correct my obvious error. “Um, Tristan, we came to you because we wanted to see a decrease in Support requests, not a rise in them, right?”
“Sometimes,” I told them, “on the path to improvement, you have to take steps that will make things look worse before they look better.”
When I looked at the team’s workflow metrics over the previous six months, I found only 2 Support tickets had been logged. Out of almost 200 issues they had solved, only 2 were Support tickets. I’m not sure about you, but when I hear the word “inundated” and “constant”, I don’t imagine the number 2. Also, it represented only 1% of the total number of completed work. Not exactly an outbreak of unplanned work.
In my gut, I trusted Jane when she said her team was inundated. I knew, however, without the data to back this claim, the team would struggle to take any corrective action. My advice to Jane was, as a result, that she first have the team start logging each time a Support request came in. If the team could discipline itself in this endeavor, they would be able to more accurately see how often these pesky side loaded requests for help were popping up and impeding the flow of other valuable work.
That is why, as you can see, they would first have to see a rise in the number of Support requests. Not because I wanted them to DO more. But because we first had to prove they were happening at all.
And prove it we did.
Landing the Plane
Sometimes you have to see how often the pain is happening before you can quantify it’s really a pain worth solving. Remember Kanban Principle #1: Start where you are right now. In Jane’s case, it was a pain worth solving. After just a few weeks of getting consistent at logging Support Requests, the team noticed that their workflow comprised of about 40-50% of such requests. They were indeed inundated. Now we could discuss the next improvement. Some teams, so eager to try and make things perfect before they measure, miss out on the ability to quickly learn and adapt.
That’s the moral of the story. If you wait until things are perfect before you start to measure, you’re missing the point of measuring. Measuring early in any change effort can be painful. You see ugly things. Sure you can wait until week 3 or 4 of a diet to start weighing yourself or taking blood/sugar readings. But, you are going to miss critical feedback on how your choices are directly impacting your metrics.
Jane’s team made two improvements after they saw their “ugly” metrics. They started using a new “Support” ticket type (that’s geek speak from their work management tool, Jira), and they also created a form they could point requestors to when they needed this type of work. They very quickly made this a standard way for collecting data on this pesky process pariah and, before we knew it, multiple other teams started using these same improvement steps. Teams thought they were seeing a spike in the percentage of Support requests. In actuality, they were simply capturing how often it was already happening.
And that, my friends, is how you can use metrics to prove there’s something to solve, and quantify how your improvements are impacting your metrics. This leads to Kanban Principle #2: Commit to continual, evolutionary improvement.
Until next week,
Keep on Learning, Keep on Growing
This is already one of my favorite posts.