What is Scrummerfall?

Scrummerfall – the dilution of Scrum

‘We plan our next sprint for a week. Then we sprint for four weeks, followed by two weeks for integrating the solution and another week for deployment. To be on the safe side, we plan an additional week as a buffer.’

What does this statement have to do with Scrum? Nothing!

Scrum is a flexible framework for complex projects and developments. The heart of the framework is the so-called sprint. It includes all other events and activities and, according to the Scrum Guide, lasts a maximum of four weeks. So anyone who plans a week before a sprint and several weeks after a sprint is actually doing the following: they are taking a central concept from Scrum but working with an approach that has nothing to do with the framework and the contents of the Scrum Guide. Or in other words: they are engaging in Scrummerfall.

Scrummerfall describes the dilution of Scrum with classic approaches. [1] Often, this dilution occurs unintentionally in organisations. While teams work iteratively and incrementally within a sprint, upstream and downstream, sometimes also higher-level processes, control and decision-making paths continue to be handled in the classic way. This leads to contradictions, as agile principles such as self-organisation, fast feedback cycles and continuous adaptation collide with phase-based, highly structured approaches.

The term Scrummerfall combines Scrum and the waterfall model. Alternatively, it is often referred to as WaterScrum, WaterAgile or WAgile; however, these synonymous terms are contradictory and should be discussed within an organisation if there is uncertainty as to whether everyone involved understands the same thing by the terms. [2]

There are many reasons for Scrummerfall: Often it is due to insufficient understanding of agile principles, organisational structures that are geared towards classic planning and control, or the challenge of combining existing processes with agile methods.

Examples of Scrummerfall

Scrummerfall occurs in different forms. Here are some examples:

• Staggered sprints are used, for example, business analysts work one sprint ahead of the developers, while quality assurance lags one sprint behind.
• Sprints are defined as containers for activities: the first sprint is about requirements analysis, the second about project planning, the third about realisation, the fourth about acceptance, etc.
• Sprints vary in length because companies have made firm delivery promises to their customers (‘You will get the product after the next sprint’) and the concept of timeboxing does not apply.
• A team uses practices such as daily stand-ups, sprint reviews and retrospectives, but team members are not allowed to make independent decisions about their work. Decisions about architecture, requirements and priorities continue to be made by a central management body, which contradicts the agile idea of self-organisation.

The list of examples can certainly be easily extended.

Challenges for organisations

Scrummerfall brings with it numerous challenges for organisations, which can reduce the advantages of agile methods or even reverse them.

• Staggered or sequential workflows significantly delay feedback on developed features. This can lead to problems being identified and corrected late, increasing development costs.
• Organisations that combine Scrum with formal waterfall processes lose the adaptability of agile development. Decisions are often made early on and bureaucratic processes make changes more difficult.
• If individual roles or departments work in isolated sprints, there is a lack of holistic responsibility for the product. This can lead to an increase in misunderstandings and a decline in quality.
• A key advantage of Scrum is the self-organisation of the teams. However, in a Scrummerfall scenario, teams are often limited by external dependencies and strict processes, which impairs their personal responsibility and motivation.

To avoid Scrummerfall, organisations should therefore critically examine their processes and check whether they really support agile principles or are counteracted by traditional elements.

Notes:

[1] A well-known definition of the term goes back to Brad Wilson, a US-American software developer: ‘Scrummerfall is the practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.’
[2] On closer inspection, there are differences between Scrummerfall and, for example, WaterScrum: Scrummerfall addresses the situation in which Scrum is not applied in the sense of the Scrum Guide and is diluted by existing practices and methods that have often been used for many years. WaterScrum turns this idea around: In an organisation, classic methods and procedures are used, but the organisation wants to become more agile and use Scrum – at least in parts. The result is hybrid models or procedures in which, for example, shorter iterations enable earlier feedback from customers. The existing waterfall approach is thus becoming more agile step by step.

Here you will find a German podcast: Scrummerfall – Wenn Scrum scheitert.

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.