So there we were, at an agile conference. Well, not at the conference exactly. But at a bar very near to an agile conference.

A few patrons were talking agile stuff - like they do. And someone, as evidence in support of their stance that all metrics are evil, used the “But the Scrum Guide”, defense.

“But the Scrum Guide doesn’t prescribe any metrics. As a matter of fact, the word metric is not in the Scrum Guide. Not once.”

I found this claim dubious, so I checked it out.

Having too much Work in Process, also known as Work in Progress (WIP), is a remarkably common issue. In my experience, management often encourages this behavior. I don’t know if it is the notion that we will get more done if we work on more things simultaneously. Or perhaps there is a fear we won’t get enough things done unless we work on several of them at once.

This blog post is inspired by another Quora question; “What metrics do you use to track Agile Efficiency?”

To begin with, I want to state that if I had to choose between efficient and effective, I’d choose effective. Efficiency is often about output (how many widgets per hour), whereas Effectiveness is often about outcome (was the purpose consistently met).

Agility is about responding to change. Efficiency is achieved by driving out variation. An over-focus on efficiency will lead down a path of standardization and control, making for a less agile system.

That said, given the question was specifically about agile efficiency, I’d look at a few things - Throughput, Cycle Time, Deployment Frequency, and Mean Time to Recovery.

In a previous excerpt from the book, “Escape Velocity”, we looked at Velocity as a lagging indicator of a complex system. Here, we are going to think about velocity by way of analogy.

In this excerpt from Escape Velocity, we take a more in-depth look at Velocity and try to answer (at least in part) the question, “What Is Velocity”?

Recently, on a private forum, a member posted a query about their team’s recent drop in Velocity. Concerned about how their boss would respond, this individual wanted to know how to troubleshoot velocity issues.

After spending over an hour crafting a response, I decided I would also add it to my public blogs in case there are others who have similar questions about velocity.

When leadership asks for an increase in velocity, there are a few common behaviors that occur. Each of them are an attempt to satisfy the potentially unrealistic ask.

It is intriguing to me how often a manager will make a change such as this to a system of work and then later proclaim that the team is gaming the system. This is simply not the case. In fact, the gaming of the system is the improper application of targets or goals for lagging indicators. The rest is just natural consequence.

You can find more on the topic of velocity and metrics for agile teams in my book, "Escape Velocity".