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
<A HREF="http://en.wikipedia.org/wiki/Halting_problem">
   the Halting Problem</A>.

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
<A HREF="http://groups.yahoo.com/group/extremeprogramming/">
   XP discussion list</A>
recently.
<A HREF="http://jchyip.blogspot.com/">
   Jason Yip</A>
read Barry Schwartz's April 2004 Scientific American article
<A HREF="http://www.sciamdigital.com/browse.cfm?sequencenameCHAR=item2&methodnameCHAR=resource_getitembrowse&interfacenameCHAR=browse.cfm&ISSUEID_CHAR=2EBEBB1D-2B35-221B-60A43B4557AEA06A&ARTICLEID_CHAR=3D505772-2B35-221B-60F4B6448AEBF867&sc=I100322">
   The Tyranny of Choice</A>,
which is based on his popular book
<A HREF="http://www.amazon.com/exec/obidos/tg/detail/-/0060005688/qid=1104954338/sr=8-1/ref=pd_csp_1/002-0139064-8652065?v=glance&s=books&n=507846">
   The Paradox of Choice</A>.
Schwartz argues that there exists something of a
<A HREF="http://en.wikipedia.org/wiki/Laffer_curve">
   Laffer curve</A>
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.
<A HREF="http://www.artima.com/weblogs/index.jsp?blogger=mfeathers">
   (Mike Feathers</A>
made a similar argument on the discussion list.)

Of course, when developing software in a more traditional way,
<EM>someone</EM> 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 <STRONG>feel</STRONG> 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 <EM>tricked</EM> 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 <EM>for</EM> agile methods
than a case against them.  It underscores one of the great
strengths of the agile approaches: an <STRONG>attitude</STRONG>
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.
-----