How to manage agile and waterfall methodologies together?

Two teams in the same company, both delivering parts of the same program. One reports in two-week sprints and cannot tell you what will be finished in November. The other has a schedule that says exactly what will be finished in November, and has not changed it since March. The steering committee asks “are we on track?” and gets two answers that cannot be added together.

That is the problem worth solving, and it is not about picking a methodology. It is what happens when an organization runs two of them without deciding how they meet.

Two ways of ordering the same work

As the name suggests, predictive delivery uses a sequential process design. Work flows from a starting point to an end point through phases, typically conception, initiation, analysis, design, construction, testing, deployment and maintenance. Think of assembling a car: certain steps have to be finished before the next can begin. Planning happens up front, and the plan becomes a baseline that later change requests are measured against.

That sequential model is usually traced to Winston Royce’s 1970 paper on managing the development of large software systems, which is where the waterfall diagram comes from. It is worth remembering that Royce presented the pure sequential version as the risky one and argued for iteration around it. The industry kept his diagram and dropped his caveat.

Agile delivery uses an iterative approach to the final product. There is no predetermined action plan covering the whole project. Instead the team fixes a cadence, usually called a sprint, and decides again at the start of each one what to build next. Customers intervene while the work is in flight, and testing happens alongside construction instead of after it. As a named movement, agile dates from the Agile Manifesto of February 2001, written in reaction to exactly the closed sequential processes described above.

Predictive delivery fixes the scope and controls change against a baseline. Agile delivery fixes the cadence instead, and decides the scope again at every increment.

Between those two poles sit the iterative and incremental variants. Our article on project life cycles sets out the full taxonomy.

	Predictive	Agile
Fixed before work starts	Scope, schedule and budget	The cadence and the team, not the scope
How change is absorbed	Change control against a baseline	Reprioritized at the next increment
When the client sees the product	Late, at or near delivery	At the end of every increment
What documentation is for	Continuity and handover	Working product over documents
Cost of losing a team member	Absorbed, the plan carries the knowledge	High, the context lives in the team

What agile buys you

Agile offers a genuinely flexible model, able to adapt as the world around the project changes. The work is split into small pieces handled by independent groups that run simultaneously and talk to each other. Clients take part and the product is tested while it is being built, which keeps the result aligned with what is actually needed rather than what was needed at kickoff.

That makes agile especially useful when the objective is not clearly defined, or when the client does not yet know exactly what they need. Mutual feedback pulls the two definitions of success together over time, instead of discovering at the end that they never matched.

Communication carries the weight here: inside each team, between the teams sharing a project’s tasks, and between all of them and the client. It is what keeps the result coherent with objectives that are still moving.

What predictive buys you

Nothing starts in a predictive project until there is a clear objective and a meticulous plan. Because you know exactly where you want to arrive and how, the project tends to get there quickly and safely once it is under way. Accurate schedules and budgets can be produced before execution and then met with few deviations, and that correspondence between promise and delivery is what clients value most.

The claim only holds if you measure progress against the plan rather than against effort burned. Progress and hours consumed are different quantities, and treating the second as a proxy for the first is how a project stays green until the week it slips.

Schedule position = % completed − % expected today

That comparison needs a live baseline behind it. In ITM Platform, progress is reported from the timesheet, the task Progress tab or the Gantt, never derived from hours, which is what makes the “% expected today” and “baseline versus % expected” indicators meaningful. Their setup is covered in waterfall project tracking.

The second advantage is documentation. This way of working leaves an extensive record of what has to be done at each moment, so if a team member cannot see the project through, someone else can take their place after catching up on where things stand.

Where agile hurts

Precisely because of that flexibility, agile can show a very weak structure. Planning accuracy suffers, from delivery dates to budgets, and with no concrete plan everything can feel like it is floating.

• Communication, personal involvement and collaboration are not optional extras, they are the conditions for the method to work. With teams that do not collaborate well, agile struggles.
• Close and permanent communication consumes time, in meetings and in the exchange of context that makes them useful.
• Agile depends far more on the same people being present from beginning to end. Losing a team member hurts more than it would on a predictive project.

The answer to the weak structure complaint is not to bolt a Gantt chart onto an agile team. It is to measure something else. A burndown chart shows expected against actual progress, but it hides work in progress and copes badly with a growing backlog. A cumulative flow diagram fixes both and yields work in progress and cycle time, the two numbers that tell you whether an agile team is predictable, in a context where a schedule variance would mean nothing. Both charts are described in agile project tracking.

Where predictive hurts

The main drawback of predictive delivery is that it is less flexible, and it is less flexible for a reason: the certainty it offers is bought by planning a long way ahead. Altering the project at any stage can be a nightmare for the project manager, because once the whole plan has been analyzed, changes are hard to introduce. Every dependency downstream has to be revisited.

The second drawback is timing. Client feedback and test results do not arrive until the project is well advanced. If something is wrong, you cannot respond until late, and late responses cost far more time, effort and money than early ones.

So which one is better?

Choosing between them is the project manager’s job, weighed against the needs of the project, the demands of the client and the team actually available.

Agile suits those who know which direction they want to walk in but not exactly where they want to arrive. Predictive suits projects expected to stay still, where no changes are anticipated during execution.

Those are guidelines, not rules, and the choice belongs to each project. In any organization running more than a handful of projects at once, the honest answer at portfolio level is not one or the other, it is both.

Running both without forcing one on everybody

The two can co-exist in a single environment, but only if that co-existence is designed. Start with the people: project managers, task performers and stakeholders all need to understand the differences and appreciate what each approach offers. Looking for fault, or ranking one above the other, only sets the whole thing back.

Then give both a shared unit of time, which is the practical version of the advice to “keep them synchronized”. Sprints do not have to belong only to agile boards: a predictive project can carry sprints too, so a Gantt can be filtered and sorted by sprint while a board is navigated by that same sprint. Enable them per project or per project type and allocate tasks in bulk, as described in sprints, and the mixed portfolio has one cadence to report against instead of two calendars nobody can reconcile.

Governance is the other half. A project management office keeps both kinds of team pointing at the organization’s objectives and reads each one with the right instrument. That is a different PMO from the one that only polices plans, and it is the subject of our piece on the agile PMO.

The real obstacle is not the methodology

The biggest challenge companies face is not deciding between agile and waterfall. It is fear of change. Forcing people to abandon the way they work is difficult, often disastrous, and unnecessary. Let each team keep the method that suits its work, agree on how progress is measured and when it is reported, and the union between the two stops being a compromise and starts being an advantage.

Next steps

• Start a free ITM Platform trial and run one agile board and one Gantt project side by side in the same portfolio.
• See how planning and monitoring handles both kinds of project in one place.
• Enable a shared cadence first: sprints work on agile boards and predictive schedules alike.