Water-Scrum-Fall

Water-Scrum-Fall is the enterprise software development methodology in which an organisation adopts the vocabulary of Agile — sprints, ceremonies, backlogs, standups — while preserving the structure of Waterfall — sequential phases, phase gates, fixed scope, signed-off requirements — producing a hybrid that has the overhead of both and the benefits of neither.

The organisation believes it is Agile because it uses the words. The software believes it is Waterfall because it experiences the phases. The developers believe nothing because they have attended both the sprint planning ceremony and the phase gate review for the same piece of work, and the cognitive dissonance has calcified into a quiet, professional numbness.

Water-Scrum-Fall is not a methodology anyone designed. It is a methodology that happens — the natural result of an enterprise that has been told to “go Agile” by a CTO who attended a conference, implemented by a PMO that translated the Agile Manifesto into a Gantt chart, and adopted by teams who discovered that the word “sprint” does not change the length of the requirements phase.

“You can call a cat a dog. The cat does not fetch.”
— The Lizard, on renaming phases

The Anatomy

Water-Scrum-Fall has three layers, like a geological formation:

Water (top) — Requirements and planning are done upfront, in full, before development begins. The scope is fixed. The budget is approved. The Gantt chart is drawn. This layer is pure waterfall, untouched by the Agile transformation happening in the layer below, because the finance department has not been to the conference.

Scrum (middle) — Development is organised into “sprints.” The sprints have standups, sprint planning, and retrospectives. The ceremonies exist. The board exists. The vocabulary exists. The sprints do not iterate on requirements. The sprints do not change scope. The sprints implement the predetermined design in a predetermined order. The sprints are waterfall phases with a Scrum board attached.

Fall (bottom) — Deployment is a big-bang release after all development is “complete.” Testing happens at the end, on the full system, against the original requirements. The release date was set in the Gantt chart eighteen months ago. The release date does not move. The scope moves. The quality moves. The release date is sacred.

The result: waterfall with meetings. The same sequential phases. The same phase gates. The same signed-off requirements. But now each phase has a daily standup where someone asks “any blockers?” and the blocker is that the requirements were wrong but cannot be changed because they were signed off in the Water layer, and this blocker is noted and not resolved, every day, for the duration of the sprint, which is five weeks.

The Five-Week Sprint

At a famous camera manufacturer, an ERP implementation was organised as follows:

• Requirements Sprint: 5 weeks
• Business Process Design Sprint: 5 weeks
• Development Sprint: 5 weeks (the “short cycle”) or 10 weeks (the “long cycle,” comprising two 5-week development sprints, so that two full cycles could fit in a calendar year accounting for Dutch holidays)
• UAT Sprint: 5 weeks

Each “sprint” was a waterfall phase. The word “sprint” had been applied like a label to a jar that still contained waterfall. The jar did not care what the label said. The contents were sequential, phase-gated, big-bang, and five weeks long.

To keep the consulting teams utilised — because in enterprise IT the cardinal sin is not failure but idleness — four of these cycles ran in parallel, staggered. While Team A was in its Requirements Sprint, Team B was in Business Process Design, Team C was in Development, and Team D was in UAT. A factory line of waterfall phases, labeled “sprints,” running continuously, producing software in the same way a nineteenth-century cotton mill produced cloth: on a schedule, at scale, with no feedback loop between the product and the customer until the very end.

“The sprint was five weeks. The ceremony was a phase gate. The board was a Gantt chart. Apart from that, very Agile.”
— riclib, who walked into this and blinked

The Parallel Fictions

The camera manufacturer’s project had an additional layer of absurdity that deserves its own heading.

The ERP modules (Oracle Applications) were being implemented by one company. The BI layer (Oracle BI) was being implemented by a separate company. Both were following the same phase-staggered sprint structure. Both were running “in parallel” for the same modules.

This meant: the BI team was in its Design Sprint for the procurement module while the ERP team was also in its Design Sprint for the procurement module. The BI team was designing data extracts for tables that did not yet exist, writing transformation logic for business rules that had not been finalised, and building reports on data models that were still being debated in the ERP team’s design sessions happening in the adjacent conference room.

The Development Sprints were worse. The BI team was coding data loads for source systems that were being coded simultaneously by the ERP team. The BI team’s “development” was fiction — carefully structured, professionally managed fiction, with timesheets and status reports and a green RAG status — but fiction nonetheless, because the source data did not exist, the source schema was changing weekly, and the only thing that was stable was the Gantt chart, which showed both teams progressing on schedule.

The real development process was: build two parallel works of fiction, then rewrite everything in UAT when the fictions collided with each other and with reality. UAT was not “testing.” UAT was “the phase where you actually build the software, under the polite fiction that you are merely testing it.”

“They were building data loads for data that didn’t exist, coding extracts from tables that were being designed in the next room, and reporting status as green. The Gantt chart was a novel. A well-structured, phase-gated, professionally managed novel.”
— riclib, Interlude — The Blazer Years

The Rescue

riclib was brought in to rescue the BI workstream. The diagnosis took approximately one conversation:

The BI team was following the process. The process was producing fiction. The fiction was being rewritten in UAT. The rewrite was expensive, late, and demoralising. The process was not the solution. The process was the problem.

The first experiment was small, and it required a conspirator.

In every Water-Scrum-Fall organisation there is a Release Manager. The Release Manager controls the deployment pipeline — the gates, the schedules, the environments, the approvals. In the five-week-sprint world, the Release Manager is the person who ensures that code moves through environments on a twenty-five-week cadence: five weeks of requirements, five of design, five of development, five of UAT, and then — maybe, if the stars align and the Change Advisory Board convenes — deployment. The Release Manager is the gatekeeper. In a dysfunctional process, the gatekeeper is the most powerful person on the project, because nothing ships without the gate opening.

But some Release Managers are benign. Some Release Managers are people who went into IT because they enjoy software that runs — not software that is discussed, not software that is planned, not software that is documented, but software that runs, in production, doing things for users. These Release Managers are rare, and they are the most valuable allies a rescuer can find, because they hold the keys to the only thing that matters: the ability to deploy.

riclib found one. Kindred spirits — two people in a building of hundreds who shared the radical belief that software should work. The conspiracy was simple and it was Gall’s Law in action: you cannot redesign a twenty-five-week release process from scratch. But you can grow a simple system that works — one team, one week, one deploy — inside the complex system that doesn’t. The Release Manager would open the gate every week instead of every twenty-five weeks. The small changes team would deploy every Friday. The five-week-sprint process would continue to exist on paper, satisfying the governance requirements, while actual working software flowed through a side channel that the Release Manager had quietly enabled. The complex system that worked evolved from a simple system that worked. Gall would have nodded.

Without the Release Manager, the rescue would have been a design exercise. With the Release Manager, it was a deployment pipeline.

riclib hired an Agile Coach to introduce actual agile practices to the small changes team — the team handling the small modifications that made the ERP software actually work for the business. The agile coach, confronted with a distributed team spanning multiple countries and a communication gap the size of the Indian Ocean, struggled. riclib took over the coaching and reassigned the agile coach to write documentation, which was the first time the agile coach had been productive on the project, and both parties were quietly relieved.

The approach was simple. Criminal, by enterprise standards. Enabled by a Release Manager who believed software should run. But simple:

1. Go to the procurement team — the actual users
2. Ask for the Excel spreadsheets they were actually using to do their jobs (because the ERP was not yet working)
3. Take the spreadsheets — which represented the real business process, not the documented business process, not the designed business process, but the one that made the procurement department function every day
4. Run one-week sprints. Actual one-week sprints. Seven working days. Deliver working functionality that matched what the spreadsheet did
5. Demo to users on Friday. Get feedback. Adjust Monday. Deliver Friday.

One week. Not five. One.

The procurement team — who had spent months watching five-week “sprints” produce documents about documents — saw working software after seven days. The software did what their spreadsheets did. The software was not fiction. The software was tested, because it was tested by the people who used the spreadsheets, against the spreadsheets, which were the source of truth that the requirements documents had been trying to describe for eighteen months.

By the time riclib left the project, there were eight of these small-changes teams. Eight teams, running actual one-week sprints, delivering actual working software, building from actual business processes documented in actual spreadsheets. The enterprise waterfall process continued to run alongside them — the five-week “sprints,” the parallel fictions, the phase gates, the Gantt charts — because the process was contractually required, and in enterprise IT the process is the product and the software is the side effect.

The eight teams delivered the software. The process delivered the status reports. Both continued. Neither acknowledged the other. This is Enterprise.

“Eight teams. One-week sprints. Real spreadsheets. Working software. And next door, four staggered streams of five-week phases producing the Gantt chart that the steering committee needed to see. Both existed simultaneously. Both were called ’the project.’ One of them worked.”
— riclib, who left before the retrospective

Diagnosis

You are practicing Water-Scrum-Fall if:

• Your “sprints” are longer than four weeks
• Your sprint scope is decided before the sprint starts and cannot change during the sprint
• Your sprint planning consists of assigning tasks from a predetermined project plan
• Your retrospective produces action items that require approval from a governance board
• Your daily standup includes the phrase “blocked — waiting for sign-off”
• Your sprint review is attended by a steering committee instead of users
• Your definition of done includes “approved by the Change Advisory Board”
• Your velocity chart goes up every sprint but your users still use spreadsheets
• You have a Scrum board and a Gantt chart and they describe the same work in different vocabularies
• Your agile coach has been reassigned to write documentation

If five or more of these apply, you are not doing Agile. You are doing Waterfall with ceremonies. The ceremonies are not helping. The ceremonies are the overhead you added to the overhead you already had.

Measured Characteristics

Sprint length (Scrum Guide):                   1-4 weeks
Sprint length (camera manufacturer):           5 weeks
Sprint length (actual agile, same project):    1 week
Difference:                                    5x
Parallel fiction streams:                       4 (staggered)
BI team designing for nonexistent data:        100% of the time
Real development phase:                        UAT (relabeled)
Release Managers conspired with:               1 (the most important one)
Deployment cadence (official):                 25 weeks
Deployment cadence (conspiratorial):           1 week
Agile coaches hired:                           1
Agile coaches reassigned to documentation:     1
Small changes teams (start):                   1
Small changes teams (end):                     8
Source of truth (documented):                  requirements specification
Source of truth (actual):                      Excel spreadsheets
Sprint deliverable (5-week):                   status report (green)
Sprint deliverable (1-week):                   working software
Enterprise process compliance:                 maintained (contractually required)
Enterprise process utility:                    decorative

See Also

• Waterfall — The honest version. At least waterfall admits it’s sequential.
• Agile — What the camera manufacturer thought it was doing. Four values on a napkin. None of them say “five-week sprint.”
• Scrum — The framework whose vocabulary was borrowed. Scrum did not consent.
• Sprint — Two to four weeks. Not five. Not five.
• Ceremony — The meeting renamed to be unkillable. In Water-Scrum-Fall, the ceremony is a phase gate renamed to be unkillable.
• SAFe — Water-Scrum-Fall’s older sibling. Same condition. More trains.
• Enterprise — The gravity well in which Water-Scrum-Fall forms naturally, like sediment.
• The Consultant — The person who walks in, blinks, asks for the spreadsheets, and builds eight teams while the Gantt chart watches.