Can Lean Startup and Scrum be combined? And if so, how do they fit together? This post shares my answers for blending the two models, and it maps out a high-level process for product discovery and product development.
The Big Picture
How can Lean Startup and Scrum fit together? I find it helpful to use the former to discover if there is a problem that’s worthwhile addressing and to employ Scrum to develop the actual solution. Discovery, in this sense, includes determining the product’s value proposition, choosing the right market segment, and selecting its business goals and underlying business model. Product development entails identifying the right user experience (UX) and features, selecting the technologies and architecture patterns, and incrementally building a first product that is good enough to be launched. The following picture shows this approach.
The process above combines the strengths of the two models: Lean Startup is great for testing out different ideas and discovering if there is a need for a new product; Scrum offers an effective framework for developing digital products including roles and responsibilities, artefacts, and coordination and planning practices—think of the product owner role, the product backlog, and the sprint review meeting.
Note that there is an overlap between discovery and development in the picture above, as I find it helpful to start some of the development activities, such as addressing key UX and technology risks, once the value proposition and market have been determined. Let’s now look at the two parts in more detail.
Problem Discovery with Lean Startup
Discovering if there is a real need for a new product requires creating a valid product strategy—figuring out the market or target group, the problem the product should solve or the benefit it should provide, the product’s key features that create the desired value and make it stand out from the crowd, and the business goals—the desired business benefits it should offer.
A great way to do this is by creating an initial product strategy using my Product Vision Board. Then select the biggest risk: the uncertainty that must be addressed now so that you don’t take the product in the wrong direction and experience late failure. Next, determine how you can best address the risk—for instance, by observing target users and interviewing customers. Carry out the necessary work and collect the relevant feedback or data. Then analyse the results and use the newly gained insights to decide if you should pivot, persevere, or stop—if you should stick with your strategy, change it, or no longer pursue your vision. Follow this process until no crucial risks are left—or until you have run out of time and money. The following picture summarises the process, which is based on Eric Ries’ build-measure-learn model.
Any form of discovery is best done collaboratively. By involving development team members and key stakeholders—representatives from other business groups, such as marketing, sales, support, legal, and finance—you benefit from their knowledge and creativity, and it makes it more likely that you create a shared strategy that everyone supports. Additionally, you may want to involve a ScrumMaster or coach who facilitates the meetings and helps with the process, as shown in the picture below. To determine the right people for your product, identify who the key stakeholders or players are.
Product Development with Scrum
Once you are confident that there is a problem that’s worthwhile addressing, the focus changes to developing the actual solution. This includes understanding what the desired user experience should be, what functionality the product should provide, and how it should be built. Use the insights from the discovery work to create an initial product backlog thereby bootstrapping the Scrum process.
The new focus requires adapting the team composition: The dev team members should stay and form the core of the Scrum development team. The stakeholders should also continue to participate in the development effort and regularly attend product strategy and roadmap review meetings as well sprint review meetings. New developers, testers, and other people required to create a great product are added to the development team. Together, you test out UX and feature ideas, and you incrementally develop the product. The following picture shows this approach.
Bringing It All Together
The following table summarises my recommendations for transforming an idea into a shippable product:
|Key questions to answer||What problem does the product solve? Who are the customers and users? What are the desired business benefits?||What is the right user experience? What functionality should the product provide? How is the product built?|
|Sample artefacts||Product Vision Board, Business Model Canvas, or Lean Canvas, throw-away prototypes (pre-launch MVPs), spikes||Product backlog, product increments, release burndown chart|
|Sample activities||Observation, problem interviews, competitor analysis, and other problem validation activities||Designing, programming, testing, product demos, user tests, early releases, launch preparation|
|Team composition||Product owner, key stakeholders, and representatives of a cross-functional development team.||Product owner plus cross-functional development team|