Three Key Agile-Centric Metrics

In one of our previous blogs the term “just enough” was used to portray the idea that we (whether you’re in a testing, dev, or management roll) should help everyone on the team to resist gold plating and actively help and encourage each other to do just enough. And that by doing the “right just enough” we are BEING agile. But why? You may ask, is this term so important? Because it plays into the team’s overall velocity.

My friend and colleague, Shaun Bradshaw, and I were recently pair-coaching at a client. We started to have a conversation about velocity, not directly driven by the clients’ context, but in general.

Shaun was focused on velocity as a relevant metric within agile teams to drive conversations between teams and upper management, and I was struggling to get there.

Part of his focus was to create visibility around the difference between average velocity and current sprint velocity. Furthermore, the teams and management would be able to see:

• Velocity gaining stability over time (predictability, low variance)
• And increasing over time (short-term burst)

as part of newly formed and/or newly coached agile teams. Now I really get what he was saying. I agree that teams in these contexts should be displaying activity and behavior towards those two results. However, my struggle was to make velocity a key metric. One that everyone laser focuses on.

In order to drive some depth into our discussion, I asked both of us to define our three key or crucial metrics. That is if we could ONLY have three metrics to measure agile teams (and organizations), what would they be? Here are our choices (and remember, these were driven over a lunch conversation, so not the deepest of thinking behind them):

Shaun Bradshaw

1. Sustainable pace (heartbeat, tempo, team health)
2. Collaborative flow (swarming, avoiding Scrummer-fall, 3-amigos)
3. Effective handling of interruptions (visibility, factoring into commitments/plans)

Bob Galen

1. Value delivered (demo reactions and measured usage)
2. Continuous improvement (everywhere, effective retrospectives)
3. Predictability (from a release/business forecasting perspective)

As you can see, velocity did not “make the cut” in our lists.

Sure, it underlies some of them, for example, sustainable pace for Shaun and predictability for me. But if these are our critical, first-order metrics, velocity isn’t one of them.

What do you think of our lists? Agree with us? Disagree? And why? And what would your list look like?

We ended our discussion agreeing that velocity could be a 2nd Order metric. Why?

Because it’s fragile. Here are two related blog posts that explore that fragility:

• http://rgalen.com/agile-training-news/2015/1/3/forecasting-is-it-evil-in-agile-portfolios
• http://rgalen.com/agile-training-news/2015/8/13/when-its-no-longer-relative

But probably the biggest reason I was pushing back on the velocity with Shaun is that it can be misinterpreted and misused by leadership.

Feedback from Shaun: I think this is where you and I had the biggest disagreement. It seems to me that you’d prefer not to show velocity so it’s unlikely for the misinterpretation to occur. I think that’s fair, but I suspect that if velocity isn’t clearly identified, management will question it. As a result, my preference is to call it out. Put it out there for everyone to see. Invite the conversation about why it is what it is, and is it good by the team’s standards? Basically, if we don’t openly share velocity it may seem like the team is trying to hide it.

I have little to no concern if Shaun is focusing on velocity as he coaches agile teams, as he’s an experienced coach and understands the nuance of velocity as one of a series of healthy agile metrics.

For example, he won’t overreact if velocity changes abruptly between two sprints. Or if a team seems to struggle to gain accuracy early on. Or if their current sprint plan is 10 points less than the last one, he will certainly not challenge their commitment and professionalism. Finally, he knows not to compare velocity across teams to draw any conclusions.

But in all of the above cases, management can often make these mistaken interpretations and many more. Which can lead to metrics dysfunction and the team showing less transparency and gaming their velocity.

More feedback: I think this is the best argument against openly publishing or calling out velocity, but maybe it means, as a coach, you have to be aware of the organizational context before you recommend if/how you use velocity. In some organizations, you may never be able to cover the potential dysfunction of misinterpretation, but in others, creating the visibility of the metric could help dispel some of the dysfunction.

First, I want you to consider how important a light you want to focus on velocity as one of your metrics. Is it one of your Top 3 or is it secondary to others?

In my discussion with Shaun, I wasn’t emphasizing hiding your velocity, just deemphasizing its importance and interpretation within your organization.

I challenge all of you to sit down and list your own Top 3 Crucial/Critical Agile Metrics. Ask yourself:

• Are they similar to our lists?
• What are the differences?
• What led to your picking those three?
• And most interesting, was velocity part of your list?

I also want to thank Shaun for forcing me to think more about metrics…

Stay agile my friends,

Bob.

Up Next:

• Moving from doing to BEING agile >> Read
• Pair-Coaching in Agile >> Read