UX specialist Anthony Colfelt presents a case for how agile, alone, might not be sufficient and a thorough and engaging look into how User-Centered Design can, and should, be merged with it.
Colfelt sets up his message asking if agile is well-suited to solving the problem of helping the business know what it wants:
In of itself, Agile does a good job of flexing to the winds of change. But one has to ask whether it was devised to treat a symptom of the larger cause: the business doesn’t know what it wants. While Agile enables the development team to better cope with this, it doesn’t solve the problem and in most cases creates new problems.
He describes a "minefield" of 6 ways he's seen agile fall short in a UX sense:
- "Mine 1: An unclear role for design":
The agile principle stating “Business people and developers must work together daily throughout the project” leaves little explicit room for a UX designer, often leaving the job to developers who are unlikely to possess such skills. - "Mine 2: The requirements gathering process is not defined":
It's not uncommon for agile teams to adopt a "requirements magically fall from the sky" mentality, eschewing efforts spent on outlining strategical product vision as un-agile. - "Mine 3: Pressure to cut corners":
Forcing UX design into the same iteration as it's corresponding development can lead to impulsive design, losing opportunity to test design ideas on user. Of course, agile allows the real thing to be usability tested, but responding to the feedback from this may take more time than you've expected or are comfortable with. - "Mine 4: The temptation to call it “good enough”":
Even (maybe especially) when agile is done well, teams are invariably faced with the need to prioritize 'iterating on existing features to get them right' against 'incrementing new features into the product'. As Cofelt observes:Too often, the rework gets left in favor of exciting new stuff. An so on we go building a product full of features that don’t quite meet the bar.
- "Mine 5: Insufficient risk-free conceptual exploration time":
Many agile teams will just begin building day one of the project (or very close to it). Some may employ an "iteration zero" to do some up-front planning and design. Cofelt asks if this is enough - does the agile approach of using a working example to validate ideas always truly outweigh doing some validation with rough sketches before committing to code? - "Mine 6: Brand Damage":
Putting non-raod-tested (via UX design approaches) features out into the market, even if intentioned to gain feedback, can quickly lead customers to lose faith in your company's ability to consistently hit the mark - this is damage to your brand, something well known to be hard to build and even harder to re-build.
Colfelt makes an interesting summary statement that agile, in and of itself, "is good for refining, [but] not defining". He asserts that agile alone may suffice for "an existing product that you want to develop to the next level", but, particularly when you're starting something new, "some level of plan is necessary to avoid a Frankenstein of each individual’s perspective on the best design solution".
He describes a traditional/"typical" UCD process, focusing the readers attention to its inclusion of upfront research for product "strategy" (he later also talks of this as "Concept Design", drawing on the quintessential iPod example), something he asserts does not become any less important when adopting an agile methodology. He's careful not to say that agile explicitly precludes such upfront thinking, but asks if it provides sufficient explicit encouragement to do it justice.
Ultimately, Colfelt's goal is to raise awareness for how UCD's focus on "strategical"/"concept" discovery can and should be combined with agile's ability to "refine":
In summary, dogmatic attitudes about each of these approaches should be avoided if they are to be combined. Remember, Agile does not mandate how to define concepts or overall design direction, but it is a great way to execute on solid design research and well laid plans. UCD needs to be flexible enough to respond to the reality on the ground when the implementation team encounters issues that mandate a different design solution. Document only what is needed to get the message across and co-locate if at all possible, because cross-disciplinary collaboration and face to face communication are vital. Working a sprint ahead of the development team is helpful in allowing the design team enough time to test and iterate. If these rules of engagement are followed, the two approaches can work very well together.
Reserve some time to read Colfelt's full article before making any hard line judgements. You may also want to check out this related article by Johnny Holland about how the UX designer's job morphs in an agile (Scrum) world, in which he also discusses similar themes of "strategy" but focuses more on interaction with the development team and iteration level activities and dynamics.