Geeks With Blogs
Robert's Blog ideas about design and development

In the Agile thought-space, Big Up Front Design (BFUD) is a four letter word. There is a reason for this.

Many times people who envision projects (usually the guy with the biggest wallet unfortunately) don't realize that they don't know everything. More to the point, they don't know how little they actually know about the end user. So they envision the initial requirements for the system, and they boil them down into finer and finer grained detail, until they have something that is implementable. The problem here is the "grand envisioner" never once left his office to go talk to an end user. He never once drew up a wireframe on a paper napkin from a McDonald's bag on the job site of the end user.

As a personal rant to designers and developers everywhere, get out of your head and get into the real world!

If you don't ever meet the user in their office, you are doing the developer equivalent of making a custom tailored suit from fuzzy photographs from a single vantage point. You need to get into the room with the user and size them up if you are going to make good software.

So alot of people adopting Agile see design as a dirty word. Why? Because their formerly waterfall way of doing things didn't incorporate the use of an HCI specialist or user interviews, or the design was too cumbersome. Waterfall, like anything else, can work well, but only if done correctly. The danger with waterfall is of course that the climate will change and what was agreed upon won't be what is needed when it is delivered. This can happen even if the waterfall organization has a HCI team on staff. Why? Because the full beast as it was envisioned may take two years to deliver. A lot can change in two years. Users needs can and will change while you are building software. Agile tries to embrace this. Designs that keep work from getting done because of their inertia are just bad in principle.

I've had a lot of personal experience with people having issues with Agile design (especially technical managers and system architects). Why? Because it is not the same as not-Agile design. Not-Agile design is a thought exercise that only the really cool people get to do (the guy with the big wallet always thinks he's cool-makes me wonder if Bill Gates has seen a picture of himself lately). Agile design is more of an exercise in communication that all parties involved can and must participate in even the lowliest developer.

Good software is organic. The Mythical Man Month says as much. So how do we know when to stop adding fertilizer and when to stop pouring the water? That's simple, when people stop being interested in new developments in the process, or when you start to experience diminishing ROI. Limiting scope is a bogus concept if you ask me and usually amounts to making an irreversible decision (because that scope limitation is usually expressed in a contract, and what's on paper might as well be set in stone in a corporate environment, that's why some people advocate ripping up story cards after the iteration, but I digress..).

Prioritization should limit scope, not a decree on some piece of paper. Once again we must remember that Agile is here to embrace change.

So what needs to be in place for Agile design to happen? Here's my answer:
  • You must be able to communicate effectively and entertain ideas you don't like.
  • You need to get the "envisioner" to stop trying to own the design after the initial idea has been hatched.
    • Don't even get me started on why feelings of individual ownership are bad.
  • You need at least one representative end user on your customer team
    • You can substitute near continual feedback from beta testers or other representative users for this.
  • You must deploy early and often
    • It is better if this deployment is live, but a private beta should suffice in most cases.
  • The old school designers need to let everybody else play
    • I have personal philosophical issues with the term "System Architect", but if you have one they need to understand their new role is more of a commentator than a director now. A kind of tough sell if the architect is your boss.

Need some guidance? Go read User Stories Applied or a book on Agile Modeling then figure out what works for you. I personally like Joe's idea. A week for user acceptance testing in each release might not be ideal, but at least it lets the people doing the acceptance testing know when their presence is absolutely required.

Posted on Wednesday, July 9, 2008 2:14 PM Agile , Design | Back to top

Comments on this post: Design is not an Agile dirty word

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Robery Stackhouse | Powered by: