Is Your Organization Stuck with Water-Scrum-Fall?

Water-Scrum-Fall is a software delivery system that sandwiches Scrum methodology between an up-front design phase and a legacy deployment mechanism. Many variations of this system exist, and it sometimes goes by other names, including Scrummerfall and ScrumFail.

Whatever you call it, a partial Scrum implementation can have negative consequences. The fundamental thing to understand is that Water-Scrum-Fall is a hybrid approach to software delivery that mixes different modes of thinking and behaving. The different modes conflict with each other, and that conflict degrades the overall value of either approach.

Let’s look at how an organization might arrive at a Water-Scrum-Fall process and what some of the implications are.

Why Do Some Organizations Choose Water-Scrum-Fall?

An organization might arrive at this process for many reasons. For some organizations, the results may be more than satisfactory. Like everything in the agile world, there’s no one-size-fits-all solution. Water-Scrum-Fall may be the most effective approach to software development in many situations.

Having said that, agile is about discovering new ways of working, and evolving processes are a part of that experience. Water-Scrum-Fall may be a temporary step in the evolution of a company’s software organization. In this post, you’ll learn about some of the negative consequences of Water-Scrum-Fall and how to fix them.

Why might an organization use this type of hybrid approach? Here are some scenarios.

  • Development teams inside IT found Scrum effective for managing work. These teams grew the Scrum practice across all projects, but they have never been able to convince all parts of the business to participate. As a result, the organization follows a hybrid approach.
  • The arrangement of resources within an organization is forcing the isolation of deployment and operations away from development. This is Conway’s Law in effect across the delivery system.
  • The organization is in the middle of a transformation to a different process that is progressing smoothly.
  • The organization is stuck with an incomplete transformation to a different process.

While the history of an organization’s evolution is interesting, it’s important to focus on what process the organization will use in the future.

How Does Water-Scrum-Fall Affect a Project?

A glaring issue with Water-Scrum-Fall is a mismatch within the organization. Traditional upfront processes are heavy, slow, and often stuck in a “be certain” mindset. In contrast, Scrum is designed to be exploratory. It relies heavily on feedback, iteration, and incremental improvement.

What does this mismatch often lead to in real life? Missed opportunities.

If an organization offers an implementation plan with detailed designs to a Scrum team, then much of the value of Scrum is lost. The exploratory and experimental nature of Scrum is muted, and the process devolves into a tracking system with fixed milestone checks that are based on time rather than functionality.

Most likely, this situation isn’t all bad. Applying agile engineering practices such as ATDD, TDD, and continuous integration still brings value to the project. Having frequent checkpoints reveals progress and shows the direction of development. Including retrospectives improves processes.

However, the effects of minimal implementation and the application of concepts like YAGNI are mostly lost. The specification is already complete, and the team simply works to check off all the required parts. Also, a team working with this system has difficulty pivoting toward an opportunity.

A Hybrid Approach Can Cause a Failure to Adapt

If your team is developing an application using Scrum and agile engineering practices, then applying a traditional release mechanism would devalue much of the impact of these practices. Ideally, work is considered “done” once the team has released it into the production environment. Traditional, weighty, fixed-time delivery would dramatically lengthen the feedback cycle to the development team.

How might these long release cycles and slow feedback loops affect your team? Experimentation would likely be stymied. Corrections and issues involving defects or required changes would disrupt the Scrum delivery cadence. Having a non-incremental deployment mechanism attached to a Scrum project would be like tying a 45-pound plate to an Olympic swimmer’s leg.

How Could Water-Scrum-Fall Affect Your Organization?

Although some organizations use Water-Scrum-Fall successfully, it can lead to serious problems.

Waste and Risk

Agile approaches to software development all focus in some way on getting rapid feedback. You get this feedback by interacting often with the business (the specifier) and the market (the consumer).

Up-front design is perilous. It’s difficult if not impossible to anticipate the needs of a software system accurately. Architecting and designing a system without a tight feedback loop runs the risk of expending effort toward building the wrong thing. And of course, if you’ve built the wrong thing, you have waste.

By doing up-front work that disconnects the specifier from the build activity, you increase the likelihood of making mistakes. Having a product owner in your Scrum team who is a proxy for the specifier is less effective than having the specifier present. A proxy approach is prone to miscommunication and slow feedback loops.

Delayed Feedback and Building the Wrong Thing

Delayed delivery increases the duration of market feedback. By disconnecting the delivery of the agile team with production releases, the organization delays the time it takes to find out whether it built something the market actually wanted. The risk of creating waste over time increases.

Depending on the specific issues with delivery, organizations may further increase waste. How? By creating features that nobody will use, simply to keep teams busy between those releases. For example, in an organization with quarterly releases, delivery teams might fit six new features into the system simply because they had the time to do so. If the customer uses only one of those features, then their creation was wasteful.

The Possibility of Long-Term Damage

This waste increases costs to the organization, both in construction and maintenance. Furthermore, there are psychological and emotional effects to consider. Team morale may founder if the group delivers feature after feature that goes unused and unappreciated. Team members may lose interest in and enthusiasm for the product. Low morale on the team can eventually lead to shoddy work, a failure to innovate, increased absenteeism, and attrition.

What Can You Do About Water-Scrum-Fall?

Ultimately the goal of any organization is to meet the goals set out by the corporate vision and mission. Whatever those goals may be, it’s the organization’s responsibility to achieve them with the greatest possible efficiency and effect. It’s clear that a Water-Scrum-Fall approach, while possibly more effective than a prior process, probably isn’t the most effective process possible. The organization should examine the impact of their process of the entire system as it relates to achieving goals and then make appropriate changes.

Examining the system of Water-Scrum-Fall makes it clear that the system inherently contains and encourages waste. When it comes to product and software development, the organization should shift its approach to one that decreases waste while increasing quality and predictability.

What Benefits Come From Breaking Out of Water-Scrum-Fall?

Let’s look at a few points you may want to bring up if you want your organization to get rid of this system.

  • Applying a more iterative approach to specification will decrease time to market.
  • Deploying to production and getting genuine feedback from the market will shape product development. It will also help teams avoid gold-plating and wasted features.
  • Shifting toward a continuous delivery mechanism that allows deployment on demand will allow features to flow to the market more readily. This in turn will let the business capitalize on successful features earlier.
  • Breaking out of Water-Scrum-Fall may transform the entire organization to one that that strives to create a flow of ideas to realized software. Team members will no longer be bound by traditional “budget, plan, build, deploy” approaches.
  • Getting rid of Water-Scrum-Fall will most likely enable the business to respond to market shifts, capitalize on opportunities, and evolve business capabilities in a way that allows the organization to dominate its market space.

Should You Seek Help?

A consultant may be able to help you identify specific actions to take so you can jump-start a transition away from Water-Scrum-Fall. An outside viewpoint can help you cut through bias that may exist in your organization. Educating your organization on its overall mission is also helpful, especially if you ask organization members to help you refine your process toward achieving that goal. Companies like Plutora provide these services and greatly assist you in moving your organization to the next level.

Learn how to improve the speed, quality, and visibility of your software delivery.