Scrumfall

Myth: Scrumfall is Scrum
Variations:

• We can just slice a Waterfall project into portions and use Scrum
• We're doing Scrum in the Analysis, Design, Development and/or Test teams
• Developers use Scrum after they get a Detailed Design Document

Follow-up myths:

• Scrum Project Manager
• Scrum Team Lead

Category: General Scrum myths
Danger: High

The basis of the myth

This myth clearly originates from people who might have a superficial understanding of Scrum, but who are still stuck in a Waterfall mindset. It pops up when people have not "read the book" or received proper training and are trying to figure out the least disruptive way to "do Agile".

The statement reveals a lack of awareness that the reason why agility works differently is because ... well, people work differently.

Why is it a myth?

Long story short - the Scrum guide makes no statement about the exact scope of the team.
The Scrum Guide merely states:

The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Assumption #1: Silo organization is the best
As long as people assume that silo organization is the best way of organizing teams, the idea is that "designed to optimize" requires silo structures. This assumption is simply wrong, because silos result in the wastes of overproduction, handover, miscommunication and local optimization.
The silo organization needs to be broken to put everyone together in one team who can contribute to the solution.

Assumption #2: The Waterfall project organization works

When your waterfall works, that's great! Why would you even want to do things differently, when what you do works?
Unfortunately, in most companies - and with increasing likelihood as project sizes increase - the waterfall does not work! What exactly do you expect to be different when keeping the dysfunctions?

Assumption #3: Scrum brings the benefits

Scrum is mostly concerned with structure: Structuring the work, structuring the team, structuring the delivery. Consequently setting up a new structure is required for proper Scrum. However, as the Scrum guide states that Scrum merely creates an environment where "people can address complex adaptive problems". The benefits start to come when these problems get addressed - and Scrum doesn't do it for you!

Usually, problems are endemic to preserved Waterfall structures and will persist until these are abandoned.

Assumption #4: The only problem is that teams are not doing Scrum
No. It's not. What would make you think that everything is fine, except which meetings team members attend? Scrum will not do anything when it is considered as a way for developers to organize themselves better.
The key success factor of Scrum is relentless impediment removal, and most impediments affect developers - not are caused by them! While you can remove impediments without applying Scrum, Scrum without this form of impediment removal is completely ineffective.

Consequences

Pointless change

As Craig Larman postulates, "any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo." - when the waterfall is kept and Scrum is introduced, Scrum will be a hollow shell, devoid of it's original intention.

In this setting, people will think they understood Scrum and claim "Scrum does not work". Scrum becomes "burnt soil".

Unsolved problems

The key benefit of Scrum's idea behind cross-functional team is to have people collaborating on problem solving, rather than shoving the problem over the fence. While people continue working with shutters, blame games and fingerpointing continue. Ineffective capacity utilization remains. The problems resulting in slow progress and low quality persist.

No value gain

Agility relies on adaption. Adapt the process where it doesn't work, and adapt the product plan where it doesn't work. This adaption relies on effective, real-time feedback. Waterfall organizations assume that "when the plan didn't work, it was the fault of the plan - next time make a better plan!" Agility abandons this premise, understanding that as the world changes in real time, prediction with certainty is impossible. Waterfall structures insist on working off plans. Scrum's agile foundations rely on reaching realistic goals. The value is gained when the goal is attained, not when an obsolete plan is fulfilled.

Scrumfall is a non-agile shell resulting in superficial change without significant benefits.

Remedies

Start questioning assumptions. For every element of waterfall that you're trying to keep, ask yourself "Why are we doing this?", even to the point where it gets nauseating.
Start asking "What problem are we trying to solve?", seriously question how Scrum is supposed to help with that.
Create clarity on the differences between status quo and "problem solved". Track impediments induced by the Waterfall.
Expose wishful thinking by management ("Developers must do ... to reach ...") and move towards realistic, inclusive planning where everyone gets a say.
Address fingerpointing ("We did this, but they didn't that") or quota-matching (e.g., "Coding done", "Test Complete with Defects") in the organization.

Create awareness with practical examples that nobody can know the future, and that Waterfall's biggest caveat is the assumption that the future can be anticipated!