Skip to main content

Leading vs. Lagging Indicators

With my current focus on #flowefficiency where I work, I thought it was a good time to share how we are ensuring we focus on leading indicators instead of lagging ones. Having collecting 2.5 years of metrics during our Agile journey so far, its sometimes tricky to measure the right thing. What you measure tends to drive unwanted behaviour.


I think of a lagging indicator as something that has already happened. For example how many stories did a team complete, how many teams completed all committed stories, what is a teams current Flow Efficiency score? These metrics are useful, but don't necessarily lead me to my desired outcome. They just tell me what the current state is. 


A leading indicator leads me towards the outcome we want to achieve. I think of it as the impact or behaviour change we need to see to achieve the outcome. When you think of it in these terms you need to think about how to measure the changed behaviour. For example, to improve the flow efficiency score I need teams to start performing experiments to remove waste in their system. So my leading indicator, and the thing I actually want to measure is how many waste removal experiments did the team perform this month/quarter. This behaviour change will lead to an outcome. For example, if a team has zero experiments, that's a pretty good indicator that their flow efficiency score will not be changing anytime time soon.




Make sure when you are collecting Agile Metrics for your teams that you choose the right thing to measure that will drive the right behaviour change.


Comments

Popular posts from this blog

Increasing Analytical Thinking in Agile Teams

Shameless promotion alert! I did a talk this week with the Agile Auckland meetup that was about increasing analytical thinking in Agile Teams. Agile Auckland kindly filmed the virtual session and its uploaded to YouTube here. If you are passionate about analysis and improving the quality of it in your Agile team, please go and check out the video. A link to the Youtube video is below

Misusing the word Requirements

The more I think about the word #requirements the more I think it is and has been misused for decades, by myself included. Imagine I have a bunch of nuts, I don’t know what size the nuts are which means I don’t know what size spanner I need. I could write a BABOK format Requirement that explains that “The solution shall have a spanner that loosens a nut easily” but no one can build anything from it because we don’t actually know what size spanner to build. We don’t need a requirement. We need more information. How about a hypothesis instead? I believe that if I test a range of spanners on the nuts I will find the right size, I will know when I am successful as the nut will be turned by the spanner without slipping. Now this tells me what I need to do and how I know I will have found an answer. Let’s imagine the result is that we discover we need a 10mm spanner for our 10mm nut. Now I can write a requirement that says The solution shall provide a 10mm spanner that can turn a 10mm nut co...