For organizations in the midst of an agile transformation, the question “how do we know if/when we’re agile?” is pressing. When quizzed about why they want to be agile, they respond that they “want to go faster”, or maybe even that they “want to be more responsive.” But what does this mean, and how can an organization know whether they are good enough?
Speed Matters, but only so much
One candidate measure we use in The Evidence-Based Management Guide (EBM) is Customer Cycle Time:
Looking at Customer Cycle Time is important because it helps an organization streamline its means of delivering value to customers. As important as this is, however, doesn’t consider the time it takes to gather feedback and formulate a response. A measure that better reflects an organization’s ability to be responsive is what we call the Time to Pivot:
Time to Pivot reflects all the things that are done between the receipt of information that triggers a need to respond, and the actual response itself, including the time spent deciding how to respond. Only measuring things like Customer Cycle Time can sometimes ignore this time by only starting the clock once the decision of what to do has been made.
But even Time to Pivot ignores something important - the effectiveness of the response. Two additional kinds of measures (called Key Value Areas in EBM) are useful for doing this: Unrealized Value, and the Ability to Innovate.
Effectiveness matters, too
Unrealized Value measures the potential value that could be realized if the organization met the needs of all potential customers or users. Inherent in the concept is the idea of a satisfaction gap between the current experience of a customer (or other stakeholder) and their desired experience. Responses that don’t contribute to reducing this satisfaction gap are ineffective.
The Ability to Innovate measures the potential for each response to reduce Unrealized Value. An organization who expends lots of time in unproductive meetings, or whose developers are constantly interrupted or are constantly switching from one task to another, or from one team to another, will have little ability to deliver new value. Even if they deliver frequently, each release will do little to reduce the satisfaction gap.
Conclusion
So what does this mean for measuring agility? First, when measuring speed, make sure the clock starts when you get information that requires a response, whether it is customer feedback or news of a competitor’s latest release. Starting it when you finally get around to doing something ignores the time you spend deciding what to do.
Second, you need to measure the effectiveness of your product releases, not just their frequency. Product releases that don’t reduce a satisfaction gap aren’t effective. Your “requirements”, whether expressed as Product Backlog Items or not, may not produce the result you think they will, so you need to measure the results to know what worked and what didn’t.
Finally, you need to understand how much of what you do is really valuable. People may look busy, but if most of what they do is unproductive then the organization won’t be able to reduce the satisfaction gap very quickly, no matter how frequently it delivers new releases to customers.