Originally published: Aug 01, 2008
In the best teams, the UX folks have an active hand in deciding what is built, the overall business strategy that drives what's built, and the tactical prioritization of work done first. In some successful Agile organizations the UX team is the Agile customer team or product owner team.
For UX practitioners not familiar with the terms 'customer' or 'product owner' in the Agile context, they refer to a process role and not necessarily the actual customers who purchase a commercial product. However there is a bias in Agile environments to get end-users more frequently and directly involved. Do this also. More on that in #6.
In spite of what a dogmatic Agile trainer may tell you, companies that are successful at incorporating UX work and Agile do some up front user research and modeling that results in things like personas, workflow models, task analysis grids, or even something like Indi Young's Mental Models.
However, they have learned how to compress the timeframe for this work by:
Since the UX team is ideally part of the customer/product owner team, they have a hand in determining an incremental release strategy -- that is determining what coherent collection of features to release first. Leveraging this understanding, high level scenarios and/or wireframes are usually built to communicate screen flow, general look and feel, and general user interaction patterns.
All this research, modeling, and high level design often occurs in weeks, not months. Organizations, such as Yahoo, have been effective at packaging and leveraging user research across projects to shorten the time between initial concept and beginning construction. UX practitioners should leverage the time while the organization is finding production staff, such as developers and testers, to begin their research and modeling.
Some Agile teams use "iteration 0" or "sprint 0" to mean a first development timebox that they set aside for this initial research. They also use this time to get the development environment setup and ready to go and do some initial architectural prototyping or "spiking" -- the rough equivalent of high-level design from an architectural perspective. For years now, I've done a quick treatment of user centered design modeling to build a backlog and plan initial product releases.
Once high-level research, modeling, and design is done, it's time to start construction.
Construction in Agile development is done in small chunks usually called user stories -- or bits of functionality valuable and demonstrable from a user's perspective. This can be a problem for designers because they need to guess what the stories will be, then later design their interaction and look, in sync with development. Hopefully, the high level design has left us with a bit of a "sketch" of how thing might look and a high level roadmap of where the software is going functionally. We don't want to be flying too blind.
The idea of "chunking" or breaking down work into coherent chunks that can be both designed, build, and validated somewhat independently is both art and skill. Some take apart their high level sketches of the software and chunk a screen or screen-component at a time. I work using the "user task" as a building block layering in functional user tasks into the system one at a time. When a system begins to mature functionally, chunks begin to take the form of adjustments and refinements to existing software.
I believe most UX practitioners are afraid of building something akin to the Winchester Mystery House. It's not an unfounded concern. But, given a high level sketch of the design, some practice at chunking, and some course correction along the way and things tend to come out OK.
Chunking work into small bits turns out to be difficult for everyone. Developers new to Agile have difficulty with it. Business people or product managers have difficulty in breaking their system down into small parts that can be considered independently. And over time Agile practitioners have recommended breaking functionality down into smaller and smaller parts.
Lynn Miller of Alias, now Autodesk's Toronto office, first described the pattern of parallel track development in her 2005 paper, Case Study of Customer Input For a Successful Product. For Alias's Sketchbook Pro product, she described the emerging pattern of the Agile customer team working ahead one or two timeboxes to research or design what will be built in future development time boxes.
It's actually a bit more complicated than that. The design team works ahead a development time-box or two. In a given timebox they might be:
User experience people working on Agile teams become masters of development time travel nimbly moving back and forth through past, present, and future development work.
At times, it takes more time to design and validate a feature. That next Agile development timebox is coming whether you want it to or not. Ideally developers will keep working on software while design and design validation is ongoing. To buy time, it's common to have chunks of work that are technically complex, but trivial from an interaction design perspective. In her paper, Lynn described starting development work on Sketchbook Pro by beginning the construction on the feature that saved drawings as layered PhotoShop files. From the user interface, it's a simple "file, save as" menu choice, but from the development perspective, it was heavy lifting. Having the development team work on this very important feature early bought designers time to get ahead.
I used to have a friend in the newspaper business. Newspapers release every day whether writers are ready with stories or not. One of the things she did was keep stories sitting around that she called "evergreens." These were stories that stayed fresh -- stories that she could put into the paper at any time to fill space. Interaction designers would do well to identify work that's "evergreen" -- work the team can do any time, but that buys time to do the time-sensitive design or design-validation work.
Many times now, I've seen the pattern of UX people building up a pool of users they collaborate with to validate design before and after it's built. This pool of users needs to be large enough that the designer doesn't call on the same user repeatedly every week, but talks with them every month or two. My friend Heather described what she calls "development partners" at Elsevier. Desiree Sy describes design partners in her paper on Agile User-centered design.
Organizations, like Salesforce.com, keep a continuous flow of users scheduled to validate design work. I've seen many instances of users scheduled for remote usability testing or site visits well in advance of knowing what will be being tested. The one thing you can depend on in an Agile context is that there will always be something.
[In Part 2, we'll look at tricks for scheduling continuous user research, using the RITE method, and becoming a design facilitator, as we continue with Jeff's 12 best practices.]
If you're a user experience professional working inside an Agile development team, you'll want to check out Jeff's virtual seminar Story Mapping for UX Practitioners: Tying Agile & UX Together.
Are you working to improve the user experience in Agile development projects? What practices have you found to work (or to avoid)? Share your thoughts with us at our Brain Sparks blog.
Read related articles: