by Jeff Gothelf
Agile methods are mainstream now. At the same time, thanks to the huge success of products like Amazon’s Kindle and Apple’s iPhone, so is User Experience (UX) design. But making Agile work with UX continues to be a challenge for many companies. In this chapter, we review how Lean UX methods can fit within the most popular flavor of Agile—Scrum—and discuss how blending Lean UX and Agile can create a more productive team and a more collaborative process. Here’s what this chapter covers:
Definition of terms
Just to make sure we’re all on the same page when we say certain words like “sprint” and “story.”
Staggered sprints
The once-savior of Agile/UX integration is now just a stepping stone to true team cohesion.
Sprint zero and design sprints
How much, if any, upfront work should we do?
Dual-track Agile
How to plan product discovery activities along with delivery.
Listening to Scrum’s rhythms
The meeting cadences of Scrum make for clear guide posts for Lean UX integration.
Participation
A truly cross-functional process requires that everyone be a part of it.
Design is a team sport
Opening up the design process to all team members.
Coordinating multiple Lean UX teams
How to encourage sharing and reduce duplicate work.
Managing up and out
Clear obstacles to your team’s progress by being proactive with your communications.
Let’s get started.
Some Definitions
Agile processes like Scrum use many proprietary terms. Over time, many of these terms have taken on a life of their own. To ensure that the way we’re using them is clear, we’ve taken the time to define a few of them here. (If you’re familiar with Agile, you can skip this section.)
Scrum
An Agile methodology promoting time-boxed cycles, team self-organization, and high team accountability. Scrum is the most popular form of Agile.
User story
The smallest unit of work expressed as a benefit to the end user. Typical user stories are written using the following syntax: As a [user type]
I want to [accomplish something]
So that [some benefit happens]
Backlog
A prioritized list of user stories. The backlog is the most powerful project management tool in Agile. It is through the active grooming of the backlog that the team manages their daily workload and refocuses their efforts based on incoming learnings. It is how the team stays Agile.
Sprint
A single cycle of work for a team. The goal of each sprint is to deliver working software. Most Scrum teams work in two-week sprints.
Stand-up
A daily, short team meeting during which each member addresses the day’s challenges. This is one of Scrum’s self-accountability tools. Every day, members must declare to their teammates what they’re doing and what’s getting in their way.
Retrospective
A meeting at the end of each sprint that takes an honest look at what went well, what went poorly, and how the team will try to improve process in the next sprint. Your process is as iterative as your product. Retrospectives give your team the chance to optimize your process with every sprint.
Iteration planning meeting
A meeting at the beginning of each sprint during which the team plans what they’ll be doing during the upcoming sprint. Sometimes, this meeting includes estimation and story gathering. This is the meeting that determines the initial prioritization of the backlog.
Product discovery
A term used to describe any learning activities the team undertakes to help them determine what to deliver. Lean UX powers the product discovery process.
Sprint zero
This is the time before product delivery begins that many organizations set aside for product discovery. It can extend beyond one sprint. Our goal is to ensure that, even if you’re using the sprint-zero model, it is not the only time that testing, learning, and validation take place.
Design sprint
A term popularized by the design team at Google Ventures used to describe a time-boxed collection of collaborative activities that help a team move quickly from ideas to prototypes. Running a design sprint as “sprint zero” is an increasingly common practice.
Dual-track Agile
Popularized by product management guru Marty Cagan, dual-track Agile is an attempt to build a continuous product discovery and delivery model for Scrum teams. It champions a process in which teams manage two backlogs—a discovery backlog and a delivery backlog. They work through their discovery backlogs with only validated items graduating into the delivery cycle. In many ways, if executed well, this is the end state most teams should strive for; however, it is not without its challenges.
Staggered Sprints and Their Modern Offshoots
In May 2007, Desiree Sy and Lynn Miller published “Adapting Usability Investigations for Agile User-centered Design” in the Journal of Usability Studies.1 Sy and Miller were some of the first people to try to combine Agile and UX, and many of us were excited by the solutions they were proposing. In the 2007 article, Sy and Miller describe in detail their idea of a productive integration of Agile and User-Centered Design. They called it cycle 0 (though it has come to be referred to popularly as either “sprint zero” or sometimes “staggered sprints”).
In short, Sy and Miller described a process in which design activity takes place one sprint ahead of development. Work is designed and validated during the “design sprint” and then passed off into the development stream to be implemented during the development sprint, as is illustrated in Figure 7-1.
Figure 7-1. Sy and Miller’s “Staggered Sprints” model
Many teams have misinterpreted this model, though. Sy and Miller always advocated strong collaboration between designers and developers during both the design and development sprints. Many teams have missed this critical point and instead have created workflows in which designers and developers communicate by handoff—creating a kind of mini-waterfall process.
Staggered sprints can work well for some teams. If your development environment does not allow for frequent releases (for example, you work on embedded software, or deliver software to an environment in which continuous deployment is difficult or impossible),2 the premium on getting the design right is higher. (In these cases, Lean UX might not be a great fit for your team because you’ll need to work hard to get the market feedback you need to make many of these techniques work.) For these teams, staggered sprints can allow for more validation of design work—provided you are still working in a very collaborative manner. And teams transitioning from waterfall to Agile can benefit from working this way, as well, because it teaches you to work in shorter cycles, and to divide your work into sequential pieces. However, this model works best as a transition. It is not where you want your team to end up.
Here’s why: it becomes very easy to create a situation in which the entire team is never working on the same thing at the same time. You never realize the benefits of cross-functional collaboration because the different disciplines are focused on different things. Without that collaboration, you don’t build shared understanding, so you end up relying heavily on documentation and handoffs for communication.
There’s another reason this process is less than ideal: it can create unnecessary waste. You waste time creating documentation to describe what happened during the design sprints. And, if developers haven’t participated in the design sprint, they haven’t had a chance to assess the work for feasibility or scope. That conversation doesn’t happen until handoff. Can they actually build the specified designs in the next two weeks? If not, the work that went into designing those elements is wasted.
Evolving the Design Sprint
These days, the term “design sprint” has taken on a new
meaning. The term is now associated with the ideas in the book Sprint by Jake Knapp, John Zeratsky, and Braden Kowitz (Simon & Schuster). They describe a design sprint as a way to bring together all the key stakeholders on a new project or initiative. Working closely together over the course of five days, this cross-functional team brainstorms, iterates, and works their way through a series of ideas. The week culminates with a prototype. In most cases, the resulting prototype has even had a round or two of customer research applied to it.
This is a technique that we’ve used many times in our own practice (based on the time-honored Design Studio method, described in Chapter 4). It is highly effective at bringing together a diverse set of colleagues, exposing their assumptions and biases about the business problem at hand and injecting these opinions with a dose of market reality. In our experience, the ideal result of a design sprint is a backlog of hypotheses. This prioritized list of risks defines the work that the team must continue to validate throughout the project lifecycle. Design sprints also help us to better define the scope of our work—at least for the foreseeable future—allowing teams, both in-house and consulting, to provide their stakeholders with a more accurate timeline for product launch.
There are a few pitfalls to watch out for when running a full five-day design sprint:
Use them on the right projects
Ensure that the problem space you’re exploring is big enough to warrant putting your entire team in a room for five days. New projects, initiatives, or business lines are worthy of this process. Smaller changes to existing workflows might be too small to warrant a full design sprint.
Keep the team size small
Design sprints are touted as a great tool for collaboration. This is true, but collaboration can get diluted if too many people are involved. Run these sprints with the core team and their immediate stakeholders. Try to keep the participant number to about 10 people.
Adapt the recipe to your needs
There are many detailed descriptions of exactly how to facilitate a design sprint. These are phenomenal resources for early practitioners of this technique. But don’t become stuck following the rules. As you gain experience with design sprints, ask yourself which elements of the design sprint add value given your current project and time constraints, and which can be discarded to save time.
Learning doesn’t end at the end of the design sprint
Design sprints are exciting, high-energy bursts of work. But it’s hard to sustain that energy. We’ve seen teams emerge energized and motivated to get building. But learning shouldn’t end when the design sprint ends. As the product progresses and evolves, new questions will come up, and they require further discovery. Ensure that elements of the design sprint make their way into future sprints so that your team doesn’t end up implementing blindly.
Dual-Track Agile
In many ways, dual-track Agile is what Sy and Miller were trying to convey with their staggered-sprint model. Marty Cagan, Jeff Patton, and others advocate for a process in which a single team manages two backlogs: a discovery backlog and a delivery backlog. The team splits into two units to do the work: a discovery unit and a delivery unit. The discovery unit works through the discovery items, running experiments and speaking to customers in an effort to discover which ideas merit further exploration and which don’t. Ideas that graduate from discovery to delivery are built by the delivery unit of the team. This reduces the amount of documentation necessary to drive the delivery process because the people who validated the feature are in close contact with, or in some cases are, the same people who design and implement it. Figure 7-2 offers an overview of the process.
Figure 7-2. Marty Cagan’s dual-track Agile process diagram (image courtesy of Marty Cagan)
Theoretically, dual-track Agile promises to manage learning and delivery in a transparent way. It allows the team to prioritize their work based on evidence while using that same evidence to provide their stakeholders with regular updates, directional shifts, and data. In practice though, we’ve seen teams hit the following speed bumps:
Separate discovery and delivery teams
One antipattern we’ve witnessed several times is teams splitting up who does the discovery and who does the delivery on their team. Often the UX designer and/or the product manager take on the bulk of the discovery work. The engineers are delegated early delivery work. This effectively recreates the mini-waterfalls of staggered sprints, as described earlier. The shared understanding breaks down, slowing the pace of decision-making and reducing the team’s cohesion, productivity, and learning. Our recommendation is to have as many team members involved in discovery as possible, especially early on in an initiative, so that the core decisions about your project are made with everyone’s participation. As the project continues, there will certainly be situations in which not everyone is available for research work. In these cases, those who do the research are responsible for bringing it back to the team as soon as it’s over and discussing their findings while they’re fresh.
Limited knowledge of how to do discovery
Building a dual-track Agile process assumes that your team knows how to do discovery. There are many tools that you can use to build feedback loops into a discovery backlog. Without a broader knowledge of these tools, teams resort to the ones they’re most familiar with, and often pick suboptimal tactics for learning. If you have access to researchers, try to add them to your team. At the very least, seek out their input as new discovery initiatives begin. Seasoned practitioners can teach your team the best method for your needs and can help you plan your discovery work.
Not feeding back evidence from the delivery work to the discovery backlog
This challenge is symptomatic of an organization that is still thinking incrementally. After a feature makes it from discovery to delivery, the team will implement it as designed and ship it. The great thing about that is that, as soon as it’s live, this new feature begins to provide a new set of data about how well it’s working and where to focus your next discovery activities. Ensure that your team is continuing to collect feedback on shipped features and using that information to regularly assess the prioritization of their discovery work.
Exploiting the Rhythms of Scrum to Build a Lean UX Practice
Over the years, we’ve found some useful ways to integrate Lean UX approaches with the rhythms of Scrum. Let’s take a look at how you can use Scrum’s meeting cadence and Lean UX to build an efficient process.
Themes
Scrum has a lot of meetings. Many people frown on meetings, but if you use them as mileposts during your sprint you can create an integrated Lean UX and Agile process in which the entire team is working on the same thing at the same time.
Let’s assume that you’ve chosen a risky hypothesis as the early focus of your project. You can use that hypothesis to create a theme that guides the work you’ll do over the next set of sprints, as demonstrated in Figure 7-3.
Figure 7-3. Sprints tied together with a theme
Kick Off the Theme with a Design Sprint
Start work on each theme with some version of a Design Studio or design sprint. (See Figure 7-4.) Depending on the scope of the hypothesis, the design sprint can be as short as an afternoon or as long as a week. You can do them with your immediate team but should include a broader group if it’s a larger-scale effort. (See Chapter 4 for details on how to run a Design Studio.) The point of this kickoff is to get the entire team sketching, ideating, and speaking to customers together, creating a backlog of ideas from which to test and learn. In addition, this activity will help define the scope of your theme a bit better—assuming that you’ve built in some customer feedback loops.
After you’ve started your regular sprints, your ideas will be tested, validated, and developed: new insights will come in, and you’ll need to decide what to do with them. You make these decisions by running subsequent shorter brainstorming sessions and collaborative discovery activities before each new sprint begins
. This allows the team to use the latest insight to create the backlog for the next sprint.
Figure 7-4. Timing and scope of design sprints
Iteration Planning Meeting
Bring the output of your design sprint to the iteration planning meeting (IPM). Your mess of sticky notes, sketches, wireframes, paper prototypes, and any other artifacts might seem useless to outside observers but will be meaningful to your team. You made these artifacts together and because of that you have the shared understanding necessary to extract stories from them. Use them in your IPM to write user stories together, and then estimate and prioritize the stories. (See Figure 7-5.)
Figure 7-5. Hold iteration planning meetings immediately after brainstorming sessions
Experiment Stories
As you plan your iteration, there might be additional discovery work that needs to be done during the iteration that wasn’t covered in the design sprint or collaborative discovery activities. Or, there might be work in your discovery backlog that you know is coming up that needs to happen by a certain time frame. To accommodate this in your sprint cadence use experiment stories. Captured by using the same method as your user stories, experiment stories have two distinct benefits:
They visualize discovery work
Discovery work is not inherently tangible as delivery work can be. Experiment stories solve that by leveling the playing field. Everything your team works on—discovery or delivery—goes on the backlog as a story.
They force its prioritization against delivery work