The customer is always right
Suppose the customer asks you to make the main window un-resizable.
Make its geometry static and repress the grab handles on its window
Maybe the customer (a marketing department) thinks they target the
RealPlayer / Windows Media / Musicmatch Jukebox theme, where a
user-friendly software program impersonates a user-hostile hardware
gadget. These rock-n-roll skins are indeed resizeable, but the
customer doesn't realize that. They want the chic, even if your
program has lots of business data to display in grids that should
Agile theory says you code directly to the immediate requirement, and
deliver the request. This increases the odds marketing can ship your
product, and they can relax their Illusion of Control and allow actual
usability leadership (from the end users and, natch, from you) to take
- --- 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