Wednesday, January 3, 2007

User-Centered Design and Agile: Why Can't We Be Friends?

On the surface, it would seem that an analysis methodology such as user-centered design and a software development methodology like agile would be incompatible. User-centered design, after all, tends to rely heavily on research and documentation, identifying user tasks, goals and objectives as they relate to a software or web application. Agile software development is about delivering useful, functional software as quickly as possible. In other words, UCD wants to take its time to fully understand the road that lies ahead while agile is at the starting line with the engine revving ready scream down the highway.

It may seem as though I am criticizing agile development, but I'm not. In reality, both methodologies share a lot in common. Richard Cecil in a recent blog post discussed how these methodologies can co-exist to produce useful, functional software and web applications without stepping each other's toes. As an advocate for the end-user, I feel user-centered design and its many research methodologies are the best tools to support their needs. Research should be done before design and development begins. As Cecil reports in his post;

If we're defining users' needs during development - even in an agile development process - something has gone horribly wrong.

Once I read that, it took me back to my schooling in instructional design (basically, it's the 50-cent phrase for saying training development). As I was taught, the development of training can follow a simple model called ADDIE - analysis, design, development, implementation and evaluation. You can't do the "D-D-I-E" without doing the "A" first. If you do not who you are designing and developing for and the rationale behind your efforts, all of your work will likely be in vain.

I was recently asked by an executive of a software company if UCD and agile can co-exist. My answer was yes - I believe it can only if there is a mutual understanding between the two teams the the overall goal is to build to the end-user's needs. Much of that understanding comes from putting yourself in the shoes of the other person, whether it's the UCD researcher (user advocate) or the developer. The beauty of the two methodologies, in my opinion, is that it affords these concessions. The challenge to the UCD professional is to stay one or two steps ahead of the development team out of respect for the timelines established in agile.

No comments: