--- In email@example.com
, Adrian Howard <adrianh@q...>
> 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
Having a separate UCD process also interferes with one of the core
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