RE: [agile-usability] Re: The customer is always right
MessageTo 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.-- Alain:I couldn't agree more and that's why I really like the WholeTeam approach taken by XP.Note that in my experience, whenever there people feel the need to "push their own agenda", it's because the decision is neither purely technical nor purely UX. It's a decision that has implications on both, and therefore, both sides need to sit together, understand the impact on each other's agenda, and come up with a decision that achieves an appropriate balance point between the two. Note that this may not always be a win-win situation (although your first reflex should be to look for a win-win situation). In most cases, one of the agenda or both will have to suffer a bit.----
- --- 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