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.

The Abilene Paradox

Jonathan quotes Harvey in his article. Go check it out, we’ll wait here for you.

What? You didn’t go check it out? Here’s how Jonathan sums it up:

The heart of Harvey’s message, in my view, may be summed up in the following points:

1. While the benefit of coming to decisions as a group is that more points of view will filter out the weakest options, groups sometimes reach incorrect decisions because of false consensus.
2. People will go along with what they perceive to be “the crowd” even if, in reality, there is no “crowd.”
3. People tend to have an impression – either warranted or unwarranted – that there will be repercussions to speaking out against ideas with which they don’t agree.
4. If we acknowledge that the paradox exists, we can be more conscious of it, and strive to avoid it.

Jonathan Babcock (bold is ours)

OK, now we’ve got your attention. Go check it out.

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:

1. User adjusts price discount on product.
2. System updates product price on quote.
3. System updates subtotal price (for all products) on quote.
4. User requests recalculation of shipping and taxes.
5. 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.