Skip to content

Mixed methodologies: an agile-waterfall union

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content

Can agile and waterfall methodologies really be combined without causing more headaches than they’re worth? Yes, but it takes some compromise and adjustment.

Today’s IT project leaders might think they suffer from dual-personality disorder. They’ve grown accustomed to conventional project management, which typically follows a waterfall methodology, whereby projects move progressively through each step of a defined process, with each one “checked off” before moving on to the next. But, project management methodologies are changing - where waterfall used to be the gold standard for every project, agile is quickly becoming the favourite. And then some teams opt for a mixed methodology environment.

Whether transitioning from one methodology to another, or trying to use both simultaneously, project managers often struggle to find a balance between the project dates and the feature sets they need to deliver—and the sprints and iterations their development teams are tracking against.

Like any “marriage,” it takes some adjustment and compromise to make it work. Not only does it mean learning something entirely new while still trying to get the work done, it also makes managing, tracking, reporting and collaborating on projects extremely chaotic and time consuming—almost as if the two sides speak different languages. Teams spend more time trying to “translate” and figure out what’s going on than making progress on the project. However, understanding both the differences and the benefits of these two methodologies is the best way to make the marriage work.

Methodology merits
It’s not that one methodology is better or worse than the other. Both waterfall and agile have their merits. The problem is that they both work best in different applications, which is why trying to marry the two can be a lot like the proverbial round-peg, square-hole problem. Waterfall is very detailed, predictive and based on meticulous planning. However, it’s primarily a top-down system that’s particularly useful with a manufacturing process for prototyping or building a physical product. There’s very little room for change or evolution along the way, and revisions often require teams to start completely over from scratch. Testing is often the last step of the process, which means any bugs discovered are fixed last, which could take quite a while and hold up delivery.

Agile, on the other hand, can actually take one of several forms, all designed to be more flexible, fluid and iterative, focusing on rapid development—delivering a product faster, even if it’s still a “working draft.” While agile does allow the flexibility to react to changing needs and new developments, there’s also no specific beginning and end to a project. It’s basically done when the client is happy, which means the end result could look completely different than what you envisioned at the beginning. The agile process also requires total trust in the team to complete the work on-time and on-budget because it’s very difficult to track conventional metrics along the way.

A messy mixture
Given the differences, and the fact that some aspects of each are polar opposites of the conventions of the other, it’s easy to see how switching from one to the other or combining the two can cause friction within the organisation. But in reality, combining the two actually gives any organisation the best of both worlds, allowing each team to use the methodology that works best for them.

However, combining the two can be a hot mess. Teams using one method will likely need to interact with teams using the other. Without the right training in the unfamiliar method, the two teams will have a hard time communicating and collaborating. Frustration and confusion over deadlines, deliverables and expectations can cause internal strife that could sabotage the entire project.

Project leaders who have to manage mixed methodologies will especially struggle with merging the logistics, including timelines, metrics, due dates, time and cost budgets. Because most typical project management software does not support the use of both agile and waterfall, it often requires team leaders to invest far too much time entering and managing duplicate data and integrating information into something that everyone can understand.

Make a successful marriage
It’s tempting to resist the urge to marry the two out of fear it might be too complicated, confusing and costly in terms of time, resources and effort. But, when the business case for mixing the two makes sense—the ability to let your teams work more effectively and efficiently—there are several ways to get the most out of each methodology, without causing your employees to lose their minds.

1. Clearly communicate the benefits and expectations.
Recognise that change is difficult and don’t expect an overnight success. Ease the transition by carefully outlining the advantages to this new dual-method approach. There will be new language, new procedures and new software to learn, which adds to their existing workload. Pre-empt resistance by outlining the “what’s in it for me?” benefits to employees can be a huge incentive for both faster adoption and training participation. Namely, team members and stakeholders will get less manual reporting, more accurate data, and a much more favorable perception with their boss - and they should know that up front.

2. Merge metrics.
Trying to track two sets of non-integrated metrics can be a nightmare, so find a way to merge them. For most managers and the C-suite, waterfall-style reporting makes the most sense - they want to know how the project stands per the objectives, timeline and budget expectations. But, this requires project leaders to “translate” project status from agile into these neatly defined metrics. Remember that, ultimately, all metrics center around three primary factors, regardless of methodology: what are we working on, what is the current status and when will it be done. Train project leaders in how to make the translations, to satisfy both sides of the aisle.

3. Create and measure against benchmarks.
Despite some likely resistance from the agile camp, you must set some clearly-defined benchmarks for project success. To ease the discomfort, start by establishing mutual agreement about how you will measure success based on business objectives, time and budget targets, sales or whatever other metrics you choose. Collect data along the way and track progress against those markers. Compare these against the waterfall metrics to measure success at each step in the process or timeline, and use this global view to make decisions about how and when to move forward.

By far, the biggest challenge in most organisations isn’t what method to use, but instead it’s culture and a fear of change. And, the reality is that forcing employees to completely shift the way they work can have a serious negative impact on productivity and morale. Fortunately, a massive sea change is not always required, nor is it the best option. By adopting flexible work management solutions that allow teams to work in the methodology that works best for them, you can achieve a successful marriage that results in increased visibility and productivity across the entire organisation.

To learn more about how to tackle the challenges of a mixed methodology IT department, download this whitepaper: A Manager’s Guide to Mixing Agile and Waterfall.


Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Seamus O'Sullivan
    Seamus O'Sullivan 20 June 2015, 07:37 AM

    At 3gamma we have found a mixed approach can work well in some instances. A particular case study can be found here. Anthony correctly points out, it is understanding what the particular combination of project, team and company need. 

  2. Russell Whitworth
    Russell Whitworth 03 June 2015, 07:49 PM

     Excellent article. And if anyone is hesitating about the download - please do it; it completes the picture.PMOs may dislike Agile projects, but Agile projects despise PMOs! They need to learn to coexist and support one another.

  3. Sue Mundicha-Katerere
    Sue Mundicha-Katerere 17 May 2015, 05:13 PM

    This is a very useful article and found it very informative for me in adding to my knowledgeThank you 

  4. Antony Della Porta
    Antony Della Porta 16 May 2015, 11:37 PM

    Here is a thought: the two recognised methods of business change delivery (project delivery) have not been around that long, the "techniques" they foster have been around for decades, just not with a "title". Its down to the mind-set, experience and skill of the PM and how that is then "projected" to the wider team as to how the outcomes will be delivered - the "project approach".By this I am saying that too many get caught up in looking a which method to use or varient there-off. This is not relevant, it is understanding what approach and techniques the project needs and when in the project, that is required. When recovering a project in difficulties, this understanding becomes more apparent, however, just as important when running one that is not in dire-straits. I know from 35 years + practical experience.When a PM insticntively know and understands this, the rest of the orchestration, the mechanics of delivery, follows.

  5. Shawn Dickerson
    Shawn Dickerson 21 May 2015, 01:24 AM

    Great point, Antony. I don't disagree, but what we find in a great many enterprises is that "accidental project managers" are often drafted from other functions instead of being trained in a specific discipline - which tends to require a less-complex approach to balancing the work approaches on various teams.