- Yes, I like this differentiation, and in Cooper s Inmates book he goes to great lengths to point out that business folks (funders) know what is viable, butMessage 1 of 49 , Jul 21, 2005View SourceYes, I like this differentiation, and in Cooper's "Inmates" book he goes to great lengths to point out that business folks (funders) know what is viable, but not necessarily what is useful. He goes on to say that a smart business will understand this, and delegate their decision making authority to a UX designer whose job it is to find out what the user wants.To me, part of the answer to this whole problem lies in the fuzzy world of human-human interaction.I have worked with good agile teams where the everyone has the courage to push their agenda when appropriate, and has backed down when appropriate. Meaning, that the UX person pushed her agenda when the decision was UX related, and the developer backed down, but the developer pushed his agenda when the decision was technical, and the UX person backed down.I have also seen a QA person completely change a feature because when it came time to 'review' what the UX person had planned, her strong personality pushed hard for something she liked, and the UX person, being timid, gave way. The company's "process" called for UX to set the direction and development/QA to review. What actually happened, is UX made a proposal, and then it changed until development/QA approved.We often like to look at these these problems from a mechanistic perspective because we hope to control a situation using some kind of process/system/technique. However, if a business person or developer have an ego problem, and other team members are "courage deficient" the team/product is going to have problems no matter what system/hierarchy you put in place.- Rob
"Desilets, Alain" <alain.desilets@...> wrote:
> One point that I don't think has been raised here, is that a
> software `product' may not only have one customer.
Yes. Part of the problem here is that there is an XP jargon term
"customer", which is generally not the person who pays for and uses the
software. In a lot of environments, "product manager" is the correct
term for what XP calls the "customer".
Agile Customer = Project Funder = Group of people who pay for the
DEVELOPMENT of the software
UCD Customer = Project User = Group of people who USE (and possibly, but
not always, BUY the software)
As developpers, we report to the the Project Funder, and therefore our
PRIME concern is to satisfy the Project Funder's needs.
Of course, unless the Project Funder is completely clueless, satisfying
his needs will mean we have to pay a lot of attention to the needs of
the Project User. But the Project Funder needs to be in charge, not the
- ... Having a separate UCD process also interferes with one of the core benefits of Agile development: Continuous Scope Management. In my experience the worstMessage 49 of 49 , Jul 26, 2005View Source--- In email@example.com, 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