Combining Lean Startup and Scrum

By Roman Pichler, 27th June 2013

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 creating new products within existing businesses.


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. Product discovery includes determining the product's value proposition, choosing the right market segment, and selecting its business goals and underlying business model. Product development means identifying the right user experience (UX) and main features, selecting key technologies and architecture patterns, and incrementally building a first product that is good enough to be launched. The following picture shows this approach. Combining Lean Startup and Scrum The process above tries to combine the strengths of the two models: Lean Startup is great in my opinion 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.

Product 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. Start by creating an initial product strategy, for example, by using the 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. Risk-based Product Strategy Validation

Discovery is a team sport. As the person in charge of the product, you hardly can identify and address all the risks and make the right decisions on your own. You will therefore benefit from the support of the stakeholders. These include development team members,  and representatives from other business groups, such as marketing, sales, support, legal, and finance. You may also want to have a ScrumMaster or coach who facilitates and helps with the process. The dev team members help you assess the technical feasibility of the product, identify and address technical risks, and build prototypes. The picture below shows a sample discovery team. To determine the right discovery team members for your product, identify who the key stakeholders or players are.

Product Discovery Team

Product Development with Scrum

Once you are confident that there is a problem that’s worthwhile addressing, the focus changes to developing the actual product. 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 product discovery work to create an initial product backlog and bootstrap the Scrum process. The new focus requires adapting the team composition: The dev team members should stay and the marketer, sales and service representatives leave. But the latter should continue to participate in the development effort as stakeholders and regularly attend 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 incrementally develop the product. The picture below shows this approach. Product Development with Scrum Finally, as you make progress with your development work, don’t forget to prepare the product launch. Having a marketer present at the sprint review meetings should help, but you may find that you need to be actively involved in preparing and executing the launch.

Bringing It All Together

The following table summarises my recommendations for transforming an idea into a shippable product:
Focus Discovery with Lean Startup Development with Scrum
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 Product backlog, product increments
Sample activities Observation, problem interviews, competitor analysis Designing, programming, testing, product demos, user tests, early releases, launch preparation
Team composition Product owner, sales rep, marketer, service rep plus UX designer and developer Product owner plus cross-functional development team
Summary
Article Name
New Product Development with Lean Startup and Scrum
Description
This article describes how combining Lean Startup and Scrum can help you create new products.
Author
Pichler Consulting

Learn More

You can learn more about product discovery and strategy development with the following:

Source: http://www.romanpichler.com/blog/combining-lean-startup-and-scrum/

RSS Feed

12 comments on “Combining Lean Startup and Scrum

  1. Susma

    Hi Roman,
    I landed to article from a reference in your article about checklist for a product owner before starting a sprint and with the title of the aticle, I had expected some details on how long to follow lean start up methods and switch to development sprints. I understand some people talk about sprint 0 but sometimes the starting phase may really take some time. Some inputs on a good way to distinctly divide the steps would have been great.

    Thanks,
    Susma

    • Roman Pichler

      Thanks or you comment, Susma. Unfortunately, I cannot state a specific timeframe, such as one sprint, as the problem validation or product discovery work required does vary. It depends on the innovation type and product life cycle stage, as I explain in my book Strategize. In sum, the more uncertainty and change is present, the more validation work is required. This ranges from a few days to several months. Hope this helps!

  2. Mark

    Just a read a very interesting article about how a company can be considered lean if its improvement efforts result in layoffs? Michael Ballé, PhD answers this frequently asked question drawing from his own experience dealing with organizations. http://www.planet-lean.com/the-layoffs-taboo

    • Roman Pichler

      Hi Mark, Thanks for your comment. I believe that the goal of any improvement effort should ultimately be to help a company create more value and not to lay people off. As far as I know, the term “lean” was coined to refer to an environment where wasteful work (Japanese muda) is eliminated, overburden (muri) is avoided, and unevenness (mura) in the work is reduced thereby creating a smooth, levelled workflow. Hope this help.

  3. Scott Cable

    Hi Roman,

    I came across your very interesting article last year. A similar distinction between the problem domain and the solution domain can be found in npd literature – between the “fuzzy front end” and the “execution-oriented back-end” – see Menor, L. J., Tatikonda, M. V., & Sampson, S. E. (2002). New service development: areas for exploitation and exploration.

    • Roman Pichler

      Hi Scott, Thanks a lot for your feedback. I am glad that you like the post. Thanks also for the reference. I don’t view problem and solution validation are not phases or stages in the traditional sense with a hard stop such as a milestone or gateway. They can overlap and form a continuum. Does this make sense?

      • Scott Cable

        Understand and agree with the continuum point – the domains I mention describe biases or orientations in terms of the activities executed, rather than discrete phases with a hard stop or transition or gateway. And sure, there can be overlaps, as well as reversal in direction.

  4. Shannon Lewis

    This is an excellent article. I could have used this when I was working to redefine the new product idea process back in the old “waterfall” days. One thing we found very important is treating all product ideas equally. All too often “pet projects” would have different rules than the rest of the world and were funded too long and cost the company time and money. Having set criteria that all projects have to follow is key to success. I wrote about how I changed the new product idea process back in the waterfall days. If you think this might be interesting you can find the blog here: http://www.panopticdev.com/blog2014/optimizing-your-new-product-idea-pipeline/

    Where does the financial analysis come into play in your model?

    • Roman Pichler

      Hi Shannon, Thanks for your feedback. I am glad that you find my post useful. I view financial analysis is part of creating and validating the business model. Does this make sense?

      • gokhan

        I am curious about the same.

        Because product owners replace inbound product managers, right? if so, they should be able to build business cases. Am I wrong?
        Calculating NPV, ROI or IRR sometimes?

        Thanks

        • Roman Pichler

          Hi Gokhan, Thanks for your comment. I agree that product owners should take charge of the business model (possibly with the help of people form other business groups such as finance).

          How you define and measure value depends on your product, your business model, and your organisation. I like to use my GO product roadmap to formulate product goals and metrics/KPIs: http://www.romanpichler.com/tools/product-roadmap/ If, for instance, the goal of the first product version is to acquire customers, then ROI would not be an appropriate KPI. Does this help?

  5. sherine

    Nice creation for developing an innovative new product development with lean start up and scrum.

Leave a Reply

Your email address will not be published. Required fields are marked *