Anti-Pattern of the Month: WaterScrumFall

Several years ago an article appeared in Project Manager Today which explored why many software initiatives fail. The project management life cycle was summarized as follows:

1. Initial Enthusiasm

2. Dawn of Reality

3. Panic

4. The Blame of the Innocent

5. Rewards for the Uninvolved

This invites comparison with the following stages of "waterfall" project management:

1. Conception

2. Analysis

3. Design

4. Construction

5. Servicing

Cynical correspondences of this nature will be recognizable to many who work in the software engineering profession. A similarly staged phasing of work was outlined by Winston Royce in 1970. This later became termed the "Waterfall Model" and it has gained a tarnished reputation. Empirical process control is lacking, and there is poor support for learning and emergence. Ironically though, it is usually forgotten that Royce presented the model as an example of a flawed approach, and not as a proposal for a good one. 

This type of structuring even features in some iterative and incremental development methods. The Rational Unified Process, for example, describes a phased progression from Inception through Elaboration to Construction and Transition. It can be advantageous to provide a degree of "narrative continuity" during the execution of an initiative, especially if it reassures stakeholders and investors who are looking for a traditionally staged project schedule before funding will be authorized.

In some cases, it may be possible to divvy up iterations so a convincing project narrative can be faked. However, there are significant risks in doing so. A common symptom of the "WaterScrumFall" antipattern is that iterations have a tendency to become a feature of the software construction stage, and not of any other. Managers can wrongly assume that agile ways-of-working is essentially a technical concern. A key feature of agile development is that stakeholders must be engaged and empowered throughout the initiative. Stakeholders have to be involved in an ongoing dialog of requirements prioritization and release evaluation. Hence offering a narrative structure can be dangerous. It can create the impression that all stakeholders have to do is "push a button" and the software process will trundle along without intervention on their part, with nice reports being generated at major stage gates. This is unrealistic when complex software products are being developed and there are multiple unknowns and risks to be controlled.

Software development is not a magical code factory where industrious Munchkins rattle through a ready, complete, and accurate feature set as though they were churning out chocolate bars. To avoid the "WaterScrumFall" anti-pattern it has to be made clear to stakeholders that their engagement is needed throughout the project, product ownership must be resolved, and that scope will need prioritizing and adjusting at regular intervals.

WaterScrumFall is Antipattern of the Month at agilepatterns.org

You may also like: Microservices Anti-Patterns

Antipattern of the Month: WaterScrumFall

Intent: Attempt to leverage Scrum benefits while retaining a stage gated approach

Proverbs: A dog cannot serve two masters; cr*p or get off the pot

Also Known As: Scrum — But, Agile In Name Only (AINO)

Motivation: Organizations may often have the goal of adopting an agile way of working, but they can lack the cultural grit to transition away from an established stage-gated culture. They then attempt to effect a compromise in which an iterative development approach is encapsulated within a development stage. In so doing they hope to leverage the benefits of agile practice, whilst not actually changing the organization's delivery approach or the terms of reference that are comfortable to stakeholders.

Structure: A team attempts to sprint in order to produce increments of work that are drawn iteratively from a Product Backlog. However, the sprints are constrained by the pre and post conditions of stage gates that are determined by a project plan, and the value delivered is correspondingly reduced.

Applicability: Waterscrumfall is widely used to constrain agile practice to a development stage. Requirements analysis and delivery are held to be outside of the remit of agile teams.

Consequences: The stage gated culture of an organization remains unchanged. Definitions of Done are weak because they do not cover the value stream through to release. Potentially releasable increments of value are not delivered and work continues to be batched into large shipments. The ability to inspect and adapt to the engineering process is compromised due to delayed feedback. The potential to gain from early returns on investment is lost. Reputational damage can occur to agile practice since stakeholders may believe, incorrectly, that agile methods are in fact being applied.

Implementation: This anti-pattern has been widely implemented across the public sector, but it can also be found in commercial organizations, particularly those at an enterprise scale. Various agile scaling frameworks (e.g. Agility Path) have been developed in an attempt to provide remedy.

See Also: Iteration, Increment

Further Reading

Top 40 Project Management Terms and Concepts of 2019