Is Scrum Right for Your Product?

By Roman Pichler, 19th September 2016
Photo by Charlotte Coneybeer, courtesy of Unsplash

Scrum offers a powerful way to develop products. In fact, it is often seen as the standard way to create digital products, and I have met more than one company where the product managers were suddenly told to be agile and do Scrum. But like every process, Scrum has its benefits and limitations. Is it the right approach to develop and grow your product? Or would you be better off using an alternative?


When is Scrum Most Helpful?

A process like Scrum is a great fit for your product when it is brand-new or young, and when you extend its life cycle, as shown in the picture below. This means that not every product will benefit from Scrum: Products that are maturing or declining won’t benefit from Scrum—at least not to the same degree.

scrumandproductlifecycle

The picture above shows the traditional, bell-shaped product life cycle curve with three key events: launch—the product first becomes available; achieving product-market fit (PMF)—your product is ready to serve the mainstream market; and end of life—you decide to discontinue the product. Note that your product’s actual trajectory may differ significantly from the one above: it may be much steeper or flatter. In order to leverage the product life cycle model, you have to define the business benefits your product delivers and then track them over time. For revenue-generating products revenue is commonly used, for example. But if your product exists to sell another product or service, then the number of active users might be the appropriate metric. (See my post 10 Tips on How to Choose the Right Product Key Performance Indicators for more information on selecting the right metrics.)

The younger your product is, the more it is likely to benefit from Scrum. Why? When working on a brand-new product, trying to achieve PMF, or struggling to keep the product growing, you typically face many unknowns and a substantial amount of uncertainty and change. You may not fully understand the value it should create for its users and customers, the features and user experience (UX) it should provide, the business goals it should serve and the business model it should use, and the technologies that should be used to develop it. Scrum is a great fit at this stage: Your product will benefit from an iterative, cyclic process that allows you to quickly test an assumption, address a risk, generate new insights, and come up with new ideas. This accelerates learning and mitigates the risk of developing the wrong features, providing the wrong UX, and applying the wrong technologies, as I describe in more detail in my post The Scrum Cycle.

But as your product grows and eventually matures, the amount of uncertainty and change gradually declines. After achieving PMF, you usually understand how to meet the user needs, and know how to develop, market, and sell the product to the mainstream market. Your focus tends to switch to penetrating the market and fending off competitors by keeping your product attractive and refining it. This typically results in smaller, often incremental product changes. A good example is the latest iPhone 7, where Apple largely optimised existing features like camera and battery life. Scrum consequently becomes less helpful at these life cycle stages: The development team members are often no longer required to work together towards a shared goal in order to test an assumption or to deliver a piece of functionally. If, however, you decide to revitalise a maturing product and extend its life cycle, for instance, by taking it to a new market or unbundling a bigger feature, you usually face a significant amount of uncertainty and change. In the picture above, the life cycle extension is shown by the arrow that reverses the ageing process of the product and takes it back into the growth stage. In this case, Scrum becomes very helpful again!

If you are in doubt if you should use Scrum or not, consider how much uncertainty is present in your product. Do you understand how to address the market needs and solve the users’ problem? Do you know how to develop, market, and sell the product? And more specifically, can the users confidently tell you which functionality they require and which aspects of the product need to be improved? Do you mainly provide incremental enhancements or bug fixes? Are the architecture and technologies fit for purpose and stable? Are you regularly struggling to agree on a shared, meaningful sprint goal? If the answer to these questions is yes, then Scrum is probably not the best framework for your product. To gain more clarity, use the next sprint retrospective to investigate if your process is still helpful, or if you should switch to an alternative.


What’s the Alternative?

Once your product no longer exhibits a significant amount of uncertainty and risk, is growing steadily, or has started to mature, a Kanban-based process may be the right choice, as the following picture illustrates.

scrumkanbanandproductlifecycle

Unlike Scrum, Kanban does not regard protected, goal-driven iterations as mandatory. You can use it to implement an agile process with the flexibility to work on different items and release them individually at different times. This is particularly handy for incremental enhancements and bug fixes and to quickly test smaller ideas.

I therefore suggest that process follows product: You should choose the process that is best suited to provide a successful product—a product that does a great job at creating value for the users and for the business. There is no one right way, no silver bullet. Neither Scrum nor any other framework is always the best fit. As a consequence, you may well have to adjust and change your process across over time. Use the retrospectives to regularly enquire if your current process is fit for purpose and adapt and change it as appropriate.


Mix and Match

The picture above seems to suggest that you face a stark choice—either Scrum or Kanban. But that’s just a simplification to help you choose your primary process. You can, of course, combine Scrum and Kanban. You may decide, for example, to apply Scrum to develop new features and Kanban to fix bugs, as I describe in my post Succeeding with Innovation and Maintenance.

You can also use Kanban for product discovery and strategy validation activities, as I recommend in my book Strategize. These activities may overlap with the Scrum-based development, for instance, when you intend to extend the life cycle of your product.

Summary
Article Name
Is Scrum Right for Your Product?
Description
Find out if Scrum is effective to develop and grow your product or if you should consider using a different process.
Author
Pichler Consulting Limited

Learn More

You can learn more about when Scrum is most helpful for you with the following:

Source: http://www.romanpichler.com/blog/is-scrum-right-for-your-product/

RSS Feed

Tags related to this post:


8 comments on “Is Scrum Right for Your Product?

  1. tushar

    Hi, thank you for this post I Agree with you that A process like Scrum is a great fit for your product when it is brand-new or young, and when you extend its life cycle, as shown in the picture below. very useful information

  2. Harihara Prasath

    Especially in the following points:

    Do you understand how to address the market needs and solve the users’ problem?
    Me : If we understood clearly the market needs and if we are constantly solving the user’s problem, then in what way it is not advisable in doing Scrum.

    Do you know how to develop, market, and sell the product?
    Me : If we know how to develop, mark and sell the product, what is there in not executing this with scrum

    And more specifically, can the users confidently tell you which functionality they require and which aspects of the product need to be improved?

    Me : If the users confidently tell us what functionalities they required, is it not the expectation for any project? How it differs for not qualifying as a Scrum Project.

    Sorry for my long question. I want to understand better. Thanks in advance for your answer

    • Roman Pichler

      If you thoroughly understand who uses your product and why, and if you understand how to develop it, then you are facing little uncertainty. You can still use Scrum, of course, but you should consider if it is still the best process for you, see my post The Scrum Cycle.

      I don’t think you can and should expect that your users are generally able to tell you what the product should do. I regard it as the responsibility of the product manager/owner and the dev team to discover the right features and UX.

      Hope this helps!

      • Harihara Prasath

        Thank you for the nice explanation Roman.

  3. Harihara Prasath

    Nice Article.

    If you can give more clarity on the below points, it will be of great help

    If you are in doubt if you should use Scrum or not, consider how much uncertainty is present in your product.
    Do you understand how to address the market needs and solve the users’ problem?
    Do you know how to develop, market, and sell the product?
    And more specifically, can the users confidently tell you which functionality they require and which aspects of the product need to be improved?
    Do you mainly provide incremental enhancements or bug fixes?
    Are the architecture and technologies fit for purpose and stable?
    Are you regularly struggling to agree on a shared, meaningful sprint goal?

    If the answer to these questions is yes, then Scrum is probably not the best framework for your product.

    • Roman Pichler

      Hi Harihara, Thanks for your feedback. What makes it difficult for you to apply my advice? What’s unclear to you?

  4. Rik Pennartz

    Thanks, Roman. I really enjoy reading your posts. They are very helpfull!

    • Roman Pichler

      Thanks for your feedback. I’m glad to hear that you find my posts helpful.

Leave a Reply

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