How do you know if your chosen agile initiatives are working? How do you know if you’re agile consultant is actually helping or just telling cute stories and quoting books they’ve read? How do you know if your agile teams are actually agile or just call themselves that?
This is a dicey question, and there are a fairly large number of agile consultants who will tell you that you can’t measure such things.
Like most falsehoods, this has a seed of truth to it. When you are dealing with complex systems that are primarily people-powered, you can’t quantify everything, nor should you try. This is one of the many reasons why managing by the numbers is so wrong-headed. You have to be in the midst of your people. You can’t quantify things like communication, collaboration, trust, habits, or many of the multifaceted aspects of the way people work with other people.
It is also true that any change in business as usual will actually create a dip in productivity (and possibly morale) as people have to leave the familiar and struggle to form new ways of working together. Unfortunately, this stage (sometimes called the “storming” stage) is where most people abandon their agile initiative because things got worse, and they never reap the rewards of riding through that dip and coming out the other side into the new normal of greater productivity.
However, it is my view that some aspects of agile effectiveness can be measured, and it basically comes down to this: are you delivering more value more quickly?
Companies increase their agility to make more money. Full stop. For all our fancy mission statements and talk about disruption and whatnot, every for-profit organization has the overarching goal of making money. Things that help companies make money, save money, or protect money from risk are seen as improvements, while things that cause companies to lose sales, lose money, or put their money at risk are seen as detriments.
Agility is not exempt from this. In fact, if agility isn’t helping you in this department, what’s the point in doing it?
There is no inherent value in conforming to “agile rules” or even the Agile Manifesto, so trying to measure that is a waste. There’s no inherent value in conforming to a plan, so trying to measure that is also a waste. That alone sweeps a ton of possible metrics off the table. There’s no point in assessing agile effectiveness by things like if you’re doing Agile Practice X, if you’re following the Scrum rules, or how well your estimates match up to actuality. None of that truly matters.
There is inherent value in delivering items of value, not wasting time reworking those items, and removing obstacles to delivering those items. Therefore, if you want a measurement of the effective agility of your team or organization, here are the metrics I think are not only most important, but are actually measurable.
1. How much value are you delivering over time? (Throughput, Lead time)
2. How much rework are you having to do? (Quality, Time spent on bugs)
3. How are work items flowing through your system? (Flow, Amount of work over time in each stage, Amount of work coming into and leaving the system)
The things that help you deliver more over time without increasing rework are enhancing your agility. The things that impair this dampen your agility. The whole reason to become agile is to deliver more, deliver faster, and deliver higher-quality. It isn’t to become better people, hack our corporate culture, or make software development more pleasant. All those things might very well happen and are probably desirable, but they are means to an end. Ultimately, it’s all about the Benjamins or whatever the kids are calling money these days, and that is the final criterion by which initiatives can be measured.
If you aren’t measuring these things, I encourage you to do so. A lot of people think their diets work, too, until they step on the scale. A lot of people think they can sing until they do it in front of Simon Cowell. Find out, and when you’ve found out, don’t use those measurements to beat yourself up (or anyone else for that matter), but use them as a catalyst for conversations about improvement.