Don’t Mix Your Waterfalls – Scrum Is Better at Flying Solo

DZone 's Guide to

Don’t Mix Your Waterfalls – Scrum Is Better at Flying Solo

Water-Scrum-Fall: difficult to say, but not difficult to fall into.

· DevOps Zone ·
Free Resource

Water-Scrum-Fall: difficult to say, but not difficult to fall into. It’s a software delivery system that places Scrum methodology in between the design phase and an existing legacy deployment system. Many businesses can find themselves in this situation, however, and should be aware that Water-Scrum-Fall can have negative implications. Because it involves multiple approaches to software delivery, there are lots of different patterns of behavior and standard processes. When these clash, the overall benefits of either approach are reduced. Businesses that have ended up in this scenario should assess their current status and then establish where to start to work their way out of it.

Start at the Source

Businesses can find themselves using Water-Scrum-Fall for multiple reasons, and may not even realize this is where they’ve ended up. For some organizations, the results of this method may be 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 certain situations. However, agile is about discovering new ways of working, and evolving processes are a part of that experience. Water-Scrum-Fall should just be a temporary step in the evolution of a company’s software organization. 

Businesses may also use Water-Scrum-Fall for the following reasons:

  • Some teams would grow the Scrum practice across all of their own projects because of the benefits, but won’t have made this standard across all other teams as well, resulting in a hybrid approach across the organization

  • The arrangement of resources forces the isolation of deployment and operations away from development

  • The organization is in a transition phase to a different process that is progressing smoothly

  • The organization is stuck with an incomplete transformation to a different process

Though it’s always interesting to consider the background and evaluate why a business is in the situation it is in, it’s more important to look forward and consider what is the most effective approach to use in the future.

Just Because It’s Functional Doesn't Mean It’s Working

The main problem with Water-Scrum-Fall is the complex mixture of approaches within an organization. Traditional approaches tend to be heavy, slow, and often stuck in a “be certain” mindset, in contrast with Scrum which is designed to be exploratory. A Scrum approach relies heavily on feedback, iteration, and incremental improvement. Trying to have both of these approaches working alongside each other tends to lead to 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. This might not be the biggest issue, as applying agile engineering practices still brings value to the project. Having frequent checkpoints reveals progress and shows the direction of development, while including retrospectives improves processes. However, the effects of minimal implementation and the application of concepts like YAGNI (‘You Aren’t Gonna Need It’) are mostly lost. The specification is already complete, and the team simply works to check off all the required parts.

A hybrid approach can also lead to 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.

Although some organizations use Water-Scrum-Fall successfully, it can cause serious problems:

  • Waste and risk – Up-front design makes it 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.

  • Feedback delays – Delayed delivery increases the time before receiving 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.

  • Making the wrong product – Depending on how long the delays are, organizations may further increase waste by creating features that nobody will use. For example, in an organization with quarterly releases, delivery teams might fit six new features into the system simply because they had the time. If the customer uses only one of those features, then their creation was wasteful.

  • Long-term damage – Waste increases costs, both in construction and maintenance. Additionally, there are psychological and emotional effects to consider. Team morale may drop if the group repeatedly delivers features that go unused and unappreciated. Low morale on the team can eventually lead to poor work, a failure to innovate, increased absenteeism, and attrition.

Leaving the Waterfall Behind

Development teams, along with all other areas of a company, should be working towards meeting business objectives. Regardless of what these are, everyone must work together to ensure that these goals are met and, if possible, exceeded. The Water-Scrum-Fall approach, while possibly more effective than a previous process, very likely isn’t the most effective process available. The organization should examine the impact of their process of the entire system as it relates to achieving business goals and then make the appropriate changes to improve efficiency. It’s clear that a Water-Scrum-Fall system 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.

For teams and team leaders who want to implement these changes, putting a strong case to senior management of the benefits of moving away from Water-Scrum-Fall is crucial. These points include: 

  • An overall decreased time to market

  • Improved product development using market feedback, helping teams avoid gold-plating and wasted features

  • Features will flow to the market more readily, letting the business capitalize on successful features earlier

  • The organization will strive to create a flow of ideas to realized software, and team members will no longer be bound by traditional “budget, plan, build, deploy” approaches

  • The business will be better placed to respond to market shifts, capitalize on opportunities, and evolve business capabilities to dominate its market space

Water-Scrum-Fall is common enough among many businesses, and given the current global crisis, no one would be criticized for continuing with this approach in the short-term. But, as companies – and societies – begin to recover in the months to come, development teams should consider whether their Water-Scrum-Fall approach is becoming detrimental, and whether they can invest in a more Scrum-focused methodology that enables teams to realize the benefits of this more modern system. All businesses will be reassessing their processes and legacy systems both during and after the pandemic is over. The most successful ones will be those that put this assessment to good use, and introduce the systems needed to speed up accurate development, getting customers the products they have been eagerly anticipating.

agile, development, scrum, software, software delivery, software delivery management, waterfall

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}