Walk into almost any large organization and you’ll find a mix. The contract with a supplier follows a fixed plan. The regulatory filing has a date set by someone outside the company. Meanwhile, the software team down the hall works in two-week iterations and changes its priorities as it learns. Nobody designed this combination. It just happened. We think the better approach is to design it on purpose.
Why mixing makes sense
Plan-driven (predictive) methods suit work where scope is clear, change is costly, and commitments are external: procurement, construction, contracts, and regulatory milestones. Iterative (adaptive) methods suit work where you’re still learning what the customer needs: product and software development. A program that includes both is normal, not a failure of discipline.
The trouble starts when the mix is accidental. The agile team doesn’t know that a vendor delivery is fixed for March. The predictive plan assumes the software scope is frozen when it isn’t. Each side blames the other, and the program manager spends the week translating.
Three things that make hybrid work
Clear interfaces. Decide where the plan-driven and iterative parts meet. What does the iterative team commit to, and by when? What does the fixed-date work promise to supply? Write down these handoffs the way you would for any dependency, and agree on who owns each one.
One integrated roadmap. Keep a single view of the whole program, at a level of detail both sides can use. It should show fixed milestones as fixed and iterative work as ranges or themes. Leaders then see the full picture without forcing the iterative work into a false precision.
Consistent risk and dependency management. Use one risk register and one dependency list across the program. The cadence can differ: the predictive side might review monthly, and the iterative side every sprint. But the information must flow in both directions, or surprises will surface at the worst moment.
An example
Picture a utility replacing its customer billing system. The contracts, data center changes, and regulatory approvals follow a conventional plan. The customer portal and mobile experience are built in short iterations, with feedback from real users. The program manager keeps one roadmap, with the regulatory date marked as immovable and the portal shown as a sequence of releases. A weekly dependency review catches a mismatch between a vendor interface and the portal team’s needs, six weeks before it would have caused a delay.
If you suspect your organization already runs hybrid delivery by accident, start by mapping where the approaches meet, and ask who is responsible for each handoff. That single exercise often reveals the biggest risks. We’re glad to help with that mapping if it would be useful.