Thursday, October 19, 2017

What is Water-Scrum-Fall?

According to Forrester, although Agile software development has gained tremendous popularity, the reality is that the approach many organizations follow is constrained by both organizational culture and intuitive governance.

"Organizations are increasingly adopting Agile software development methodologies through a combination of bottom-up adoption and top-down change. However, the reality of agile adoption has diverged from the original ideas described in the Agile Manifesto, with many adoptions resembling what Forrester labels Water-Scrum-Fall," explains Dave West, Director of Research and Vice President at Forrester.

Water-Scrum-fall is typically regarded as a hybrid agile way of working, which originates from the fact that the practitioners of agile methodologies focus on the domain they are most familiar with: software development.

While some, such as Andy Hiles, who gave a talk about Water-Scrum-Fall at the first Agile Greece Summit, believe that Water-Scrum-Fall can be used as a stepping stone to agility, others, such as Cameron McKenzie, a former software engineer who currently specializes in Agile development are convinced that using Water-Scrum-Fall only creates problems and resentment.

To help you come to your own conclusions, we are taking a closer look at both the Waterfall and the Scrum approach, comparing the two and then examining how they relate to the Water-Scrum-Fall approach. 



Waterfall

The Waterfall approach is commonly described as a linear-sequential life cycle model. In other words, the software development process follows clearly defined stages, each of which follows the previous one. 

The typical stages are:

  • Requirement analysis: The requirements of the product to be developed are gathered and captured in a requirement specification document.  
  • System design: Based on the gathered requirements, the design of the product is prepared and used to specify the product’s expected hardware and system requirements.
  • Implementation: Based on the design, small programs, called units, are developed individually and tested for their functionality. 
  • Integration and verification: The developed units are integrated together, and the product as a whole is verified.
  • Deployment: The product is deployed in the customer environment or released into the market.
  • Maintenance: The deployed product is maintained and, optionally, improved.


Each of these stages may take several months, so it often takes a long time for a product to be deployed. The Waterfall approach necessitates that planning is completed before any work begins, which means that it's usually completed before it is entirely understood what the project entails. When system design problems are discovered after the implementation had already begun, the project goes back to the planning stage and starts over.

Scrum

Scrum is a popular implementation of Agile, which is a set of values and principles for software development, described in the Agile Manifesto.

As Andy Hiles says, "Agile is a mindset, a set of guidelines, Scrum is a framework that can be deployed, it has strict rules and events to follow, they are not the same thing. Agile thinking exposes our inability to deliver fast; it drives out what the customer actually wants and improves quality by providing multiple opportunities for continuous feedback, which in turn focuses the developers towards how to build the right thing right."

Scrum breaks down the development process into several smaller pieces, called events, building a minimal feature set and getting the product ready to ship:

  • Sprint: The basic unit of development in Scrum, restricted to a specific duration. Each Sprint starts with planning. 
  • Sprint Planning: The team discusses and agrees on the scope of work that is intended to be done.
  • Daily Scrum: The team synchronizes activities and creates a plan for the next 24 hours during a 15-minute time-boxed event.
  • Sprint Review: Held at the end of the Sprint to review the work that was completed and the planned work that was not completed.
  • Sprint Retrospective: The opportunity for the team to inspect itself and create a plan for improvements.

A sprint typically takes less than a month and is repeated over and over again, each time resulting in a new incremental release. It’s not uncommon for a shippable product to be created only after the second or the third Sprint.  

Scrum defines three key roles that are needed for the framework to work:

  • Product owner: Responsible for defining the features that are needed in the product. 
  • Scrum master: Responsible for protecting the team and the process, running the meetings, and keeping things going.
  • Team: Includes the developers, testers, writers, and anyone else involved in the product development. 


Scrum produces three Artifacts, or documents:

  • Product backlog: Where product owners create a prioritized list of features, known as user stories. The product backlog evolves and changes priorities with each Sprint. 
  • Sprint backlog: The highest priority user stories go into the sprint backlog and are committed to for the next sprint. 
  • Burndown chart: Shows the progress during a sprint on a completion of tasks in the Sprint backlog.


Waterfall Versus Scrum
  
With the Waterfall approach, the software development process is seen as one monolithic project, and the development team releases working software to an operations team at the end of the project. On the other hand, Scrum would approach the development of the same project as a series of very small projects called, Sprints. The development team would release working software periodically until the entire software product is complete.

Water-Scrum-Fall

The Water-Scrum-Fall approach originated from the desire of many organizations to adopt Agile software development methodologies combined with the fact that Agile adoption has been led by Agile practitioners, who naturally focus on domains they can influence: the Scrum team itself. Those domains that fall outside their control, project planning and release management, still follow the traditional Waterfall approach. 

According to Margaret Rouse, Water-Scrum-Fall is "A flexible approach that embraces both traditional and Agile development principles and allows development teams to use whatever practices and techniques best meet the needs of the problem being solved."

As such, software development is often divided into three distinct phases: a period of detailed design and planning, the development using the Scrum approach, and a strict and managed product delivery. Just like the Waterfall approach, the Water-Scrum-Fall approach is ruled by fixed contract terms and lengthy deployment times.
According to Dave West, one vice president of development said, "We have to spend time upfront with the business building the requirements and plans to ensure that we know what they want, and they know how long it is going to take and how much it is going to cost. The problems start when the business does not know what they want, or the architecture is new to us."

West advises that application development and delivery professionals should realize that spending too much time upfront will not increase the quality of the release. Documents should introduce the problem area and allow high-level planning to commence as quickly as possible, while rapid feedback from the customer thanks to frequent software releases and better integration of the release process into the development team ensure early availability of usable software. 

"Apart from describing Water-Scrum-Fall as a kick-off stepping stone to agility, I am struggling to find any real benefit," states Hiles. For this and other reasons, the Water-Scrum-Fall approach is often described as an anti-pattern. "This anti-pattern has been widely implemented across the public sector, but it can also be found in commercial organizations, particularly those at enterprise scale. Various Agile scaling frameworks (e.g., Agility Path) have been developed in an attempt to provide a remedy," concludes agilepatterns.org.

Conclusion

The Water-Scrum-Fall approach often results from a botched Agile transformation and creates an environment with many pitfalls of the Waterfall approach but with limited benefits of the Scrum approach. Several remedies for the Water-Scrum-Fall anti-pattern have been developed, including Agility Path and other scaling frameworks.

Sources