Mixed methodologies: an agile-waterfall union

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.