Agile vs. Waterfall: Matching Method To Project Requirements
Ever since the Agile Manifesto stood the project management (PM) industry on its head 17 years ago, small business leaders have been asking, “Which method is right for my organization: agile or waterfall?”
This is the wrong question. The truth is that you need to be proficient at both agile and waterfall PM practices so you can apply the right methodology, to the appropriate projects to achieve the best results. Specializing in one at the expense of the other will restrict your customer base and yield narrow profit margins.
The right question—the one that small businesses should be asking—is, “What attributes make a project a better fit for one over the other?”
Understanding what makes a project, or certain parts of a project, a better fit for agile or waterfall practices enables you to:
Reach a larger customer base
Increase project success rates
Forecast staffing needs so you can hire and retain the right talent
Here’s what we’ll cover:
Understanding the “Agile vs. Waterfall” Debate
What Projects Are a Better Fit for Agile?
What Projects Are a Better Fit for Waterfall?
How Can They Work Together for Your Business?
Understanding the “Agile vs. Waterfall” Debate
Before we dive into what makes one project a better fit for agile or waterfall methods, let’s back up and address why “agile vs. waterfall” is a debate in the first place.
With every new year, there are plenty of articles and thought leaders proclaiming the “death” of waterfall. Despite that, waterfall remains the primary delivery model for the majority of organizations.
Source: IT Key Metrics Data 2018: Key Applications Measures: Project Measures: Current Year (full report available to Gartner clients).
According to Gartner, this split has remained more or less the same for the last several years. Managing projects in this way results in roughly 60 percent of projects completed on time and 70 percent completed on budget.
However, traditional or “pure” waterfall does have its drawbacks. Specifically, it’s change averse, meaning requirements, analysis and design are set during planning and should not (i.e., are not expected to) change over the course of the project.
This can be unrealistic for a lot of projects. Change is bound to occur, especially over time on longer initiatives. When projects aren’t set up to accept and respond to change throughout, it can result in lower quality and customer/end user satisfaction.
Which brings us to agile. Agile methods are designed not just to accept change, but to encourage and facilitate change through frequent iterations and customer feedback. These feedback loops help clarify requirements leading to higher quality and customer/end user satisfaction.
However, this cycle can result in scope creep, where requirements continue to be added or changed and the project is never closed. When deliverables are clear from the start, and time and budgets are limited, it isn’t necessary to invite change.
These pros and cons are the basis for the “agile vs. waterfall” debate. And why, overtime, the “pure” applications of waterfall and agile methodologies have been modified and blended in order to achieve more consistent delivery results.
This has resulted in the following spectrum:
Pure waterfall requires stable project requirements and a clear understanding of deliverables. Uses a sequential work breakdown structure (WBS) to forecast the time, budget, and resources needed to deliver the scoped requirements. Work flows from one phase until the next until completed.
Incremental waterfall also requires stable project requirements and clear deliverables. Work is broken into a set of fixed-time, fixed-resource and fixed-cost “waterfalls” or increments, that are run concurrently or sequentially. This method reduces risks commonly associated with pure waterfall and improves quality, as testing is done during each increment rather all at once at the end.
Iterative methods accept that requirements might change and allow for their evolution by adding opportunities for feedback after each increment, or iteration. This helps identify and resolve issues early in the project. Again, testing is performed throughout, rather than all at once at the end, so risks are lessoned and quality improved.
Pure agile does not require stable requirements or clear deliverables to start, expecting the best solution to present itself during the project as a result of feedback from the customer/end user. Work is broken down by function rather than a WBS, and completed in fixed-time and fixed-resource timeboxes.
(Source: The End of the Waterfall as We Know It, full report available to Gartner clients)
So now, rather than deciding between agile and waterfall, the challenge becomes learning how to balance both waterfall and agile methods successfully within one organization.
Hybrid models tend to be misconstrued, implemented incorrectly and poorly executed. Too often people hear “hybrid” and think it means they only need to do “half” the work—they can half learn waterfall processes, half learn agile processes and then apply them half-heartedly.
To borrow from a common phrase, to successfully balance both waterfall and agile methods you have to learn the rules entirely, before you can break them effectively.
And the first step is understanding what makes a project a better fit for a certain methodology.
What Projects Are a Better Fit for Agile?
There are several factors that can make a project a better fit for agile over waterfall. These include:
Unclear requirements/deliverables
Level of participation/input and buy-in from stakeholders
Cost of change is minimal
Emphasis on teamwork, transparency and continuous improvement
These factors tend to align on projects in certain industry segments more often than in others. For example, software development and new product development projects are predominantly (although not exclusively) run as agile.
This type of work benefits from transparency, frequent inspection and adaptation so teams and stakeholders can assess and re-prioritize as needed to deliver the most value.
What Projects Are a Better Fit for Waterfall?
There are several factors that can make a project a better fit for waterfall over agile. These include:
Certainty, or stability, of requirements/deliverables (and lack of flexibility from stakeholders)
Strict budget or timeline constraints (cost of change is high)
Part of a program/portfolio where projects have interdependencies and risks
Compliance and regulatory requirements
These factors tend to align on projects in certain industry segments more often than others. For example, compliance heavy fields such as medical, aviation and food processing often require waterfall methods to adhere to regulations.
Other types of work are simply more sequential and linear in their nature, such as city planning and construction. Projects in these sectors are predominantly (although not exclusively) run as waterfall.
How Can They Work Together for Your Business?
Sometimes you might employ both agile and waterfall processes on a single project. We reached out to industry experts for real-life use cases to demonstrate this scenario.
Planning. It’s not uncommon to use agile principles in the early planning stages when unknowns are high, and teams need to explore possible solutions, regardless of industry norms.
Todd Williams, president of eCameron, Inc., notes that in cases like this, iterations (short work cycles and incorporating feedback loops) act as mini-prototype sessions. For example, if you are developing a new composite and need to validate whether it can replace an alloy, or printing a new component to validate its shape or size.
Applying agile principles at design stages can feed a more predictive waterfall project, and help reduce project costs and time to completion.
Software development for a highly regulated industry. As mentioned, some industry projects lend themselves more to waterfall than agile due to the compliance and regulatory measures, e.g., medtech, life sciences and pharma.
Shelley Iocona, founder and product strategist at ON ITS AXIS, offers the following use case of employing both agile and waterfall methods on a project in a heavily regulated industry:
“If we’re working on a software development project for the pharma industry, we might run the software delivery in an agile fashion with iterative cycles and test-driven feedback. However, when it comes to meeting compliance guidelines and regulatory requirements, that part of the project is best managed in a waterfall fashion.”
In this example, because the project is large, involves many stakeholders and has specific milestones that must be met in a certain sequence under time restraints, Iocona says they’d refer to the project as waterfall, even though the software development part of the project is agile.
External requirements and influences. Cody Swann, CEO of Gunner Technology, believes it’s more accurate to say that clients often don’t fit into pure agile or pure waterfall. Their preference dictates the methods used on projects and small businesses need to be able to blend agile and waterfall to accommodate them.
“We’ve had clients who say they want agile, but then they’ll want deliverables in a waterfall format. All of our resources are trained in both agile and waterfall, so we can easily move resources from one to the other without a problem” he says.
Pure agile or pure waterfall is almost nonexistent at this point. Small businesses can’t afford to be religious with how they operate.
Cody Swann, CEO of Gunner Technology
Recommended Actions
If you’re like the majority of small businesses we speak to each year, you’re already practicing waterfall project management. This means you’ll need to adopt agile practices to ensure you’re set up to run both agile and waterfall projects effectively.
This will require the following:
Shift your company philosophy and project management culture to embody core agile values. This is critical if you want to successfully run both agile and waterfall projects. In fact, companies retaining an opposing philosophy is the number one challenge reported by businesses adopting or scaling agile, as noted by respondents in VersionOne’s 2017 State of Agile report. For tips on adopting a business agile mindset, go here.
Put rules/guidelines in place for matching project requirements to agile or waterfall methods. Make methodology recommendations at the project’s inception. Evaluate the standard factors (discussed above), perform risk assessment and evaluation and have the funding executive team make the final decision based on their risk tolerance.
Provide teams with training, guidance and support. Have an unbiased consultant evaluate your current projects and clients, assess your needs and capabilities and put together a plan on when to hire and when to outsource so you get the right mix of skills.
If you have questions about our recommendations, or are interested in resources where you can learn more about implementing a well-rounded project-strategy, email me at eileen@softwareadvice.com.