Why hybrid agile-waterfall projects fail
A recent HPE survey of 403 Development and IT professionals, performed by YouGov, revealed that pure agile projects are more successful than those that use a combination of agile and waterfall approaches. Of those surveyed, nearly one-third (32%) were using an agile-waterfall hybrid model.
While agile-only organizations rated themselves the highest, hybrid projects fared the worst on every measure. Why? Because the hybrid approach “straddles two development methodologies that naturally pull in different directions,” the report says. But that directly contradicts the results of a report by CAST Software, which concluded that the hybrid approach leads to higher quality than either pure waterfall or pure agile.
If hybrid is such a bad idea, why did one-third of organizations surveyed follow the hybrid path? Why have so many organizations that followed the hybrid model failed to meet expectations? And what can organizations do to improve their chances of success, particularly when working with a hybrid model?
Why so many organizations use a hybrid model
It’s no surprise that the survey results conclude that mixing agile and waterfall yields lower success rates than agile approaches. Mixing the most popular agile framework, scrum, with waterfall, has been described with a variety of terms, including scrummerfall, water-scrum, and water-scrumfall. But whatever term you use, most agile experts strongly discourage the practice of mixing waterfall and agile.
Why then, would organizations ignore these words of warning? One reason is that in a large enterprise, it’s very difficult to switch from traditional waterfall methodologies to a pure agile approach.
The survey targeted organizations with greater than 500 employees, and if these large organizations have established processes and tools that use traditional practices, it would take significant time and effort to switch to using only agile practices. Thus, many organizations start by introducing some pieces of agile without entirely letting go of many of the waterfall practices, resulting in this hybrid approach.
Malcolm Isaacs, an enterprise agile expert at HPE, says:
“For most of these organizations that take a hybrid approach, this is an interim step, and they intend to gradually expand their agile activities beyond the development and testing stages to the rest of the software development lifecycle.”
Another reason that organizations may choose to use a hybrid model is to meet compliance and regulatory requirements, which require more rigorous documentation and governance than you get in a pure agile shop.
ReQtest chairman of the board Ulf Eriksson, in his post, Combining Agile and Waterfall Methodologies: Overkill or Genius Idea? recommends an 80/20 split with an emphasis on agile, but he still suggests retaining some of the documentation rigor used with waterfall methodology. In the post, he notes that a hybrid approach would allow for more predictability (from waterfall) as well as the ability to respond to feedback quicker (from agile).
Eriksson prefers a pure agile model whenever possible. But he acknowledges that many organizations are restrained by a waterfall project model, ITIL, or another framework that takes a long time to replace with agile methods.
"Companies have to fundamentally change the way they are working by making budgeting and business planning more agile. Until that point, many have to live with a blended environment.” —Ulf Eriksson
Donnie Berkholz, Research Director, Development, DevOps & IT Ops at 451 Group, agrees that the cultural change required is a big barrier to complete agile transformation. Combining waterfall and agile feels comfortable and doesn't require as many changes from a cultural perspective.
"The shift in mindset and operating model required to move to a series of sprints rather than an end deadline, which is likely to run late and over budget even if the project does get completed, is one that many traditional companies find difficult.” —Donnie Berkholz
Why performance and success metrics are lower with hybrid
The HPE study asked teams to self-assess their performance across 25 recommended practices, such as “small team” or “good customer relationship.” It defined project success using six metrics, including quality and performance, time to market, speed of delivery, scope, security, and cost/use of resources.
In the performance ratings, as well as the success metrics, the hybrid approach fared lower than the agile-only approach.
So why did a hybrid approach show lower success metrics than pure agile? Isaacs sees a correlation between the performance ratings (the self-assessments on agile practices) and the project success metrics. “Hybrid organizations say that they do less automated testing and automated integration, and have little automated infrastructure. Performing these activities manually takes longer and is less consistent, particularly for repetitive tasks."
Of the 25 performance ratings, Isaacs says those related to automation are areas that can have a direct effect on success metrics. Indeed, many of the practices related to automation, such as continuous integration, originated from the agile framework XP (extreme programming), and have frequently come under the heading of “DevOps.”
Might it make sense then, for teams to just add DevOps practices to their waterfall methodology? While it’s possible to run DevOps practices in a waterfall environment, HPE technology evangelist John Jeremiah writes, “If you try to optimize delivery in a waterfall-siloed world, you'll exert lots of energy and feel like you're working hard, but you probably won't deliver the business results you could.”
CAST counterpoint: Hybrid approach yields higher code quality
While it might seem obvious that pure agile is the preferred approach, a 2014 Research on Application Software Health report by CAST Software, a vendor of software analysis and measurement tools, found that a mixed waterfall/agile methodology yielded better code quality than either pure waterfall or pure agile methods.
Primary report author Dr. Bill Curtis, a senior vice president and chief scientist of CAST Software, says his assessment of the findings was that quality suffered under pure models.
“Our research shows that applications produced using traditional agile or waterfall methods alone have more security vulnerabilities, more reliability and performance issues, and a higher cost to maintain than those produced with a mixed method.” —Dr. Bill Curtis
One reason for the perceived inconsistency between the HPE survey and the CAST report is that not all teams that claim to be agile are using the framework as intended. CAST executive vice president Lev Lesokhin, a co-author of the report, noted that many organizations claim agility, yet they just use it “as an excuse to do whatever they want and crank out code quickly.”
Lesokhin also cites the importance of a solid architecture up front. Some agile teams let the architecture emerge, which creates problems down the line, when refactoring is difficult. “It’s becoming increasingly important to secure your architectural quality and design before writing the first line of code,” he says.
What to do when you must take a hybrid approach
Large organizations are often forced to find ways to mix methodologies, or at least have them co-exist. Even those organizations attempting to transition to agile may be dependent on an infrastructure that has many complex dependencies on traditional methodologies, or they may be working with vendors using a waterfall framework.
Although faced with challenges that may seem futile to resolve, managers and teams can work toward improving their chances of success when managing agile and waterfall together. There are ways that waterfall and agile teams can successfully co-exist. Coordination and communication on a regular cadence, early and frequent integration, and remaining flexible to change, while accommodating and respecting differences in methodologies are all areas that can help improve success.
Berkholz says the most important agile practice is to connect business requirements to the end user. If companies are doing agile only within the development organization, they’re missing out on the potential for improving product-market fit, he says. So even if your is technically a success, you might have built the wrong thing.
"Without testing on end users and iterating based on their feedback, it’s impossible to truly succeed.” —Donnie Berkholz
Isaacs recommends focusing on areas that are within your control, making team changes that will lead to short-term wins and improve the team’s metrics and deliverables. Sharing, mentoring, and helping others move towards agility will lead to improvements.
“You might not be able to change the model directly, but you may be able to influence it." —Malcolm Isaacs
Continuous improvement leads to success
Large-scale transformation to pure agile is difficult. Which agile practices will lead to success? You've heard a variety of answers from experts, but for teams to mature in agility and improve their chances for success, your organization needs to practice continuous improvement.
By including frequent and regular opportunities for the team to reflect and improve,they can determine its biggest issues, and work together toward improving those. As they adopt more agile practices, your team needs to let go of traditional practices that may conflict with the agile practices they’re adopting.
Some teams make the mistake of adding agile practices while continuing to require all of the traditional practices as well. This leads to frustration, since it not only will require more time and effort than either pure waterfall or pure agile, but will cause confusion and delays when the practices are in conflict.
Practices that are required for compliance or for ensuring a high-quality and secure architecture can be done in a well-disciplined agile environment.
By remaining aware of the benefits that an agile approach will provide, and continually evaluating and improving, teams can ultimately improve their overall performance ratings and success metrics.