- LEAN Sprint: Move Your Business Model Forward [Book Excerpt] - August 23, 2016
- Business Model Test by Ash Maurya [Infographic] - July 13, 2016
- How to Embrace Failure and Succeed [Book Excerpt] - June 20, 2016
This excerpt shows you how to utilize a LEAN sprint and is a follow-up to “How to Embrace Failure and Succeed,” published on StartupNation.com on June 20, 2016.
Below, find an exclusive excerpt for StartupNation.com, excerpted from SCALING LEAN: Mastering the Key Metrics for Startup Growth by Ash Maurya, with permission of Portfolio, an imprint of an imprint of Penguin Publishing Group, a division of Penguin Random House LLC. Copyright © Ash Maurya, 2016.
Chapter 10: Avoid the Curse of Specialization
We’re highly prone to subconscious biases when devising solutions to problems we’re eager to solve. While the GO LEAN framework helps you expose the “right” problems or constraints to tackle, your strategies are still vulnerable to the innovator’s bias. In my Lean Canvas case study from the last chapter, for instance, given our problem of a low user activation rate:
- My developers wanted to build more features,
- My designers wanted to improve usability, and
- My marketers wanted to optimize landing pages and run ads.
Different team members will see different solutions to the same problem based on their specialized training. This is the innovator bias at work. It is a problem only if you limit the diversity of ideas. In order to achieve breakthrough, you have to continually tap into a large source of new ideas.
The real answer to the question, “Where do good ideas come from?” is that good ideas can come from anywhere. The challenge, of course, is that good ideas are rare and often indistinguishable from bad ideas at the beginning.
So you need a robust process that on the one hand allows you to source a large diversity of ideas, and on the other hand lets you quickly distinguish good ideas from bad ideas. This chapter will show you how to do this using LEAN sprints.
What is a LEAN sprint?
A LEAN sprint is a time-boxed iteration cycle for sourcing, ranking and testing new ideas for moving your business model forward, that is, for breaking constraints and increasing customer throughput. Simply put, LEAN sprints help you implement the GO LEAN framework across your team.
The right time box for a LEAN sprint is determined by the stage of your product and the size of your team. I recommend starting with two-week sprints and adjusting from there.
The sprint start and end are marked by two meeting ceremonies: the sprint planning meeting and the sprint review meeting. This is where the team comes together to plan strategy and experiment-level activities and share results. During the sprint, the team also meets regularly to coordinate task-level activities using a short daily stand-up meeting.
One of the things you might have immediately picked up on was the number of meetings during sprints. I know the last thing you want is more meetings. However, meetings run well create time-boxed opportunities for focused conversation—which is key to success.
Most meetings don’t work because:
- There isn’t a set agenda. While the reason for a meeting might be known in advance, most meetings just go with the flow, which sometimes, but not always, leads to actual progress being made. Like the interview scripts in Running Lean, LEAN sprint meetings are driven by a metascript designed to accomplish certain key learning objectives.
- There isn’t enough active participation. There are usually just one or two people doing most of the talking, while everyone else listens. LEAN sprint meetings are hands-on and require everyone’s participation.
- There’s isn’t enough original thinking. When HiPPOs and peers bias meetings, they can quickly devolve into groupthink. LEAN sprint meetings use an align-diverge-converge design thinking technique, developed at IDEO, for fighting groupthink and enabling original thinking.
How is the LEAN sprint different from an agile iteration or a scrum sprint?
If you come from a software background, you have most likely been exposed to the scrum/agile methodology, and would have noticed several similarities between a scrum sprint and the LEAN sprint. LEAN sprints are heavily influenced by agile and scrum practices, like the meeting ceremonies, but there are some key differences.
- The goals are different. While the goal of a scrum sprint is demonstrating “build velocity,” the goal of a LEAN sprint is demonstrating “traction velocity.” It is not enough to build a great product or feature during an iteration, or just to demonstrate learning. You have to build, measure, learn, and demonstrate how your product or feature affects one or more of the key levers for traction.
- The participants are different. Scrum and agile are typically developer-only practices. LEAN sprints, on the other hand, require the complete team, including your internal and external stakeholders.
- Time-boxing does not dictate build or release cadence. I am still an advocate for using kanban (or just-in-time) techniques for continuous delivery. Time boxes in a LEAN sprint are used only to force a decision and do not drive the release cycle. You can still choose to practice continuous delivery or a more traditional schedule-based release cycle as you see fit.
How is the LEAN sprint different from a design sprint?
If you come from a design background, you have most likely been exposed to the design sprint created and popularized by Google Ventures.
Design sprints also draw from the agile framework but incorporate design thinking techniques to help teams solve design problems in five days. Cross-functional team members are recruited from across the organization and then spend five intense days working on the design problem through lots of brainstorming, rapid prototyping and user testing. At the end of the sprint, winning solutions are decided and handed off to implementation teams. The sprint team is then disassembled.
While LEAN sprints also draw inspiration from several design thinking (and design sprint) techniques, they are intended for more general problem/solution exploration. The activity cadence is also “less intense” on the teams. Unlike with design sprints, the goal isn’t assembling a short-term SWAT-style team that comes together to solve a big problem one time. Rather the goal is assembling a long-term product team that continually solves big problems from one sprint to the next.
The five stages of a LEAN sprint
There are five stages to running a LEAN sprint. These stages use overlapping align-diverge-converge cycles to provide the right balance between individual thinking and group collaboration:
- Expose Problems: What is the constraint? The team comes together in a pre-sprint meeting to align around a common understanding of the business model constraints.
- Define Solutions: How might we break this constraint? The team then diverges to individually generate solutions captured on one or more Validation Plans.
- Short-list Solutions: Select the best strategies. These solutions are then shared, ranked, and short-listed in a sprint planning meeting that officially kicks off the sprint.
- Test Solutions: Test the strategies with experiments. The team diverges again to test these solutions.
- Decide on Solutions: Decide next actions. Results are analyzed and next actions decided in a sprint review meeting. The cycle then repeats.