So, we've briefly looked at Velocity, what it is, how it gets abused and what the typical result of that is – and therefore the need for an alternative. Now we're going to look what "agility" means, with the intention of figuring out some measures that are better aligned with that.
"Agility" is, unfortunately, a nebulous term – and one that get's used and abused. I generally try to avoid using it at all because of this ambiguity. For far too many people, "Agile" often means some half-baked Cargo Cult implementation of Scrum. Setting aside the platitudes in the Agile Manifesto for a minute, I've previously made the assertion that true agility is a function of Speed and Optionality.
Let's look at a specific example to help understand what I mean. One of the most agile animals we know is the humble House Fly. They can accelerate very quickly AND they can also change direction extremely quickly – giving it all the optionality in the three-dimensional world it lives in.
And yet the fly can outmaneuver any human-built craft at low speeds. Buzzing annoyingly across a room, a housefly reaches speeds of up to 10 kilometers per hour at twice the acceleration of gravity. When turning, it is even more impressive: the fly can execute six full turns per second, reaching its top angular speed in just two-hundredths of a second. It can fly straight up, down, or backward, and somersault to land upside down on a ceiling. If it hits a window or a wall sideways, which it often does, the fly will lose lift and begin to fall. But its wings keep beating, and within a few microseconds, the fly recovers its lift and can move off in the opposite direction.
What about for Product Development? How might we measure a similar ability to accelerate and change direction? I've previously articulated three foundational principles behind "agility" that I use to guide and assess the "agility" of how a team or organisation is operating – and how it is improving over time:
These three are aligned to the Speed and Optionality in that by delivering early and often, that provides optionality to change direction. If you are fast end to end, you can develop and deliver an improvement (through iteration or increment) in fairly short order. And the third point is critical: without feedback you can't safely operate in a complex environment. It's the feedback that gives you information (OODA Loop style) with which to decide how to deploy your capabilities speed and optionality. This isn't just Agile for agile's sake, but in a practical sense – in order to actually improve, both as a team and as a product or user/customer experience.
Ok, so with that as a starting point. How might we measure "agility" in our organisations?
Before we go there, some caveats: This is supposed to be a starter for ten. I know full well that this is not perfect. No measures are. Nor does it need to be perfect. The current certainly isn't! My reasoning is that the current vacuum of alternatives to "Velocity" is leading Execs (and others) to focus on the completely wrong thing. Without an alternative, we are stuck with Availability Bias: drunk people looking for their keys under the streetlamp because that's where the light is, NOT because it's where they dropped their keys. To perhaps labour the point: we don't need a laser-pointer shining on the exact spot. The mission is to direct attention on to areas where focus is more likely to lead to Good Things™ happening.
With that said, in Part Three we will delve into the first of the three above…