TITLE: Trust and the Tyranny of Choice AUTHOR: Eugene Wallingford DATE: January 05, 2005 2:36 PM DESC: The "paradox of choice" says that our customers may prefer if we weren't quite so agile. What can we do? ----- BODY: When I'm out shopping for any big-ticket item, such as a car, I am notoriously slow to pull the trigger. I can be just as slow on even relatively inexpensive items like stereos, or snack food. My wife long ago learned to give me time, to walk off and let me stew a bit, before putting any pressure on me to make a decision. But she also learned that without such pressure I may never decide to buy or not. Talk about the Halting Problem. What's the cause of my shopping behavior? Perhaps I'm prone to regret and am trying to protect myself from that gnawing feeling that I've made the wrong choice. Having even a few alternatives makes my choice difficult. (To be honest, I think I worry about feeling regret at having spent the money at all, which just makes me cheap. :-) Difficulty making choices has been a thread over on the XP discussion list recently. Jason Yip read Barry Schwartz's April 2004 Scientific American article The Tyranny of Choice, which is based on his popular book The Paradox of Choice. Schwartz argues that there exists something of a Laffer curve at work when it comes to the psychology of decision making. Having few or no choices gives people little opportunity to control their destinies, which often results in being disappointed with how things turn out. Having many choices gives people a feeling of control but increases the probability of making the wrong choice, which leads to regret. Schwartz points out that regret tends to make people more unhappy than disappointment. From this, he concludes that having too many alternatives is actually worse for people than having too few. Jason raised Schwartz's thesis in the context of customer choice in XP, brought on by an earlier thread about optional scope contracts. He asked if anyone had observed the "tyranny of choice" phenomenon manifest itself as resistance to more flexible approaches to defining project scope. We can frame the question even more broadly, as XP offers many choices in the release and iteration planning phases of a project that customers may not be used to. The resulting thread of discussion offered several interesting takes on this idea. Check it out. When I'm doing XP, my customers face a somewhat different situation than I do when I'm buying a car. Customers tend to make their choices as part of a longer-term relationship, and the new choices XP gives them are more about ordering the steps of the project than selecting only one from a set of alternatives. If they make a choice they regret, they will have a chance to re-prioritize requirements when helping to plan the next release. As a result, their regret will tend to be short-lived and more about short-term opportunity cost. (Mike Feathers made a similar argument on the discussion list.) Of course, when developing software in a more traditional way, someone is making all these choices, though often it is the technical team. You'd think that customers would be no worse off making their own choices, even if they come to regret them, than by having some programmer make the decision in his cubicle one night. But that's the vexing part of Schwartz's thesis: They feel worse off in regret at their decision than they do in disappointment at the programmer's. Knowing this, agile developers can play a valid role in helping their customers make choices. When they see a customer having difficulty setting priorities, they can inject some of their professional experience into the mix. Telling customers how past projects have gone may help them set a priority for the current release. Reminding them that they will have a chance to guide the project's course again at the next release or iteration may help them avoid paralysis motivated by fear of regret. Some folks on the XP list offered some fun little strategies for helping break a deadlock in decision making. For example, if the customer says that all features are equally important, try selecting what seems to you to be the least valuable feature as the first one to implement. Sometimes, that's enough of a push to get the customer to think he can do a better job than you and so choose. I'm guessing that it's especially important to manage expectations in this scenario -- you don't want the customer to think you tricked him into making a choice he ultimately regrets, because then he'll be saddled not only with regret but also a distrust of you. And trust is essential to a good working relationship, especially in an agile approach. For me, this brings to mind my younger daughter. Since she was a toddler, she has generally had trouble deciding, whether the choice is among alternatives for dessert, or outfits to where, or whether to ride home in the car with mommy or daddy. (Like many other families, we often end up in the same with both cars!) Instinctively, I've always tried to reassure her that her decision isn't the Final Answer, that if she later wishes she'd chosen ice cream for dessert, well then, we can just have ice cream tomorrow. That hasn't always seemed to help, at least not with the choice at hand. But I think that it's a good way to approach the situation: don't put undue pressure on her, and help calm her fears -- whether of regret or of disappointing me, which sometimes seems to be a factor in her decisions that I didn't expect. Building a relationship in which she can trust me is the best I can hope for in helping her learn to choose. And, as she's gotten older, she has become a more confident decision maker. Back to software: Ultimately, I think that the "paradox of choice" phenomenon is more a case for agile methods than a case against them. It underscores one of the great strengths of the agile approaches: an attitude toward job and customer based in respect, trust, and communication. When we value these ahead of hard-and-fast rules and ahead of "the process", we are able to adjust our approach to the particulars of the customer and the current project. -----