Avoid the Abilene Paradox

An excellent article by Jonathan Babcock raises a thought provoking idea. When gathering requirements, we can end up with requirements that no one actually wants, because everyone thought someone else wanted it. This is apparently known as the Abilene Paradox, a term coined by Jerry Harvey. We can apply our insights into stakeholders and traceability to prevent it.

Eliciting Unowned Requirements

The other point we walked away from the paradox with is that somehow, the group “manufactured” a requirement (or desire) to go to Abilene, even though no one actually wanted to go. This can be a real challenge with elicitation. The “requirements analyst” believes he has discovered a requirement to go to Abilene when there really wasn’t one.

The problem manifested partly because the people in the story jumped immediately to a solution, and then made assumptions, and then group think‘ ed themselves into a horrible experience. Once they were considering a solution, and failing to communicate, they ended up manufacturing the requirement to go to Abilene.

Context And the Ownership of Goals

Had the people validated those assumptions, with a simple question, “Why do you want to go to Abilene?”, they would have avoided the dreaded trip entirely. If you walk away with the “solution” of “always ask why” you’ll do ok. But you could do better.

“Why?” is certainly a good question – but ultimately, you need to understand the rationale and ownership of goals. In the story, the father-in-law proposes the trip to Abilene as a cure for (perceived) boredom. The rest of the family assumes that he, and each other person (progressively) actually wants to go to Abilene. In reality, the father-in-law wants to cure family boredom, and the other family members want to make each other happy. The long drive through the Texas desert to eat bad food in Abilene achieves none of those goals. Why someone would think that driving through the Texas desert is a cure for boredom, I’ll never know. Perhaps when you live 53 miles outside of Abilene, you have different standards.

Imagine that the father-in-law had expressed his goal (requirement) – “We need a cure for our boredom!” and then proposed a solution “Let’s drive through the desert.”

The family would have had the opportunity to dispute the need for a cure for boredom. At a minimum, we would hope that they would propose an alternative solution, like staying home and seeing how high they could stack some rocks.

In the World of Software Development

Cute as the story is, there are unfortunately too many examples of this happening in our companies or with our clients. Someone proposes a solution, without defining the problem. It could be an executive, forbidding all employees from using instant messaging tools, instead of identifying low worker productivity as a problem to be solved. It could be someone from the IT department mandating that all employees may only use Internet Explorer, instead of identifying that the human resources self-enrollment website does not support other browsers.

Or it could be an example I saw recently in a use case. Paraphrasing to protect the innocent:

User adjusts price discount on product.

System updates product price on quote.

System updates subtotal price (for all products) on quote.

User requests recalculation of shipping and taxes.

System updates total price (for all products, including shipping and taxes) on quote.

Discussions with the product manager reveal that the existing system (being modified) was implemented such that the server that recalculates taxes can not handle the volume of tax-calculation requests that would be created if taxes were recalculated with every price change (step 1) on every quote. By asking users to make multiple price changes, and then just recalculate taxes once per quote, the load on the tax-calculation system was dramatically reduced.

A use case represents what the user is trying to accomplish – it should neither incorporate design elements, nor articulate system constraints.

There’s a very real possibility that the tax-calculation server has been updated to handle all the traffic for all of the users. If the use case is written such that it implies that the user desires to manually recalculate taxes, then the user is very likely to get stuck recalculating taxes manually.

Expressing this procedural artifact within the use case is forcing the user to go to Abilene for dinner.

Conclusion

When you gather and write requirements, find out the source of the requirements – and trace those requirements to the source. Don’t mix them up. Don’t enforce constraints / requirements within a use case that are unrelated to what the user is trying to accomplish (reducing the price on a quote to close a sale). Validate and document the system constraints (tax-calculator can only handle X quotes per hour), separately.

This is a great way to describe a real problem – one that is often associated with a lack of formality in requirements assessment. One problem is, the more formal the requirements tracking, the less agile it can feel to the dev team. In the outside-in approach to software development, John Sweitzer and I described techniques that specifically address the Abilene Paradox (although we didn’t use that colorful name for it!).

We start with understanding WHO your project’s stakeholders really are. That tells you whose requirements to even consider. Then we suggest ways to prioritize them, using a tool we call the Stakeholder Goals Map. This approach also allows us to deal with changes over the course of a project: changing requirements (yes that happens!) and changing constraints (like budgets). Read more at http://outside-in-thinking.com/?p=50

Product Management Today

@sehlhorst on Twitter

Who Should Read Tyner Blain?

These articles are written primarily for product managers. Everyone trying to create great products can find something of use to them here. Hopefully they are helping you with thinking, doing, and learning. Welcome aboard!