I'm taking a stab at answering a question that is becoming quite common these days, "How does design fit into an agile development process?"
Illustration by I, Timmy
I have a decent amount of experience doing UX in "Agile" environments. One thing that's critical to acknowledge is that there is no standard Agile method: every shop uses it's own flavor based on their own adaptation of Agile principles. Even SCRUM is not universal.
Because of this, I look at a continuum between Waterfall and Agile, and try to understand the specific process and rituals of a given shop in order to understand where user-centered design fits, and the gnarliness of the shoehorn that's going to be needed to make it work.
Waterfall versus Agile
At it's basest, Waterfall describes a product lifecycle in which all business and design documentation is compiled and then passed on to the development staff. At this point the effort is sized, and development commences. Timeframes are often protracted. Agile, on the other hand is based on a short-cycle iterative approach with deeply rooted rituals that generate high visibility into the development process. The promise of Agile is a shippable release every 2-3 weeks.
As typically practiced, UX design fits hand-in-glove with Waterfall. The extended requirements gathering period provides opportunity for the business and user requirements to co-evolve very synergistically. Agile, however, espouses very concise, atomic User Stories in the place of standard requirements. Sprints are composed of a rather ad hoc mixture of these Stories. This makes it very challenging to document in typically UI documents such as wireframes and redlined visual specs because arbitrary units may be left out in any given Sprint. Ugh.
Critical to success: global styles
In order to facilitate developers during Sprints, it's critical that you documentation for each Sprint be terse. The best way to ensure that is to pull out all generalizable details and put them in a global styleguide. I am a firm believer in using a wiki for this, and encouraging the developers to contribute to that wiki. Design must own the styleguide, but having devs in there contributing will make it more accurate and up to date.
Draw it all up front (even if you make shit up)
In order to understand the user experience, you have to see it end to end. You can't expect to design something that works well without looking past a single Sprint. This is especially important when looking at the IA and task flow.
If Themes are used within the org you are working with, you basically need to design at that level. Unfortunately, it's likely the Stories for the entire Theme aren't completed, in which case, you need to make some educated guesses (in collaboration with the business owners) regarding the core and outlying usage scenarios. Document your assumptions, and then draw up a high level design. This will be a useful tool for the devs, and it will provide a backdrop for all your subsequent effort.
Keep the developers engaged through this process, but don't let them throw out technical roadblocks. This about getting the user experience right. The Sprint pointing should solve the technical concerns.
User involvement
It's important at this stage to perform some usability, otherwise it's likely you'll be WAY off base. I recommend hallway usability and some paper prototype usability testing sessions. Note: Read the book Paper Prototyping The Fast and Easy Way to Design and Refine User Interfaces ➜➜ if you haven't. It's great.
Iterate your designs as efficiently as possible.
Sprint involvement
Going into Sprint Planning, you should have all the detailed design work completed for the Stories the biz hope to jnclude. Make sure in addition to the standard docs (wireframes & visual spec) you have added Acceptance Criteria to each Story for all user requirements.
The critical meetings for you to attend are the daily SCRUM, Sprint Planning (only when UI Stories are in the queue), and Sprint Review. Sometimes you'll find after a few Sprints that you are not adding value at the SCRUM. This may especially be the case if the UI is less complex than the backend. In these cases, I recommend making an arrangement with the UI developers to follow up offline, ONLY if the SCRUM is taking mire than fifteen minutes.
Photo by Roger Smith
Test usability of the real deal
The beauty of being Agile more than anything is having usable app every few weeks. You should absolutely get it in front of users and get usability data. Include a SUS survey [PDF] after observing them work.
Be prepared to have to redesign and rebuild
As an UX Designer your responsibilty is to ensure an best of class experience. It will not be popular among the devs or biz folk, but at times, you're going to have to iterate your design. This will feel like a kick to many devs because they already built the functionality you specified. To the biz, it's going to seem like time (and obviously $$) wasted. It's important to keep the focus on the user experience, and use as much data as you can gather to support your arguments.
Top risks
Some major challenges are out there for the UX practitioner.
Risk Design documentation is too detailed. This will make it very hard for you to deliver on time, and you'll end up delivering documentation that includes significant sections that end up not included in the current Sprint, causing confusion for the devs and resulting in churn.
Preventative measures Create a deep and broad stylesheet that documents common elements, interfaces and interaction methods. Document functional areas as atomically as possible, allowing for mix & match opportunities.
Risk Code is shipped to end users and critical usability issues cause failed interactions.
Preventative measures Design a fairly detailed mockup early in Theme development and perform hallway usability, create paper prototypes and test them with real customers (or potential customers.) Also, test the hell out of the app when it comes out of a Sprint. You must use it in order to understand the nuances of how it works. Think of it as a UAT opportunity, but also, plan in advance for usability sessions every couple of Sprints. This is a great chance to catch big issues.
Risk Runaway developers hijack the UI and make it yucky.
Preventative measures This is always a risk, but it can be minimized by your working closely with the developers. This should be especially easy to do in an Agile joint, because of the emphasis placed on deep collaboration. That said, it's rarely as easy to ensure as you'd expect. Make sure to raise your hand with issues at the daily SCRUM.
Finally, how I think it really should be
Having worked in both Waterfall and Agile environments, I feel pretty confidently that Agile is actually phooey. I know that's a controversial thing to say when everyone basically has put Agile up on a shelf as the best thing evar. I just don't agree.
I think that what makes Agile work in the places I have seen it work is that there is a development process in place, there is visibility into it by all business, design and tech folks, and releases are pushed in short iterative cycles. That's it! The thing missing is the time to do sufficient design iterations, things end up being sketchy at best.
In the most effective development environments I have experienced, the process has been essentially a fusion of Waterfall and Agile: business and user requirements were completed up front, then implemented through a series of short-cycle iterations with a SCRUM like process. The lead time up front really does improve quality of what's delivered.
