When Waterfall Met Agile: A Hybrid Delivery Story
A mid-sized public agency hired a vendor to replace an aging permitting system. The contract was fixed-price with hard regulatory deadlines — classic conditions for a waterfall plan. But the requirements were genuinely fuzzy: nobody could fully describe how the new workflows should behave until they saw them. The team, scattered across three cities and working remotely after the office closures of the prior year, decided to blend the two worlds. This is what the hybrid looked like, and what it taught them. Names and details have been changed.
How they split the work
The team kept a waterfall spine for the things that genuinely could not move: the regulatory go-live date, the data migration window, and the security accreditation gate. These became fixed milestones on a master schedule, each with a clear owner and a date that everyone treated as real.
Inside that spine, the build itself ran in two-week sprints. The product owner — a senior analyst from the agency, not the vendor — kept a single prioritized backlog. Every fortnight the team demonstrated working software to real permit clerks, who then reshaped the next sprint. The fixed dates told everyone where the train had to arrive; the sprints decided what got loaded into each car.
What nearly went wrong
The hybrid was not smooth at first. Three problems showed up quickly, and they are the ones most hybrid projects hit.
Two reporting languages. The steering committee wanted percent-complete against the plan, while the team measured progress in working increments. For two months the status reports contradicted each other. They fixed it by mapping completed backlog items to the milestone they fed, so one chart served both audiences.
A frozen scope that was not frozen. Because the contract was fixed-price, every change felt like a fight. The team introduced a lightweight change protocol: small adjustments inside a sprint were free, but anything that touched a fixed milestone went through a short, documented impact review. That single rule cut the friction dramatically.
Remote silence. Working across three cities, the team mistook quiet for agreement. A developer spent a week building the wrong validation rule because a decision made in chat never reached him. They moved key decisions into a written, searchable log and made the daily standup the place where blockers were named out loud.
The lessons worth borrowing
By the go-live, the system shipped on the regulatory date with the features clerks actually needed, and the inevitable trade-offs landed on the lower-priority items rather than the legally required ones. Looking back, the team credited a handful of habits that any hybrid project can copy.
Be explicit about which parts are fixed and which are flexible — and never let that boundary blur.
Keep one backlog and one owner who decides priority, even when the schedule is governed by milestones.
Translate progress into one shared picture so executives and the team are reading the same reality.
Make change cheap inside a sprint and deliberate when it touches a fixed date.
In a remote team, write decisions down; spoken agreement evaporates.
Hybrid delivery is not a compromise that pleases no one. Done deliberately, it lets you honour fixed commitments while still discovering the right solution as you go — which is exactly what this project needed.
If you are balancing fixed deadlines against uncertain requirements and want a delivery approach that fits the reality of the work, XNM's program & project delivery advisory can help you design and run it.