- Setting up Auditing & Logging of Files/Objects Using Native Windows File Server Tools - 16th October 2020
- Designing Key Performance Indicators (KPI) - 15th July 2020
- DDOS Attacks and Website Hacking - 6th July 2020
In this blog post I discuss if Scrum is the right approach for a project or is it better to use another Agile alternative? I will cover when is Scrum the best option, how to find out if Scrum is the best option, and what is another alternative. Scrum offers a powerful way to develop products. In fact, it is often seen as the standard way to create digital products. But like every process, Scrum has its benefits and limitations. In this article I express my views on when is Scrum the best fit.
The first thing to understand, in my view, is that there is no such thing as a project process or approach. Rather, there is a product development process that is used within the project. And this methodology is determined by the end deliverable of the project – the product. There is no use using a methodology just for the sake of that methodology and in my view, the development lifecycle process used in the project follows the product.
You should choose the process that is best suited to provide a successful product. And it is worth remembering that there is no sole right way. 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. This is where the Sprint Retrospectives can be used to regularly review if your current process is fit for purpose and adapt and change it as appropriate.
Mix and Match
Many projects start off thinking that you face a binary choice — either Scrum or something else throughout the life of the project. I suggest that that is not the case. A project can choose a primary framework for developing the product and then combine or replace that with another framework when needed, perhaps at a later point in the product or project lifecycle as appropriate. For example, you can use Scrum to develop new features and Kanban to fix bugs. Or Scrum when there are many unknowns regarding the features and requirements of product in the beginning of the project, and Kanban later on in the project when the product has become more mature, and the development work is more towards bug fixes, as illustrated below.
The picture above shows the traditional, bell-shaped product life cycle curve with three key events: launch — the product first becomes available; achieving product-requirement fit (PRF) — the product has a settled features list and requirements backlog; and end of life — when it’s decided to discontinue using the product.
In order to leverage the product life cycle, 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 cost saving products cost saves are usually used and if the product exists for use by other products or services, then the number of active users might be instead.
How to Determine Whether to Use Scrum?
What determines when best to apply scrum if the amount of uncertainty around the product, it’s features and requirements. If there is a lot of uncertainty, and things may change, it is best to iterate through product builds and Scrum is a very good development framework for managing that. The following questions can be used to consider how much uncertainty there is around the product and consequently if Scrum should be used by the project:
- Is it understood how to address market needs or solve the user’s problems?
- Is it known how to develop, market, and sell the product?
- Can the users state which functionality is required 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 goals?
If the answer to these questions is “no” or “don’t know”, then there is a high degree of uncertainty around the product and Scrum is probably the best framework to use. If the answers are “yes”, then the next sprint retrospective can be used to investigate if your process is still helpful, or if you should switch to an alternative.
When best to use Scrum
The younger, and less mature the product is, the more it is likely to benefit from Scrum. This is because when working on a brand-new product, or a product that has never been used by an organisation if it’s an internally used product, you typically face many unknowns and a substantial amount of uncertainty and change. The following are factors in determining the level of uncertainty and if things are likely to change:
- When it’s not fully understood the value the product should create for its users or customers
- When the features and user experience (UX) the product should provide are not clear
- When the business goals it should serve and the business model it should use are still being worked through
- When the technologies that should be used to develop the product might change based on testing and feedback.
In a situation where much is uncertain, the 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. In such a situation, where accelerating learning and mitigating the risk of developing the wrong features, or providing the wrong UX, or applying the wrong technologies is important, Scrum would be the best methodology.
When Best to Use an Alternative Agile Process
As your product grows and eventually matures, the amount of uncertainty and change gradually declines. After the product achieves a good fit of its requirements, you usually understand how to meet the user needs, and know how to develop, market, and sell the product. The focus at this point for the project tends to switch to penetrating the market and fending off competitors by keeping the product attractive and refining it – not specifically testing an assumption or delivering new functionality as these things would have been tested or delivered in prior releases such as product launch or further updates. This stage of the product lifecycle might result in smaller, often incremental product changes that can be done independent of each other. A good example is mobile phones, where the manufacturer largely optimises existing features like camera and battery life. Scrum consequently might become less helpful than other Agile frameworks at these life cycle stages and could be replaced by something that fits better.
If, however, you decide to revitalise a maturing product and extend its life cycle (shown in the diagram above as the point of New Feature and Product Life Extension), for instance, by taking it to a new market, you usually face a significant amount of uncertainty and change and Scrum would be more useful.
What are the Alternatives
Once the 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 a better choice. 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 useful for minor incremental enhancements and bug fixes and to quickly test smaller ideas.