Including Concept development in Agile

The following are excerpts from Bringing User Centered Design to the Agile Environment, an article by UX designer Anthony Colfelt on http://boxandarrows.com.
My own writing is enclosed in [].
The best way to read this article is to visit the actual article, which includes diagrams by the author.
---

Where did Agile come from?
Envisioned by a group of developers, Agile is an iterative development approach that takes small steps toward defining a product or service. [Scrum is one of several agile methodologies]

Why do people rave about it?
1. In theory, software can be released earlier.
2. Generates momentum with manageable deadlines.
3. Steers the team away from Feature bloat.
4. Encourages contribution from different perspectives, which is usually good for resolving issues.
[+ from the youtube video introducing scrum: Task completion times are efficiently managed.]

The Minefield
Mine 1: An unclear role for design
[Agile Manifesto says:] “Business people and developers must work together daily throughout the project” is another principle of Agile. Where does the designer fit into the frame?

Mine 2: The requirements gathering process is not defined 

Agile, made from the perspective of a developer, tends to shoe-horn design 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 

Implementations of Agile that put design activities within the same iteration as they must be developed, ensure designs are achievable in code. But they also put tremendous pressure on the experience design team to ‘feed the development machine’ in time enough for them to implement their vision.

Mine 4: The temptation to call it “good enough” 

Invariably when we have release-ready working code at the end of each cycle, even if it’s sub-optimal, there’s a strong temptation to release it because we can.  

Mine 5: Insufficient risk-free conceptual exploration time 

Iteration “zero” (i.e. a planning and design iteration prior to the first development iteration) can be used to do this and other planning activities. However, depending on how long this iteration is, the level of rigor applied to exploration may be insufficient. 

Mine 6: Brand Damage

Non-researched solutions might lead to the wrong product.When a company releases a flawed product or service, then their image in the customers mind (i.e. brand) is tarnished. Brand damage takes far longer to mend than it does to make.

Agile is good for refining, not defining.
[...]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.

User Centered Design
UCD requires iteration – design, test with users, refine, test with users again, refine… repeat till it’s right. This is where Agile and UCD can work brilliantly together. Agile really is about presuming you’ll need to change things, and that’s a good thing when it comes to refinement.

Uncovering requirements to form a strategy
User Centered Design (UCD) is not about answering requirements alone, but also includes defining requirements....[but sometimes lacks a realistic execution plan. This shortcoming can be addressed by combining UCD with Agile.]

The best of both worlds
UCD can be too documentation-heavy, isolated and risky but Agile needs help with defining requirements and concept development. How can Agile and user centric principles work together?

A shared vision of the interaction fundamentals
In good software development, a conceptual interaction model that has been thought through beforehand, outlines how the user navigates the system, performs tasks and uses tools in generic terms, i.e. not each and every navigation label, task or tool but rather the interface and interaction patterns that will persist. Risky interfaces that are new or significant improvements on what has been seen before, are best tackled as design-only activities in a sprint prior to when they will be developed (i.e. do involve developers, don’t try to produce code). This circumvents the pressure to deliver something before proper thought, reflection and user testing, which ensures you’re not wasting time and effort.

Conclusion
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.

---