Why does Waterfall sometimes wins the Agile versus Waterfall?

Agile gets all the press, but Waterfall has proven to be a fairly trustworthy approach to software development for a very long time. It’s definitely not going anywhere. In fact, it’s still the preferred methodology for many of the world’s largest enterprises for some very good reasons, so don’t ever think that the Agile versus Waterfall debate has been concluded.

At a recent Agile vs. Waterfall Debate, which pitted the two methodologies against each other, four experienced technology professionals dug deep into both approaches. The conclusion at the end of the night was unanimous: It’s imperative to choose a process that works for the organization and for the situation at hand. And sometimes, that’s still Waterfall. Here are five ways to tell if you might want to pick Waterfall over Agile or the Scrum framework in an upcoming project.

#1 The project has to be right the first time

With all its flaws, Waterfall is still the most time-tested method for software development. It is designed to provide maximum control and reduce uncertainty. For situations with clear requirements, regulatory compliance factors, and a strong possibility that failure will mean lots of very bad press, most enterprises will opt for Waterfall in the Agile versus Waterfall debate, just to stay on the safe side. Mark Yarbro, performance test manager at a major financial institution, put it plainly. “When we screw up, it is front page news. It’s got to be right the first time.” Scrum and Agile may get things done fast, but there’s still a risk of missing the mark. “You’ve got to be doing the right thing, not just doing the wrong things faster.” Cyclic waterfall is often used where speed and control need to be balanced.

#2 Timing and coordination are essential

Mark deals with the issue of synchronizing multiple teams on a daily basis. “We have twelve hundred applications. We release many of them on a ninety day cycle. The way it works is we get everyone together so they are working in lock step. It’s very difficult to release one product when it doesn’t line up with the others. We are doing performance testing on thirty different apps to get them all ready at the same time.” It’s not just the apps, but the platforms and the entire ecosystem that must be upgraded simultaneously. That’s not something that Agile is good at doing, and one reason why being Agile is so difficult to scale. “Agile is a great way to get things done if you don’t know what you need, if the customer is not being clear. But it’s much more difficult to get everyone lined up and releasing at the same time.”

#3 Fulfilling the scope is the point of the project

Obviously, it’s ideal to have a workable piece of software at the end of the day, but both Agile and Waterfall have been known to fail in that regard. Waterfall tends to place more emphasis on the process of doing the work according to the plan. Sometimes, that’s just about making the project as profitable as possible for those providing the software development or related services. Enterprise Agile Coach Jay Packlick pulled no punches in shining a light on why Waterfall is a tempting choice when pockets are deep. “If you’re a government contractor getting paid by the number of hours, the answer might be I’m going to optimize for stuff. What is your customer optimized on? IS my problem getting solved? To be clear, Agile tends to be biased on delivering what you need. It’s generally value focused. Waterfall is biased toward delivering lot of billable stuff.”

Satyapal Chhabra, Founder and Managing Principal at Ideliver, agreed to an extent, but pointed out that well-defined scope can be a good thing. “Waterfall is about the scope. Not because you don’t want to deliver the value, but because the scope is driven by someone who is qualified, who knows what is needed.” Knowledge and expertise are highly valued in Waterfall when it comes to creating the overall plan and setting the course of action. In contrast, “Agile tends to think, ‘We can do it because we have inclusion by the right people.’ That’s where Agile becomes cyclic and goes on forever. Waterfall tends to at least deliver something that you can hand out at the end.”

Of course the notorious Motorola phone and the original Obamacare marketplace website were both brought up in the debate as examples of technically delivering the scope but not a usable end result. But in a reasonably well run Waterfall project, the scope would encompass the value and help the project from getting pulled off course to pursue other objectives.

#4 High level stakeholders don’t like risk

For organizations that are used to Waterfall, making the transition to Agile may prove a bridge too far to cross, making the whole Agile versus Waterfall debate moot. Mark admitted that Agile is a superior methodology in many ways, but it relies heavily on the human factor. “Agile is ugly and messy. Real Scrum is so much fun. It’s a battle royale, muddy and messy, and you get so much accomplished. But it’s not pretty. Management, especially in big organizations, is very intolerant of messy, seemingly out of control processes. The whole organization has to change. People have to think and act differently all the way up the chain, and it’s hard to change human behavior.” In that case, getting Agile off the ground might actually take longer and deliver poorer results than sticking with traditional methods.

#5 The culture doesn’t mesh with Agile

Speaking of people, when teams are made up of less skilled or less self-directed people, or when feedback and collaboration are not highly valued, Waterfall may be the only functional option. Jay cautioned against trying to go Agile or do Scrum in the wrong circumstances. “If I’m working in an organization where I give the boss bad news and get fired, if everyone shuts up when the boss walks into the room, if I’m in a place where people don’t give a crap, they just want to get in, get a paycheck and get out, they don’t want to have a conversation or do Kumbaya, they’re probably not going to succeed with that framework. You have to fit your framework to your problem, cultural or otherwise. Don’t try to shove Cinderella’s slipper on her big fat sister, because it ain’t gonna fit.” To mix one final metaphor, when the Waterfall fits, go with the flow.

App Architecture
Software Quality
Cloud Computing
Security
SearchAWS
Close