The Right Team
A key piece of advice in the book is that you need to have a decider. Someone must represent the organization’s point of view, have the authority to assign resources and headcount, and possess the political capital to make it so. This is vital so the sprint team doesn’t get stuck, wondering whether an assumption or approach is acceptable.
Sprint provides advice relating to the specific roles that should be part of a sprint team. The team comprises just seven committed people. While that may seem small, the approach does encourage inclusiveness. One of the first things a sprint team does is to bring in subject-matter experts (SMEs) on day one to learn as much about the problem space as they possibly can.
But how many people should contribute—and how much of their time? While it’s important to try to get as much input as possible, the authors are not so rigid about the process that they require a minimum amount of time per contributor. They even provide an example where an SME dropped in on a sprint session for just a few minutes—not even long enough to sit—but the team realized that her contributions were invaluable to significantly reframing their understanding of the problem, simply by virtue of the insights they gained from her position in the organization.
The Value of Sketching
In the UXD program at Kent State and in my consulting, we stress the importance of sketching to express ideas. As I take a look at my bookshelf, I see a number of books on UX design that discuss sketching and drawing as an important foundational exercise in designing experiences. Unfortunately, many people are a bit self-conscious about their skill level in drawing.
Sketching is really nothing more than expressing ideas without words. It’s thinking with pencil and paper. Sketching is as a very efficient way of describing relationships and processes. Sprint encourages the use of sketching to develop new ideas and stresses the need to iterate. The best way to get good ideas is to have lots of ideas, then select the best ones. One of the questions people often have is how to start sketching. Fortunately, the authors provide a logical, structured method of using sketching to understand the problem a team is solving, develop ideas, and diverge, then converge on possible solutions.
Prototyping and Testing
The word test actually appears on the book’s dust jacket. If that’s not a clear enough endorsement of the value of prototyping and testing, I’m not sure what would be.
For example, the authors describe in detail how a sprint team for a traditional bricks-and-mortar company had competing ideas for launching a new ecommerce site serving a discrete market. This was a company that really knew its product and had a strong reputation among its customers. However, using the sprint process, they discovered early on that their assumptions about how people selected products was wrong. When they presented their prototyped ecommerce site to customers, they were surprised that customers saw the traditional version of their design, which was evocative of the bricks-and-mortar store’s design and branding, as less desirable. While we may know our business and products very well, it’s almost impossible to truly understand the viewpoint of customers until we test with them.
So this sounds great for a Silicon Valley startup or a retailer moving into ecommerce, but how about an industrial, business-to-business firm? Could you prototype and test complex, highly technical products in a five-day timeframe? Yes and yes. The authors present an example of how the sprint process worked for Graco, a company specializing in fluid-handling products such as industrial pumps and paint sprayers. Graco was introducing a new industrial pump for use on assembly lines—a complex product that would take more than a year to design, engineer, and manufacture, as well as significant funding. Graco hypothesized that a sprint might help derisk the project, by ensuring that the product would be relevant to their customers. In five days, the team used the sprint process to answer the question of whether the product concept had a good chance of succeeding, including a creative approach to prototyping and testing.
It’s Not a Recipe Book
Of all the books I’ve so far reviewed for UXmatters, I think this one offers the most content that you can apply within a week of finishing the book. But don’t let the book’s user-friendly presentation fool you. Putting the book’s methods and exercises to use probably won’t work perfectly the first time. It takes practice. Your sprints are likely to be effective, but they may not be textbook examples.
The authors acknowledge this through their examples of the sprint method’s not quite working. Sometimes they didn’t have the right people in the room or didn’t quite understand the problem. This certainly helps the reader to recognize that having flexibility and taking the opportunity to learn are always helpful to solving problems.
In the last several years, I’ve noticed that authors whose works appear in the “Business” section of book stores and libraries are more often using the language of design and User Experience. I think this shows that UX matters to businesses and their strategies. (See what I did there?) User experience and design are emphatically not just about making pretty Web sites and advertisements. The research methods we use, our focus on customer empathy and ideation, and our outcomes-based approach to solving problems deliver real value to organizations.
The sprint process the book presents is all about aggressively attacking problems, but doing so using a disciplined approach that minimizes risk to an organization. The method’s emphasis on speed and cost control make it an approach that all organizations and managers should welcome.
Sprint delivers a right-sized approach to solving business problems and presents the values and methods of User Experience in a business-friendly format that dispenses with UX jargon. Remember the usability principle avoid jargon? The authors make the processes and benefits of User Experience and Design more accessible to nonpractitioners. Even if your colleagues don’t know the finer points of User Experience, they can appreciate and probably apply the approaches that Sprint describes.