Hybrid Project Methods: Combining Waterfall and Agile Sensibly

You combine waterfall and agile sensibly by steering the frame and milestones together with approvals on a plan and delivering the work inside that frame in short iterations. The combination pays off wherever one part of an undertaking is bound by fixed constraints such as contracts, hardware or certification, while another part can only be clarified by trying things out. What matters is that each method applies exactly where its strength lies and that the transitions between the two are defined in advance.

This article describes four patterns for hybrid projects, a decision tool with four criteria and the interfaces at which hybrid undertakings fail in practice. It is written for managing directors and heads of department who need a common way of steering in an organisation with both traditional and agile teams.

Why is a single method often not enough?

A single method is not enough because undertakings consist of parts with different costs of change. A production line that is ordered and installed can hardly be altered after delivery. The software that controls it can be adjusted weekly. Anyone who steers both in the same way either plans the software too early and too rigidly or lets the hardware run like an experiment.

The history of waterfall shows that the separation of methods is itself a simplification. In 1970 Winston Royce described in a paper on managing the development of large software systems the sequential approach of requirements and design, implementation and testing, and considered it risky when it runs without feedback between the phases. Later practice turned the warning into a template. The counterpart, the Scrum Guide 2020, describes iterations of one month at most and presumes a Product Goal at which the work aims. Neither text rules out a combination, and practice often demands one: with the seventh edition of the PMBOK Guide in 2021, the Project Management Institute moved from a process-based to a principle-based description and made tailoring the method to the context a principle.

Which patterns exist for hybrid projects?

Four patterns have proved themselves in practice. In the first, the plan-based frame with agile delivery, the organisation steers budget and milestones as well as approvals on a traditional plan and delivers in sprints within each phase. In the second, the agile core with fixed milestones, teams work iteratively while leadership sets deadlines for board decisions, trade fairs or contract partners as fixed anchors. In the third, the parallel track, one part of the undertaking develops to plan, such as hardware, a building or an installation, and another iteratively, such as software or process design. In the fourth, agile clarification with plan-based rollout, a discovery phase tests iteratively what is to be built, after which it is rolled out in a fixed plan.

Which pattern fits is decided by the nature of the constraints. Fixed-price contracts with acceptance favour the plan-based frame, as the article on agile fixed-price projects shows. Deadlines tied to external events favour fixed milestones, whose planning the article on milestone planning in agile programmes describes. A part with a long procurement time favours the parallel track.

A simple rule gives orientation. If at least three of the first four criteria point to plan-based, you steer the sub-project by plan. If at least three point to iterative, you steer it iteratively. At two against two, the undertaking is cut too large, and it is worth splitting it into parts before choosing the method.

Where do hybrid projects fail?

Hybrid projects fail at the interfaces between the parts. Four interfaces decide: plan and backlog; budget and scope; report and reality; roles and accountability.

At the interface of plan and backlog the most frequent error arises: the plan contains functions with dates, the backlog contains work in cycles, and nobody holds the two together. A shared level of milestones phrased as outcomes, such as “pilot line in operation”, closes the gap. The backlog then supplies the pieces that lead to the milestone. The article on Big Room Planning shows how teams resolve dependencies in this setting.

At the interface of budget and scope, two logics collide. The plan assumes a fixed scope and a fixed budget, while iterative work adjusts the scope. The way out is a budget released in tranches, each after a review with a visible result, and a scope graded into must-have and nice-to-have. The frame then stands firm, and the team keeps room to adapt.

With report and reality a silent error appears: the project reports traffic lights by plan while the teams work in sprints by value, and the two reports describe different things. A joint report uses a few indicators that apply in both worlds, such as lead time, the share of milestones reached and open dependencies.

With roles, finally, the question of who is accountable for the overall result must be answered. The project manager is accountable for frame and milestones, the Product Owner for the value of the iterative parts, and someone has to hold the interface between the two. In many organisations a delivery manager takes on that task.

How do you introduce a hybrid project?

You introduce a hybrid project in five steps. First, the undertaking is split into parts and each part is assessed with the criteria from the table. Then leadership fixes the steering for each part and writes it down in a project charter that also names the transitions. In the third step the joint frame emerges from milestones as outcomes, released budget tranches and a report with shared indicators. In the fourth step the parts start with their respective methods, with iterative teams tying their rhythm to the milestones. In the fifth step the steering group meets at a fixed rhythm, for example every four weeks, checks the handovers and adjusts the assignment when the cost of change or the clarity has shifted.

Anyone who has to choose between two team methods inside the iterative parts will find the criteria in the article on Scrum or Kanban.

Which failure modes are typical?

The most frequent failure mode is waterfall with an agile facade. The organisation calls phases sprints and specifications backlogs but changes neither approvals nor reports, so the teams work to plan and merely use different names. The mirror image is agile busyness: teams iterate without a frame, and nobody can say when which result is promised. A third failure mode is the method war, in which traditional project managers and agile roles wrestle over responsibilities because no level connects them. In all three cases nobody has settled who decides where, and about what.

Hybrid projects with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects from VC-funded scale-ups to DAX 40 corporations and in more than 20 countries on six continents. In the service area of delivery management and organisation design he works as delivery manager, project manager or product owner at exactly the interfaces at which hybrid undertakings are decided.

The approach follows the Niehues Delivery Model with three phases. For hybrid projects, two of its test questions matter: Who decides, who delivers, who uses? Which roles and decision paths as well as interfaces does operations need? The entry point is a free 30-minute initial consultation, which you can arrange through the contact form. The scope and terms of an engagement are discussed in the free initial consultation.