Apr 142015
 

Agile practitioners are often proud — and justifiably so — that when people are seriously adhering to the principles and practices, they keep the focus on value. They usually do a better job on average, I would argue from both first-hand experience and a fair amount of research, than the adherents of Waterfall methods. That’s not the same as saying that there’s not room for improvement.

Value is a slippery concept. What’s valuable to you isn’t necessarily valuable to me. That statement extends to user stories, in which the “so that…” clause differs, depending on the persona identified in the “As a…” section that precedes it. We’re supposed to write stories that have some value for that persona, no matter how minimal it might be, but we often don’t show significant value until we’ve finished all the stories organized into an epic, theme, sprint, or release. (The attraction of creating an expense report, for example, is significantly less until you can update it when needed, too.) We prioritize the backlog from highest to lowest value stories for a variety of reasons, such as ensuring that if we run out of time before a planned release, we cut the lowest-value stories, which are coming conveniently last in the list. However, we know that life isn’t as simple as a single queue of neatly sequenced work items. Which is more valuable, the ability of a salesperson on the road to enter sales activity easily, or the report that tells the sales manager about the current state of the pipeline?

Thus far, the attempts to develop better ways of assessing or expressing value among Agilists have been, at best, unsatisfying. I always make a point of recommending Mike Cohn’s classic book, Agile Estimating And Planning, to people new to Agile, but the section on estimating the dollar value of stories is the weakest part of the book. It’s written for software companies wanting to estimate the value of stories, in terms of sales, which makes it hard to retrofit onto the needs of IT organizations. Even if you are a software company, it’s of limited value. How do you qualify the value of the “create expense report” story until you have the “update expense report” story? What’s the value of a table stakes capability, such as creating a user account? Or something designed as a loss leader? Should you re-assess the estimated dollar value (or, to avoid being Ameri-centric, rubles, euros, rupees, pesos, etc.), once you find out that customers are using the capability more or less than you expected? At some point, the ROI of just making the judgment, “This story looks more valuable than that one,” becomes higher than the result of the alternative, a complex and questionable financial model. Other techniques, such as “Value Poker,” just seem gimmicky, and can’t really capture  subtleties like the “different persona, different value.”

Unfortunately, we can’t avoid discussions about value. For example, introducing Agile into an organization that is saturated in the earned value management (EVM) worldview is a fast path to a frequently difficult conversation about why EVM isn’t really a measure of value, in spite of its name. (EVM metrics describe cost and schedule, not how much good the software does, after delivery.) Even when you craft a good response to people used to looking at the world through EVM lenses, the question, What is the real value of what we’re building here? can ambush you in ways you might not be prepared to handle.

Recently, a software architect of my acquaintance was involved in an evaluation of his organization’s IT portfolio. The team doing this evaluation had a familiar list of questions designed to determine whether they should expand, sustain, or reduce the investment in various systems, based on their relative maturity. That was the intended path for this conversation with the project teams, at least.

The teams feared that the subtext of the discussion was, Justify the value of what you’re doing to the organization. Therefore, the portfolio evaluation group had a hard time pinning down the real state of each project, since the project teams were trying to convince the evaluators that their work was vital, before revealing the state of each project.

Many of these teams were Agile, so I had to ask whether the Agile teams made a more convincing case than their benighted Waterfall colleagues. The answer was a simple No. The person giving this answer, who has a very keen and exacting mind, is someone I would expect to detect any significant difference.

Of course, this anecdote tells the story of a single organization, so you can read too much into it. However, the important question isn’t, Are Agilists always better than their peers at creating value? Instead, the real concern is, Are Agilists, on average, better equipped to assess and express value? The answer, I fear, may be another No. At least, that’s the case for now, until the very bright people who are focused on matters like DevOps and Agile at scale turn their attention to the value question.

avatar

Tom Grant

Tom Grant is the former Practice Director of Cutter Consortium's Agile Product Management & Software Engineering Excellence practice. His expertise lies in software development and delivery, with a particular focus on Agile, Lean, application lifecycle management (ALM), product management, serious games, collaboration, innovation, and requirements.

Discussion

  One Response to “Value Is Elusive, Even To Agilists”

  1. Well said Tom. Value is a very difficult concept, no matter the methodology.

 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>

(required)

(required)