Coffee Talk: Java, News, Stories and Opinions

Jun 12 2017   11:25PM GMT

Why Waterfall sometimes wins the Agile versus Waterfall debate

Daisy.McCarty Profile: Daisy.McCarty

Tags:

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 that’s the case 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.” 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 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 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.

1  Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • ScottAmbler
    I like much of what is in the article, but disagree with a few things.  First, agile is better than traditional approaches at getting it right the first time due to the tighter feedback cycle and greater stakeholder participation that you typically seen in agile.  Second, it is very easy to align deliver teams in agile with common cadences, in particular common sprint lengths and common release cadences.  In fact there's a practice called "release train" in Disciplined Agile and SAFe that does exactly this.  Third, fulfilling the scope is generally a bad strategy in practice (do a search on the term BRUF to verify this).  Fourth, Agile is much less risky than traditional in practice due to the greater transparency provided by agile.  Industry success rates for traditional and agile bear out the claim that agile is less risky.  Interestingly, organizations experienced with both agile and traditional appear to be assigning their riskier projects to agile teams over their traditional teams in practice.   For a more detailed take on when I would suggest a traditional strategy, I think you'll find http://www.disciplinedagiledelivery.com/traditional-development-make-sense/ to be interesting.
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: