Mar 072014

While the problem of scaling Agile is getting the bulk of attention these days, I’ve been running into another problem quite frequently: the value dimension. There’s nothing in Scrum, XP, or other Agile approaches that mandates some calculation of value. From one perspective, I’m glad that they didn’t. Changing the principles and practices within teams didn’t require a gratuitous injection of value into the discussion, adding complexity and giving ammunition to naysayers.

From another perspective, enough time has passed, and Agile has proved itself enough, to start thinking about value. For some people with whom I worked on a recent project, it was fundamental. They already had the odds stacked against them (lots of technical debt, a risk-averse management culture, long-distance relationships with testers and product managers), so some teams felt that they needed to show the value of switching to Agile methods and principles. Even though the top executive in this enterprise had decided that they should embrace Agile, many middle managers below him had their doubts.

Inevitably, conversations about value get messy. As soon as someone proposes a measure, people immediately pick it apart. No, you can’t calculate value that precisely. No, you shouldn’t be measuring business cost, because no one will believe the numbers you derive. No, time to market isn’t really a measure of value…Or is it?

These questions are not unique to this one organization, nor is the importance of figuring out the value of what you’re doing with Agile. Now, if you’re afraid that I’m going to launch into a proposal for a sophisticated, brain-burning approach to calculating value in Agile, relax. It’s Friday, so there’s no need after a busy week to exhaust the mental gas tank much further.

Instead, let’s talk about the requirements for any Agile theory of value. What is it supposed to calculate, and what are the pitfalls it should avoid? Here are my proposed guidelines.

The value of Agile methods is not the same as the value of software that Agile teams produce.
This basic confusion happens surprisingly often. Some of the teams with whom I was working tried to prove the value of adopting Agile to their management by assigning dollar values to stories. Unfortunately, that’s like trying to prove the value of a college education by rating the quality of the books assigned in your courses. Management, in this case, didn’t know clearly what it wanted Agile to do, so arriving at a convincing measure of how much Agile improved something (quality, time to market, features produced, or another goal) would have to wait on deciding which goal was the right one. With this added confusion, the chances were even slimmer that a statement like, “The last sprint produced $87,250 worth of software,” would have any meaning to the middle managers.

Business value exists at the level of business activities.
I love Mike Cohn’s book on Agile planning, except for the part about assigning dollar values to stories. If we’re measuring business value, then user stories are too granular to be meaningful. You can say for certain that, when sales reps can’t add contact information to the CRM system, that’s going to have a significant effect on business, enough to be calculable. The feature that lets you see all CRM data about a contact when you’re working in your mail client is helpful, but the impact is so low that it doesn’t really have a business value you could estimate. Value exists at the level of epics and themes, not stories, because stories don’t encompass business activities fully.

The portfolio must have some role in calculating value.
When we prioritize the backlog, we’re implicitly saying that there is a cost to doing some work, and not doing other work. That same principle applies at higher levels, obviously: The value of the contents in the latest release depends to some small extent on what didn’t go into the release. The value of doing the CRM project depends on the value of the ERP project we didn’t do. Therefore, measures of value must have some connection ultimately to the portfolio. Otherwise, anyone can devise a business argument for anything, and it’s then a question of whose requests gets granted first.

Value is a reciprocal measure.
Whether you’re working in a software company with external customers, or an IT department with internal customers, value is always a two-way street. Again, anyone can assert the business value of a story, epic, theme, product, or project for the technology consumers, but it also has to have value for the technology producers. Otherwise, software companies build products that don’t fit their market, and IT departments take on projects with high risks and costs in the long term.

Nobody believes in exact measures, but they’re useful anyway. Go ahead, plug the numbers into your spreadsheet. You have to do it, even though no one will believe that $2,193,715 is the real value of the next release. People do believe that the value is somewhere in the neighborhood of that number. Even if it’s a big neighborhood with fuzzy borders, people still want a rough idea of value.

ROI calculations can be so big as to be unbelievable. Agile is a disruptive innovation that radically changes how software teams work. Frequently, the benefits are so great that, if you were to do an ROI calculation, you might get a result in the 500% or higher range. While there are other reasons to be skeptical about ROI as the ultimate economic measure, that startingly high ROI invites skepticism.

Investment on return may be more important than return on investment. When people try to do Agile on the cheap, they think that there is a monotonic scale of investment versus reward. They’re wrong. Underinvestment in its many forms — little training, no coaching, no time to master and Agile practices, to name but a few has killed Agile adoption far too frequently. That’s a good reason to get people focused on whether they’re willing to invest what’s necessary to make a disruptive innovation like Agile successful, and to doubt the value of ROI calculations.

There are lots of other measures than ROI. Economists don’t focus exclusively on ROI as the ultimate economic good, so why should we? We can borrow some measures directly from the economists, such as liquidity (the ability to direct assets into other uses) and inventory turnover (the frequency with which people use the software). Some measures that don’t come directly from economics, such as the reliability of teams to deliver on their commitments, or the long-term cost of technical debt, are also worth tracking.

 Any definition of “Agile value” should take these guidelines into account, lest they steer into the cul-de-sac that the teams I described at the beginning of this post found themselves. Now, I’m off to measure the value of a roaring fire on a cold, cloudy March day.


 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>