It's rare to find a software organization that follows a single methodology to the letter. Agile shops commonly use a mixture of agile techniques morphed into a custom methodology that's right for their organization. But mixing agile and waterfall? Some scrum and Extreme Programming (XP) purists would shudder at the thought! Yet managing agile and waterfall in the same project is a reality that needs to be dealt with.
Whether working with a third-party vendor or with internal teams that haven't made the switch, managing a hybrid project is often necessary. Let's stop the methodology wars and talk about ways in which agile and waterfall can not only coexist but also play well together.
Agile vs. waterfall
The bickering between software engineers about methodologies can be as heated as two politicians on the debate stage, each insisting their way is the one and only "right" way. As an agile coach myself, I'm embarrassed by the superior attitude some agile evangelists have when declaring agile as the be-all and end-all of software development methodologies. Agile really isn't a single methodology but a set of values and principles, many of which are practiced in development shops using a waterfall methodology. In fact, part of being agile includes adjusting and adapting rather than using a prescriptive set of guidelines, so claiming agile is the best approach is, in itself, anti-agile.
The main difference between agile methodologies and waterfall methodologies is the phased approach that waterfall takes (define requirements, freeze requirements, begin coding, move to testing, etc.) as opposed to the iterative approach of agile. However, there are different ways to implement a waterfall methodology, including iterative waterfall, which still practices the phased approach but delivers in smaller release cycles.
"Today, more and more teams self-identify as using an agile methodology. While many of those teams are likely using a hybrid model that includes elements of several agile methodologies as well as waterfall," writes Peter Varhol.
Agile vs. scrum
The methodology debates aren't limited to agile vs. waterfall but are common even in agile circles deliberating what is and isn't "agile." Much of this in-fighting is related to confusion over the meaning of agile. Because scrum is such a popular agile methodology, many people use the terms agile and scrum interchangeably, when, in fact, there are many methodologies other than scrum that would be considered agile.
There is even disagreement between scrum experts about best practices, because what may be considered a best practice in one setting may not apply in another. What are the rules in these methodologies, and who exactly creates or enforces them?
If we look at agile methodologies on a scale from prescriptive to adaptive, we find that scrum has nine defined rules for what needs to be present, categorized by three roles, three ceremonies, and three artifacts:
- Scrum master
- Product owner
- Team
- Sprint planning meetings
- Daily scrum
- Sprint review
- Product backlog
- Sprint backlog
- Burndown chart
The more specific rules or processes associated with each of these can vary, although there are many resources available that provide best practices associated with each.
There are many other practices and techniques that are considered agile and are used in conjunction with scrum and even with waterfall. Code reviews, unit testing, and automation testing, for example, are practices that have been around since the early days of software development. Although included in a list of "agile practices," they're certainly still used by organizations practicing waterfall. Many people speak as though agile and waterfall are complete opposites, but there's actually quite a bit of commonality. And certainly there are many organizations that use a methodology that has its basis in scrum and has morphed over time to include practices that may have originated from XP or anther agile methodology.
Mixing agile and waterfall
By now you're getting the picture: it's natural and even encouraged in some agile circles to mix techniques to create a custom methodology, depending on the needs of the organization. On the other hand, some scrum purists are adamant that scrum and waterfall don't mix.
In fact, the term Scrummerfall has been defined as:
The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone (Brad Wilson).
A slightly less negative, yet still cautionary interpretation is WaterScrum:
Co-dependent Waterfall and Scrum projects. Similar to trying to play (American) football and soccer on the same field at the same time, requiring extra levels of coordination and timing (Kevin Neher).
However, the increasingly popular Scaled Agile Framework (SAFe®) methodology supports and even promotes a hybrid approach to software development that combines elements of agile/scrum and waterfall. With SAFe®, agile/scrum and waterfall have different fundamentals, but they're complementary for complex, n-tier architecture web-application development, providing the standardization and regulatory requirements required in some industries, such as automotive and medical.
Stop the process wars
One of the first things that needs to happen when managing agile and waterfall hybrids is to stop finding fault with the differing processes and find some common ground. The methodology process wars must end and, instead, the teams must focus on providing value for the customer. There must be an attitude across the organization that the teams are working together, not against each other.
Dependencies and integration points between the teams must be well understood. This is where planning, communication, and coordination is necessary. As Ken Rubin describes in his book, Essential Scrum, in scrum, planning is done at these five levels:
- Portfolio
- Product
- Release
- Sprint
- Daily
At the early levels of planning, the differences between waterfall and agile teams may not cause issues. However, as the details and dependencies emerge, the differences in planning may cause frustration for the teams. Agile teams progressively plan at each level. Waterfall teams do more planning up front and may want answers and commitments that the agile teams don't feel prepared to give. Project managers, product owners, and stakeholders from all teams need to meet, communicate, and collaborate regularly, always keeping their common mission of providing customer value in mind.
Maintaining synchronization
The synchronization and amount of communication needed between teams will differ, depending on the level of dependencies between teams.
In the paper, "Mixing Agile and Waterfall Development in the Scaled Agile Framework," Ken France outlines three scenarios for mixed environments: independent teams, low dependency teams, and high dependency teams and approaches for how the releases can best be synchronized. The paper provides detailed mapping into touch-points and meetings required, ranging from minimal for independent teams to frequent for high dependency teams.
The role of the PMO
SAFe® recommends an agile project management office (PMO) that provides governance across all teams. The PMO would maintain the same core functions as a traditional PMO, but use agile and lean concepts in its operation. Establishing a common and agreed-upon governance across all teams, the PMO is able to monitor and steer the overall portfolio to map to the organization's vision.
What about tools?
In order for the PMO to properly monitor the projects, they need tools that will provide metrics and reporting at the release, product, and portfolio levels, regardless of the methodology being used by the teams. Recognizing this need, there are ALM tools that provide synchronization of agile and waterfall projects, as well as visibility from the team level to the portfolio level.
These tools gather artifacts from both agile and waterfall projects and merge them into a common platform. By integrating the artifacts provided by the teams, a common central repository can house the content, status, and quality data from each team. This data can be aggregated and help to provide status transparency and a fuller look at the big picture.
In summary
There's no one right answer on how to develop software. Though many organizations are moving to agile methodologies, they're still likely to find themselves depending on teams using the waterfall approach. When this occurs, rather than feeling doomed to failure, teams can learn how to communicate, coordinate, and plan for success. In the end, all teams have the common goal of providing value to the customer. Cooperation and communication between teams, regardless of methodology, is the key to success.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
