According to the 2019 State of Agile Report, the overwhelming majority of organizations (97%) say they practice the agile methodology. However, that doesn’t mean that agile is guaranteed to succeed, or that a “waterfall” approach will fail.
Jump to the main takeaways:
As such, there continues to be heated debate in various IT and business circles about which project framework is better.
The waterfall method has amassed an increasingly bad reputation in recent years. It was even touted as one of the major reasons that the U.S. government lost more than $30 billion to failed IT projects that took a waterfall approach over an agile one.
Unfortunately, the agile method isn’t a foolproof development foundation either. The 2018 Standish Group Chaos Study found that only 42% of agile projects were considered completely successful. For small projects, both methods are used nearly 60% of the time.
So what gives? Is agile better than the waterfall methodology? Is the reverse actually true? Or does the real solution lie in creating a hybrid system borrowing from both approaches?
This blog post will answer those questions and more, first by outlining the major differences between agile and waterfall that everyone should know. Then, we’ll look at how to determine which approach (or parts of both) can benefit your organization the most.
Agile vs Waterfall: What Are They?
Before this really gets rolling, let’s define, in the simplest possible terms, what agile and waterfall really are, respectively.
First, it’s crucial to point out that both methodologies are development frameworks. In other words, they each inform how tasks are organized when building and deploying software.
Why is this important? Well, because it means that neither framework is a project management style in and of itself.
Sure, there are agile project management tactics scrum masters or managers can use to streamline various processes. But, because agile management draws from ideologies embedded in the agile methodology, the two aren’t interchangeable.
Here’s what each concept boils down to in its most distilled form:
- Agile is a newer, collaborative development framework based around iterative, team-based workflows.
- Waterfall is a more traditional development framework that adheres to a very specific, linear sequence of events.
It’s worth noting at this point that both methodologies are mature enough to use right out of the box, without any tweaking, depending on your organization’s preferences.
That said, it’s usually in a company’s best interests to really examine either framework closely before attempting any implementation. You’ll become more familiar with the strengths and weaknesses of each, as well as which one ultimately fits better with your current culture and business objectives.
The Agile Methodology: A Closer Look
The agile methodology’s popularity has skyrocketed in recent years, due in no small part to the tech community’s migration from standalone products to SaaS or IaaS business models.
As the software industry continues to move away from server and data center offerings to cloud-based solutions, your average scaled agile framework keeps evolving rapidly.
At the heart of agile’s ongoing refinement is the desire to continuously deliver valuable software to end users. This means optimizing team dynamics as much as the code they create.
As the Agile Alliance’s “Agile 101” guidelines point out:
“One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.”
Some of the qualities that the agile method holds in the highest esteem include:
- The ability to welcome changing requirements, even late in the development game
- The capacity to deliver frequent updates to one app or a larger product suite
- Strong, unified collaboration between developers and stakeholders on the business side
- Teams that can self-organize and still meet project requirements
- The capability to maximize individual and team productivity, regardless of resources
Those principles all lead back to the well-known parameters of the Agile Manifesto, which is listed below:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Embracing the agile development framework means committing to flexible, efficient, and transparent processes.
Without that level of buy-in across your organization, any agile project can fall flat in spite of any individual or team’s intellectual understanding of its components.
The Waterfall Methodology: A Closer Look
By contrast, the waterfall methodology is a more traditional, linear approach to software development. It’s typically built around by a sequence of events that, unlike agile, is inflexible and doesn’t take changing circumstances into account.
Waterfall has also been around for much longer than agile. Thought its roots can be traced back as far as 1956, the first formal description of waterfall method is often attributed to a 1970 article by William W. Royce, though he doesn’t explicitly mention the term.
It’s interesting that, even when the idea of waterfall was in its infancy, its inherent problems were still quite visible, at least to Royce:
“I believe in this concept, but the implementation described above is risky and invites failure [...] The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed [...] Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties.”
However, despite the baggage that still plagues this methodology, it still possesses some redeemable qualities, such as:
- A workflow that flows logically from a clear starting point to an established endpoint
- A larger emphasis on the planning phase, during which user and design requirements are mapped out beforehand
- A verifiable way to reduce operational costs (e.g.–fixing a bug earlier on in the project lifecycle, as opposed to right before completion)
- Because design flaws or coding errors can be caught earlier, execution and implementation can be much quicker
- A higher value placed on documentation, which can make end user learning curves far less steep.
At its core, the waterfall method is far more risk-averse and, as a result, a more rigid way of working compared to agile.
The essence of waterfall’s eponymous metaphor is that water doesn’t flow upstream. Once you pass a certain point in a project, there’s no turning back.
Though this assertion feels archaic in today’s tech climate of “code first, ask questions later,” that doesn’t mean the framework isn’t totally devoid of value, particularly in a large corporate setting.
Making the Right Choice Between Agile and Waterfall
With their respective strengths and weaknesses in full view, how do you know if agile or waterfall is a better framework choice for your organization?
The real answer is that it doesn’t necessarily have to be just one or the other. For many organizations, taking the best of both approaches and fashioning an agile-waterfall hybrid is the right call.
Building a hybrid also doesn’t mean that you have to split the ideologies 50/50. You can take as many or as few aspects from either framework as you wish. The important part is that any customized implementation you create must support your overall business goals.
Otherwise, your development practices will, at the very least, lack the kind of purpose that fuels sustained productivity.
Some advantages that the agile methodology brings to the table include:
- A more dynamic environment that adapts better to changing customer wants and needs
- Shorter execution timelines mean better interpersonal communication, especially between developers and scrum masters
- Agile development teams are usually smaller, which makes for clearer individual objectives and, ideally, more balanced workloads
- A value-driven workflow that can improve the software or product suite on the fly, instead of relying on a potentially flawed original strategy
- It eliminates the scenario of delivering a final product that, if there’s negative user feedback, could take months to upgrade.
Some advantages that the waterfall methodology offers are:
- A more structured framework that underpins every project with clear technical objectives
- A more robust planning stage that builds an extensive project roadmap instead of the “we’ll figure it out later” attitude that agile so often conjures up
- A bigger emphasis on detailed client requirement delivery, which can give both parties a clearer idea of a valuable end product
- A linear timeline that makes it easier to track progress and assess if smaller deliverables are being met
- Testing is also less chaotic because of the emphasis on catching errors early on, as well as in-depth documentation.
By highlighting the best parts of both frameworks, it’s clear that agile and waterfall can easily complement each other instead of one serving as a foil for the other.
As Tracey Brower explains in her Forbes piece on agile, just implementing the more popular framework of the two isn’t always a sure recipe for success:
“Agile is easy to learn and difficult to master. Because it is relatively straightforward to grasp, it can be deceptively simple [...] If you’re picking up agile as a quick fix or an initiative you plan to hastily deploy, you’ll surely fail.”
Sometimes, to get the most out of agile software development, you must borrow from its supposed evil twin. Alexander Rodov and Jordi Teixido state as much in their 2016 paper concerning a functional agile and waterfall hybrid, using project planning as their in-point:
“A clear definition of roles and a disciplined way to develop the initial project deliverables is indispensable for a successful project. In agile projects, the product owner must develop documents and designs for the product backlog with a waterfall approach. The mere use of user stories without a robust document that envisions what the minimum viable product (MVP) will be, will make the project prone to scope creep and unnecessary delays.”
Even if you combine these methodologies into a fluid, all-encompassing framework, that doesn’t mean your work is done.
Monitoring your team’s work by measuring both KPIs and team intangibles will allow you to make necessary improvements over time. Only then can your organization hope to significantly boost efficiency and, by association, maximize their resources.
The agile vs. waterfall conversation has, historically, been a war of words between divided camps of IT and business professionals. Oddly enough, it’s those very differences that make them such great ideologies to draw upon and create customized, powerful development frameworks.
Agile may trounce waterfall in the flexibility and customer feedback departments, but the latter also has a few tricks to teach the former, specifically about how to structure and plan a project.
Those enhancements alone are worth spending time considering your agile-waterfall hybrid options and how the biggest strengths of either framework can optimize your organization’s business operations.
To paraphrase a well-known presidential speech, ask not what agile or waterfall can do for you, but what you can do with the best of both agile and waterfall.
Jira is arguably the best online platform for agile development, but you’re limiting your results if you’re not using Insight as part of your Atlassian environment.
With unparalleled data and asset management features, the Insight product suite has changed the work lives of thousands of customers in more than 90 countries. See what all the buzz is about and even start your free trial by clicking below!
Originally published Mar 10, 2020 3:00:00 AM