When Agile and User Experience Click
Published: January 21, 2013
Try this test: Find three UX friends and ask them about the compatibility of UX design with agile development. Odds are that one of them believes UX design and agile can work well together, one swears that they can’t, and one has yet to decide. There are many reasons for the divided opinion on this issue.
In the same way that consumers’ experiences are highly contextual, no two software development teams are the same. They may vary in their composition, experience level, the proximity of their members, and their organizations’ willingness to embrace agile development methods. To be successful, it is necessary to apply strategies that best serve our team’s context. In this article, we share our recent experience trying to make UX design and agile click by examining the design and development of the Android app Find MyHeadset™ and highlighting the strategies and activities that we found most helpful.
We design software for Plantronics, a global leader in high-performance, audio communication devices. One of the company’s most popular product categories is the compact Bluetooth headset. While these devices vary in their styling and feature sets, they come in a single size: extra small. Not surprisingly, they are easy to misplace. In May 2012, Plantronics formed a team to address this common problem.
Find MyHeadset is a mobile app for the Android platform that helps Plantronics customers locate their missing headsets. The app gives people two methods of finding their lost headset, as shown in Figure 1. If a missing headset is powered on and in range of its paired smartphone, a user can have the headset emit a tone to reveal its location. If a missing headset is powered off, out of range, or has no battery charge, the BackTrack feature lets users retrace their steps by displaying the most recent headset events and their corresponding locations. After four months on the market, customers have downloaded Find MyHeadset over 40,000 times and awarded it a 4.5-star rating on the Google Play Store.
Figure 1—Find MyHeadset app helps people find a missing headset
The Find MyHeadset project was the first official agile initiative at Plantronics. The eight-member team was geographically distributed, with User Experience, Product Management, and Quality Assurance (QA) located in Santa Cruz, California, while Development and additional QA team members were nine time zones away in Eastern Europe. Team members’ experience with agile varied, ranging from extensive to none. The team adopted a Scrum approach and executed two- to three-week sprints to develop the application. We completed development in four months, launching Find MyHeadset on September 17, 2012.
Advice Worth Heeding
Both prior to and during the Find MyHeadset project, our team benefited greatly from advice and experiences shared by the global UX community. In turn, we’d like to share the strategies and activities that contributed to the success of Find MyHeadset in the marketplace.
Follow Jeff Patton’s 12 Best Practices for Agile UX
Jeff Patton’s 12 best practices  should be required reading for any agile UX team that wants to sidestep the inherent challenges of designing in an agile development context. On the Find MyHeadset project, our team benefited from two of these best practices in particular:
- Use a RITE (Rapid Iterative Testing Evaluation) approach to iterate on concepts prior to development. Although planning and implementing this approach can be challenging, its benefits make the effort worthwhile. For three of the five sprints on the Find MyHeadset project, we dedicated a day to usability testing concepts for future sprints. More than once, the results from these rapid tests led to significant changes that directly improved the user experience of the final product.
- Prototype in low fidelity. Low-fidelity prototyping was critical to our conducting effective evaluations of our design patterns and workflows. By beginning with sketches like those shown in Figure 2, then progressing to mobile wireframes in a tappable PDF format, the Find MyHeadset team was able to collect highly relevant usability data that helped shape the architecture, functionality, and content of the final app.
Figure 2—Creating sketches
Create a Holistic UX Workflow for an Application
Both Nielsen  and Gothelf  emphasize the importance of a UX team’s developing and maintaining a holistic vision for an application. Without a clear vision, an agile project can quickly devolve into an incoherent collection of features and functionality that are driven solely by the prioritized user stories for each sprint.
For Find MyHeadset, we created a UX flow diagram to map out the core elements of the application and communicate our vision. While such a master plan may seem counter to an agile process, this holistic view helped the team understand what we were creating and how things were supposed to fit together.
In an agile development context, the key to creating an effective UX workflow is to keep it lean and incomplete, as shown in Figure 3. Focus on the portion of the workflow that supports the current sprint’s user stories without losing sight of the overall vision. In our case, each iteration saw the flow diagram expand and adapt to reflect the parts of the app that we were targeting during a specific sprint. Because we updated our flow diagram regularly throughout the entire development cycle, it served as an evolving blueprint that QA could rely on to conduct its testing.
Figure 3—Maintaining a lean UX workflow
Get Ahead of Development During a Sprint Zero UX Design Phase
Creating a holistic UX workflow and vision for a product doesn’t happen overnight. Depending on the scope of a project, it can require significant time at the front end of an agile project.   Some people argue that a Sprint 0 design phase simply amounts to a waterfall approach, in which the UX team completes its design of an application up front. Others acknowledge the value of a Sprint 0 design phase, but question just how far in advance User Experience needs to design prior to embarking on a first sprint.
On the Find MyHeadset project, prior to the first sprint, the UX team dedicated two weeks to ideating on design concepts, exploring workflows relating to the app’s two primary features—Send Tone and BackTrack—and conducting internal design reviews. This effort permitted team members to effectively plan the first sprint and establish a design framework that provided a foundation for detailed design during subsequent sprints.
Stay Ahead of Development by Dedicating Time for UX Design for Future Sprints During the Current Sprint
Agile planning tools can help UX teams stay ahead of Development, but UX designers must ensure that they attend to designs for future sprints even when the current sprint is demanding most of their attention. On the Find MyHeadset project, we earmarked 30–40% of each sprint for detailed design and testing of user stories for future sprints. Ideally, we would have allotted even more time. More than once, our cushion evaporated, and we failed to stay ahead of Development. Had the project been any larger in scope, we would have needed to implement a design spike  to get ahead of the Development team once again.
Partner Closely with the Product Owner
User stories are at the heart of an agile process. They drive what a product is supposed to be and do to meet the needs and goals of target users. Product Owners usually write the majority of user stories and own the responsibility for prioritizing them. By collaborating well with the Product Owner, a UX designer can directly influence the user stories and, in turn, help define the product.
According to Patton , “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.” On the Find MyHeadset team, User Experience and the Product Owner regularly worked together to groom the backlog of user stories and ensure that their details and acceptance criteria were compatible with the holistic design vision for the app.
Figure 4—Collaborating on user stories and UX design specs
Schedule Dedicated UX Reviews with the Team as Part of Sprint Planning
When agile teams are entirely colocated and members are working in close proximity, they can communicate their ideas and solutions without additional effort. For distributed agile teams, however, you must take extra steps to avoid communication problems and delays. For the Find MyHeadset project, a regularly planned review of the UX design spec prior to each sprint planning meeting quickly emerged as a requirement for success.
The spec review helped the team visualize the stories that we had prioritized for the next sprint and understand the level of effort the proposed solutions would require. It also provided team members with an opportunity to give us their input and ensured that we gave them the extra details they needed to identify relevant tasks and make accurate work estimations.
Determine the Appropriate Level of UX Design Documentation for Your Team
A common misconception about agile development is that documentation should be eliminated. This is especially untrue for projects with distributed teams, where members must make independent progress asynchronously. While it may be possible to reduce the formal documentation a project requires, it’s still necessary to record detailed interaction design decisions to ensure clear understanding among team members.
Our perspective on this is counter to Gothelf’s  view that a prototype is the documentation on an agile project and anything more is wasted effort. On the Find MyHeadset project, adopting an “it is what it is” approach to documentation would have made it very difficult to build and test the app effectively.
Mature organizations such as Plantronics often have intensive QA programs that rely on documented design details to build their testing protocols. From the outset, our team chose to follow Govella’s  advice to implement well-annotated wireframes instead of producing heavy documentation. Publishing our specifications online made them easy to update and distribute to all team members. We simply emailed team members a link to the current version and provided a clear revision history.
Figure 5—Providing specifications for our distributed team
Extend Your UX Team to Include Front-end Development
Team members who can play multiple roles on an agile project help increase the speed of iterations. When a UX designer can work directly with the code to complete front-end development work, Development team members can take on other tasks.
On the Find MyHeadset project, User Experience took responsibility for much of the presentation layer by working directly on branched code once the Development team had built the foundation. This permitted us to modify, review, and iterate on the design by creating our own builds and reviewing the latest code on demand. For a distributed team, even daily builds can be too infrequent to ensure rapid progress, so having User Experience assume some degree of ownership over front-end development can help a team to achieve a higher-quality result in less time.
More Work Ahead
On the Find MyHeadset project, our team discovered multiple strategies that made UX design and agile development click. However, we also identified several challenges with which we continue to wrestle:
- What is the best way to effectively manage certain UX roles such as visual design and user research that tend to experience peaks and valleys of intensity during a sprint?
- How can we optimize collaboration and productivity among the members of our distributed agile team?
- How can we meet our team’s desire to be lean and take risks within a culture that prides itself on avoiding failure through detailed execution and testing?
We need to address these challenges and others before we can realize the full potential of agile development. As the UX community shares more examples of successful projects like Find MyHeadset, we’ll all become more confident—and perhaps less divided—about the compatibility of UX design and agile development.
 Patton, Jeff. “Twelve Emerging Best Practices for Adding UX Work to Agile Development.” Agile Product Design, June 27, 2008. Retrieved December 9, 2012.
 Nielsen, Jakob. “Agile User Experience Projects.” UseIt, November 4, 2009. Retrieved December 9, 2012.
 Gothelf, Jeff. “Lean UX: Getting Out of The Deliverables Business.” Smashing Magazine, March 7, 2011. Retrieved December 9, 2012.
 Walker, Mat. “About Agile, UX, and Sprint 0.” MatWalker.co.uk, January 17, 2011. Retrieved December 9, 2012.
 Dimmick, Damon. “Fitting Big-Picture UX into Agile Development.” Smashing Magazine, November 6, 2012. Retrieved December 9, 2012.
 Govella, Austin. “Agile + UX: Six Strategies for More Agile.” Thinking and Making, May 7, 2008. Retrieved December 9, 2012.
Thanks to Paul Bryan and Philip Hodgson for reading an early outline of this article.