Agile development originated from a place where user experience practice was weak

In my last blog essay I explain how I see that the type of product we build has big effect on the process we follow to build it. In the lower left of my simple 4 quadrant model I place software built internally for use by an organization where usage is mandatory for its target users. I explained that this is where Agile processes originated from. I also explained that strong user experience practice rarely exists here. If your company is an exception, I’d love to hear from you. But, given this starting context where user experience practice isn’t well understood, no one should be surprised that user experience practice isn’t well understood in Agile development – at least not out of the box.

I’m often asked “does user experience practice work with Agile development?” The short answer is: “of course it does!”

After first addressing that question, I need to place the person asking somewhere on my 4-quadrant software context model to do a quick assessment of what life is probably like for them in their company. If they’re in anyplace other than the upper right quadrant, I suspect they’ve worked hard to build up a successful UX practice in their company that works inside their current process – whatever that is.

There’s an important point to understand:

Accept and adapt

In a presentation at a CHI panel discussion from Craig Villamor of salesforce.com, he explained the five phases of agile adoption for user experience people:

1. denial
2. anger
3. bargaining
4. depression
5. acceptance

You may recognize these five phases from someplace else. But, there’s an important point here: if you’re a user experience professional, you will need to adapt your current practice to work within an Agile value system and lifecycle. The sooner you get through the first four phases and begin that adaptation, the better.

My early Agile experience came from the lower right of my diagram: commercial compelled use products. I had real customers that paid my company for our software. That customer base was diverse. We had competitors that we needed to outperform. It was that context and the lack of rigor around user experience that lead me to adopt and adapt user experience practice from Constantine & Lockwood, Cooper, and Holtzblatt & Beyer, and others.

Before Agile my process was a combination of graphic arts skill, hangin’ out with users, and command and control. It worked pretty well. But, a faster paced collaborative Agile world put me in a position where I needed to be more transparent with what I was doing. I needed to collaborate effectively with others. I needed to rally a team to work together to move faster. Agile development isn’t about personal efficiency – it’s about throughput of software and value. My individual ad hoc approaches didn’t scale well. My personal throughput had it’s limits.

In my first Agile environment, I went through Craig’s five phases of adoption. I sometimes forget how miserable my first year in Agile development was. For any co-workers of mine from 200-2001 who might be reading this – I’m sorry for being such a crazy back then.

Eventually I adapted, and I’ve never been more content.

I really loved the control over the development process that Agile brought. Not unilateral command and control, but control that comes from a group of people working productively together showing consistent visible progress, and all enthusiastically working to meet the goals of our customers. Agile development has made me more confident than ever that I’ll get a good product to my users as efficiently as possible.

Best Agile user experience practices begin to emerge

There’s a description of a “pattern” that comes from the design patterns community:

I’ve got lots if ideas on what I think best user experience practice should be like in agile development, and I’m not too shy about sharing them. (Just attend one my tutorials at a conference and you’ll see.) But, I have to admit that they’re my adapted approaches – approaches I adapted for use in my Agile context. They’re not necessarily patterns. Over time I’ve seen a number of common patterns emerge from various successful user experience people across a number of companies. These are UX people that have gone through Craig’s five stages of UX practitioner Agile adoption, and have come out the other end with successful practice, and a real appreciation for Agile development.

Recently I attended a CHI workshop on Agile development and User Centered Design. While listening to this seasoned group of Agile UX people I begin to see patterns of practice both in the room, and that I’d heard before from talking and working with other UX people.

These are the common practices that I observed. I’ll list them here to spare you the suspense then give lots more detail on what I mean below. I’m confident there are lots more – these are just the ones I noticed. Here they are:

I think you’ll see that many of these are good practice, Agile or not.

Also take a look at Austin Govella’s Agile Principles for UX. You’ll see a couple points of overlap, and some different and important points Austin makes.

1. Drive: UX practitioners are part of the customer or product owner team

This means they have an active hand in deciding what is built, the overall business strategy the 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, those terms 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.

2. Research, model, and design up front – but only just enough

 

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 grid, or even something like Indi’s Mental Models.

However, they have learned how to compress the timeframe for this work by:

• aggressively prioritizing the types of users researched to the those that are the highest priority, and shortening the amount of time spent with users of lower priority
• modeling quickly, in a lightweight and collaborative way often involving other team members to help analyze data and construct time consuming models like affinity diagrams
• defer some less urgent research to be completed while the software is being constructed

Since the UX team is ideally part of the customer/product owner team, they have a hand in determining incremental release strategy – that is determining what coherent collection of features 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 research and modeling.

Some Agile teams have used the term iteration 0 or sprint 0 – as a first development timebox set aside for this initial research along with getting the development environment setup and ready to go, and doing 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.

3. Chunk your design work

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 in that we’ve got to plan – to decide what those chunks of work are – 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 & 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.

Desiree Sy has written a good description on how she approaches chunking at Alias (now Autodesk Toronto).

I believe most UX practitioners are afraid of building a [[Winchester Mystery House], and 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.

4. Use parallel track development to work ahead, and follow behind

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 time boxes 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:

• researching work to be done 2 time-boxes from now (T + 2)
• validating design prototypes to be built 1 time-box from now (T + 1)
• being available to collaborate with development to support work done in the current development timebox (T)
• working with customers to validate working software built in the previous time-box (T – 1)

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.

5. Buy design time with complex engineering stories

At times it takes more time to design and validate a feature. That next Agile development time-box 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, Customer Input in Agile Projects, Lynn describes 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 that can be done any time, but that buys time to do design and design validation work.

6. Cultivate a user validation group for use for continuous user validation

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

7. Schedule continuous user research in a separate track from development

For many commercial projects I’m starting to see user research as something that’s considered a separate and continuously running track. User research functions as an independent effort that keeps its activities and schedule transparent. User experience designers working with the development team can help steer future research, and even participate in it in support of what they’re currently working on in development. User research that’s conducted is shared and communicated in lightweight ways with the rest of the team. I’ve seen some UX practitioners using comics to communicate the output of user research rather than dry reports. I commonly see presentations schedule to share-out – or communicate stories about users and research findings with the rest of the team.

8. Leverage user time for multiple activities

In talking with Lynn Miller and Desiree Sy about parallel track development the describe visiting customers and using that time to do some contextual inquiry style observation and interviewing, to then sit down and review a prototype for something that may be built in a future iteration, then to review the working software testing features just built in a previous iteration. The trick here is to leverage that user face time for research and validation. Don’t segregate your work.

9. Use RITE to iterate UI before development

The RITE method – short for rapid iterative testing and evaluation was first described by a game development team at Microsoft. They describe an idea that to many seems common sense.

In more traditional usability engineering it may be common to conduct usability test repeatedly with different subjects on the same software. By doing this you can really prove that usability problems are repeated and actually common across users. The outcome of traditional testing might be a report that communicates problems along with possible solutions.

However, when using the RITE method, we look to get errors out of the software as soon as possible. In between each test the team discusses the problems they observed and how they might fix them. In the original Microsoft report, developers actually went to work correcting problems before the next test subject(s) were brought in. The result isn’t a list of repeated errors and recommendations like standard usability testing, but software that has most of the errors corrected – which is what we wanted in the first placed anyway.

The smart people at salesforce.com have taken RITE and cranked the dials up to 11. They build html prototypes and iteratively test and repair them using remote usability testing. They’ll complete several rounds of this on each chunk of work before it goes into a development time-box. The smart people at Google describe “lunch room testing” – testing paper prototypes of preliminary design during lunch with Google staff at a table setup in the cafeteria.

10. Prototype in low fidelity

When talking to UX practitioners working in Agile environments I continue to hear them describe the lesson learned over spending too much time crafting prototypes. I hear them chant the mantra of staying as low fidelity as possible.

I prefer paper, but I often have the benefit of working with co-located teams and customers/users I can get direct access too. I’ve seen others use PowerPoint and only simple black and white lined wireframes. Some even take the time to use “sketchy” lines to indicate roughness. Others may use html. I recently heard a talk from the designer and owner of dopplr who describes communicating design by sketching on the whiteboard with his developers.

My friend Larry Constantine describes the stuff we build as deliverable and consumable. Deliverable means we have to tighten up and deliver it to someone else. They’ll need to take that work and carry it forward often without us being there. We’re often judged on the quality of that work. But, consumable work on the other hand is the stuff we build for ourselves. This is the stuff we sketch or model to better understand what we’re doing. It only needs to be good enough to understand, to learn, to communicate quickly with our co-workers, then it can be thrown away. In agile development prototypes are consumable.

I also remember a quote from Bill Buxton who said something like: “The idea of high fidelity and low fidelity in prototypes is silly. As far as I’m concerned there’s only right fidelity and wrong fidelity.”

11. Treat prototype as specification

In an attempt to travel light, I often hear UX people describe their prototypes as their specification. It’s common to deliver only the prototype, or ideally the prototype + a discussion with the team building the software. During the discussion annotate the prototype by hand if necessary. No need to produce detailed documentation. In Desiree’s paper she points out a number of different documents that were scrapped in favor of discussions over a prototype.

12. Become a design facilitator

Early in this essay I described my early experience as a designer figuring out what the design should be then simply telling others how to build it, or building it myself. As I’ve begun to work within Agile teams, my approach has changed to favor collaborative design. More and more I find myself acting as facilitator to harvest and model information from large groups of people. I find myself working with groups of users and developers to write user scenarios, and sketch user interface design.

Recently I learned about Adaptive Path’s Sketchboarding approach, and Jeff and Jim’s Design Studio approach used at Jewelry TV. In addition to them being great approaches to increase the number of great ideas and the quality of the resulting solution, they both provide a facilitation structure to allow a number of people to participate in the design process.

To allow user centered design activities:

• to move quickly,
• to keep progress transparent,
• to give everyone in the team an understanding of the design, and
• an appreciation for the process and tradeoffs necessary for a good design,

It’s valuable to turn design activities into collaborative activities involving members of the team.

I often hear UX practitioners working in an Agile context explain to me that a big surprise is how much time they spend facilitating. UX people facilitate not just design sessions, but sessions to communicate test results or field visit results. Desiree describes replacing personas and scenarios with stories about real customers and real use.

Two sure fired ways to succeed in software development

I once introduced Jim Highsmith to the CEO of my company with the hopes that my CEO would hire him to help improve things. Jim has been a long time thought leader in the Agile community. He’s one of the original signers of the Agile manifesto. He was one of the consultants that helped Agile-UX experts at Alias get off on the right foot in 2002. He’s got a clear head. My CEO asked him “We can’t seem to finish anything on time – how do we build software and finish sooner?” Jim responded calmly “start sooner.”

I overheard Jim in another conversation with someone else years later. They were complaining about “getting all this software built on time.” Jim’s response: “build less software.”

Let’s recap. Two secrets to success in software development are:

This is sadly simple advice.

Agile development does try to short-circuit elongated research and design phases in favor of beginning sooner and continuing active research and design throughout the development cycle.

This quote from Desiree Sy of Alias/Autodesk says a lot: “For our User Experience Team, Agile user-centered design resulted in better-designed software than waterfall user-centered design. Agile communication modes narrowed the gap between gathering usability data and acting on it.” Desiree’s talking about her cycle of being able to talk to end-users, interview them or show them prototypes or working software then take what she learns right back to her development team who takes that understanding and acts on in code that she and her team can see days later. Starting sooner and keeping the customer research thread alive and active pays.

On a current project, I’m lucky enough to work with a very talented team practicing Cooper’s goal directed design in an Agile environment. When it comes time for them to describe what to build to the developers they sit down and talk about it in detail with wireframes and screen mockups in hand. I’ve seen many of these conversations and they all go a bit like this. After explain the interaction design to developers they say “Ok, we can do that. It’s going to take a couple weeks, but I was thinking that we could do something like this instead..” An explanation follows. “if we do that I think it’ll still get at what you intended, but we can do that in a few days.”

Building less software does mean keeping your software from being feature rich and quality starved – and it also means collaborating with developers to write a little less code on every single feature you do choose to implement. Sometimes you save a lot of code. Through strong collaboration I see hours, days, and weeks of development time saved every day on healthy Agile projects. For me, that’s the real secret to finishing on time with high quality software.

Don’t neglect ideation

At a recent IxDA conference keynote, Bill Buxton remarked that a problem with Agile development was iterating without ideating. I’m paraphrasing here, but basically Bill asserted that Agile teams lock onto a solution and iterate to refine it without considering that there may be a better solution out there. He’s right, but not just about Agile teams. I see a fair number of designers guilty of the same behavior.

Today it’s easier to respond to Bill’s call to action with some concrete practices like Adaptive Path’s Sketchboarding and Jeff & Jim’s Design Studio approach. Desiree Sy described using interns to prototype 10 or more design solutions to a possible design problem. What’s heartening for me is that Agile development and the desire for collaboration outside the immediate design team has motivated the creation of this type of practice.

Are these Agile UX best practices?

The 12 practices described here are repeated patterns I’ve observed. They’re not hypothetical. They’ve been proven in a number of teams and a number of companies. But, one of the tricky things about any process or practice is that it relies heavily on the context it’s placed in to work. Your mileage may vary with any of these practices.

As I pointed out above, common Agile practice today originated from contexts where UX practice was generally thin to start with. I suspect that it’ll be a few more years before there’s common understanding that we need UX work in every context, some more than others, and that there are common Agile UX practices that should be included in the Agile toolkit.

If you’re a UX practitioner new to an Agile context, I suspect you’ll be feeling some frustration – especially if you’d figured out a process rhythm that was working for you before Agile. Look closely at your company’s reasons for choosing Agile development. With luck they have some good reasons. Then “accept and adapt.” Like many UX people that have come before you, I suspect you’ll find that not only is Agile development not as bad as you though, but that it leads you to a level of process improvement you might not have come to otherwise.

To continue the discussion on user experience and Agile development, join Arlen and me in Seattle

I’ll be at the APLN Seattle Leadership Summit July 17th and 18th. Arlen Bankston and I will be facilitating an all day discussion on how user experience practice best fits into Agile development.