"Agile is good for refining, not defining"
In one of the latest Boxes and Arrows articles User Centered Designer Anthony Colfelt explains which mines you can step on when walking the "minefield" of applying UCD within an Agile project. A brief summary of the mines he describes:
Mine 1: An unclear role for design
Agile methods have originated from development, not design. The role of the designer on a team isn’t very clearly defined.
Mine 2: The requirements gathering process is not defined
“Agile accommodates design activities from the perspective of a developer. It tends to shoe-horn these activities into their view of the world where requirements fall from the sky (from the business or customer who is assumed to be all-knowing) and takes for granted that they are appropriate.”
Mine 3: Pressure to cut corners
As Agile focuses on delivering working functionality fast there is little time to choose between and test out different options and designs before implementing.
Mine 4: The temptation to call it “good enough”
Agile processes focus on delivering ‘potentially shippable’ code. If Product Owners release because they can, then that could mean products get released while the quality is not high enough.)
Mine 5: Insufficient risk-free conceptual exploration time
The focus of Agile on starting development soon leaves little time for Concepting, UX research and designing a vision.
Mine 6: Brand Damage
When releasing too early, the brand identity suffers
One of the main conclusions: "Agile is good for refining, not defining".
If you have an existing product that you want to develop to the next level, then Agile in its truest sense works because you have a base upon which to improve. This means that if you know what your requirements are and these have been properly informed with user research, comparative analysis, business objectives, and analysis of what content you have and what you can technically achieve, then Agile alone can work well.
But spending money on software development without a plan of what to build is like asking a construction crew to erect a tower with no blueprint. Some level of plan is necessary to avoid a Frankenstein of each individual’s perspective on the best design solution.
