The Only Legitimate Measure of Agility

29 04 2016

“Oh no you di’unt.  I know you didn’t just say there’s only one legitimate measure of agility!”

Oh yes I did.  That’s exactly what I did.  Not only is there just one legitimate measure of agility, but it’s a very simple measure, requiring only one metric, and a completely objective one at that.

“Obviously, you don’t understand.  Agility is a tremendously complex proposition, requiring many moving pieces, and any attempt to measure it is going to have to take into account at least dozens if not hundreds of different metrics, which will be different from methodology to methodology, and most of those metrics will be untidily subjective!”


An agile culture is indeed tremendously complex, but I’m not going to measure the culture. I’m going to measure the success of the culture, which is a simpler task.


Agility is a measure of how frequently new functionality is released to customers customers customers in production production production.  Significantly, this is not how frequently it’s released to the business in the UAT region.

Why customers customers customers?  Why not the business?

Those of us who are developers are familiar with the phenomenon, discovered only after wading through thundering torrents of human misery, that it’s difficult-bordering-on-impossible for developers to understand what the business wants from them without an iterative process of stepwise refinement.  That’s why we have the business in the room with us.  That’s why we’re constantly pestering them with questions.  That’s why trying to cope without a product owner is such a disastrous idea.

But as hard as it is for us developers to understand what the business wants, it’s at least as hard for the business to understand what the market wants without an iterative process of stepwise refinement.  Harder, because they have not only to know what the market wants, they have to predict what it will want when the software is finished.  The business is undoubtedly better than we developers are at predicting the market, but that’s not saying enough.  Without iterative stepwise refinement of the project’s goals, it will end up being much less responsive to customer’s needs–and therefore much less valuable–when it is finally released. If it is finally released.

Of course, that iterative process of stepwise refinement for the business is frequent releases to production. This is so that the customers, who pay the bills, can see and react to the trajectory of the product, and the business can either A) adjust that trajectory for better effect, or B) abandon the project, if it turns out to have been a bad idea, early before millions of dollars are irretrievably gone.

That’s what the word “agility” means: the ability to respond quickly to unexpected stimuli and change direction rapidly.

The only legitimate measure of agility is this simple formula:


where w is the number of weeks between releases of new functionality to production.

If you release every week, you’re 100% agile.

If you release every month, you’re 23% agile.

If you release every year, you’re 1.9% agile.

If you release twice a day, or ten times a week, you’re 1000% agile!

I know what you’re thinking.  You’re thinking, “What about the single startup developer with execrable engineering practices whose production server is running on his development machine, and who ‘releases’ every time he commits a code change to source control?  Are you going to try to claim that he’s agile?”


Yes I am.

He may not be very good at agile, but he definitely is agile, responding constantly to customer needs.  He’s certainly more agile than a big company that releases only once a year but has dutifully imposed all the latest engineering best practices on its developers.

And if he doesn’t go out of business, it will be his very agility that will force him to develop and adopt better engineering practices, purely in self-defense.  Which is to say, enthusiastically and wholeheartedly, as opposed to the way he’d have adopted them if a manager forced them on him.

You see, that’s the way it works.  Demos aren’t agility. Retrospectives aren’t agility. Pair programming isn’t agility. Not even test-driven development is agility. Releasing to production is agility, and all those other things are supportive practices that have been empirically demonstrated to enable agility to be sustained and increased.

A client says, “If everything goes right, we release about once a year.  We’d like to be more agile, but we have a lot of inertia, and we’d like to take it slow and gradual.  So we put up this card wall, and now we’re considerably more agile.”


No they’re not.

They were 1.9% (max) agile before they put up the card wall, and they’re 1.9% (max) agile now. The card wall may or may not be a good idea, depending on how they use it, but it has zero effect on their agility.

I think agile transformations ought to start on the other end.

Do whatever it takes to develop the ability to release to production every week, and then start doing it.  Every week.

If you have new code since last week to release, then release it.  If you have no new code, then re-release exactly the same code you released last week, and complain bitterly to everyone within earshot.

Presently, perhaps with the help of a powerful director or vice president or executive, you’ll start getting some code.  Probably it won’t be very good code, and minutes after you release it you’ll have to roll it back out and return it for repair; but you’ll be agile, and your agility will drive the development team to adopt the engineering practices necessary to support that agility.

That’s the way we do things in an agile culture, isn’t it? We try something for a short time to see if it works, and if it fails we figure out what to do to improve the process and try again.

Maybe the dev team will choose to adopt card walls and demos and retrospectives and TDD and continuous integration and all the rest of the standard “agile” practices, and one or more of us will get rich teaching them how.

Or…maybe…they’ll come up with something better.





3 responses

29 04 2016
Agility Isn’t For Everyone | Agile Fantasies

[…] post of less than 24 hours ago, The Only Legitimate Measure of Agility, has drawn some interesting comments.  (I mean real, face-to-face, vocal audio comments, not […]

30 04 2016
Christopher J. McClellan

I’m so terribly happy somebody finally said it. Spot on!

2 05 2016
Dan Wiebe


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: