RE: [agile-usability] RE: The customer is always right
- Excellent analogy. I guess what is tripping people
up here can be illustrated by extending your analogy
just a bit: Instead of dealing directly with the
architect you have somebody representing you. You say
you want a fairly "open" house. That representative
portrays that to the architect (incorrectly) that you
want an "open-space" house, taking things further than
you had intended. Now, this architect, who has been
around for a while, is questioning if that is really
what you would want.
Like I said in an earlier post, it is the duty of the UCD person (or in
this case Architect) to question customer requests if they seem wrong.
This is especially true if the UCD person (Architect) is not talking
directly to the customer, but is going through an intermediary. In a
case like that, the UCD person (or Architect) should probably request to
talk directly to the customer in order to clarify this particular point.
But consider a scenario like this. The customer actually WANTS a TOTALLY
open space house and says so to the intermediary. The intermediary
conveys that to the Architect. The Architect questions that and asks to
talk to the customer directly to clarify. They meet, and after much
discussion, and iterative drawing of alternative floor plan with
feedback from the customer, the Architect realises that the customer
actually DOES want an open space house with no walls whatsoever between
the kitchen, dining room and living room. The Architect finds it butt
ugly and is convinced that it will be completely disfunctional, but
that's what the client wants. What's the Architect to do in this case?
The answer should be clear. He who pays for the work gets the last word.
The disconnect comes when somebody who "represents"
the end user(not to overload customer, as Jeff P
says), pushes through "requirements" that are really
not beneficial to the end user or what they would
want. I imagine in my mind a manager type pushing not thought-through
requirements, but I know that I am guilty of it as well.
This comes back to what Jeff P was talking about earlier, i.e. there is
a mismatch in terminology between the Agile world and the UCD world when
we talk about the customer.
In the Agile world, by customer we mean the person or organisation that
comissioned the work. Let's call it the Project Funder to avoid further
confusion. In the UCD world, it seems to me that many practitionners
define the customer as the people who will be using the software. Lets
call those the Product Users.
The needs of the Project Funder overlap widely with the needs of the
Product User, but they are not one and the same. In fact, sometimes they
are in opposition. For example, most Product Funders (MS in particular)
would love to forever lock Product User into using their line of product
and not be able to migrate to products of their compw etitors. But
obviously Product Users feel differently. What do you do in such a case?
Againk, the answer should be obvious. He who pays for the work gets his
- --- In firstname.lastname@example.org, Adrian Howard <adrianh@q...>
> [snip]Having a separate UCD process also interferes with one of the core
> This, I think, is why I worry when the stock answer to integrating
> UCD into agile practices is that the UCD person sits in the
> customer role.
> It becomes harder for the developers to get to grips with the
> stories because they're out of the loop when it comes to the design
> decisions that helped shape those stories. It also seems to
> encourage more up-front design than I think is necessary in an agile
benefits of Agile development: Continuous Scope Management. In my
experience the worst result of big up-front design is that it produces
product bloat and creates expensive, monster applications of which
major portions are not used. More importantly, it delays user
feedback from working software that can guide the development team to
producing the highest-value portions as quickly as possible.
The key tool to avoid this is to get the whole team working on finding
simple implementations that meet the essential business objectives.
That is what splitting cards is all about: Look for the 20% subset of
the card that gets the essential business value, split it out to an
early card, and get as much basic functionality into the users' hands
as quickly as possible. This accelerates the feedback loop and
permits prioritizing the remaining cards based on business and user
Take the old XP mantra: Do the simplest thing that can possibly work.
Add to it: defer the rest to another iteration.
and make sure that the "customer" understands the basis for
prioritizing the cards, and this will accelerate delivery.
gastles (at) projectcards (dot) com