Hybrid delivery and scaling agile

0:00 When agile and predictive meet

An airline in the UAE, fictional, is upgrading its check-in experience. New airport kiosks need hardware procurement, installation and certification: very predictive. A new mobile app needs rapid iteration with real passengers: very agile. And integration with the departure control system, managed with a vendor, sits somewhere in between. One programme, three kinds of work, one go-live that the public will notice if it goes wrong. That's hybrid delivery, and in twenty twenty-six it's the norm rather than the exception. In this lecture you'll learn the common hybrid patterns, a step-by-step way to make hybrid work, how organisations scale agile across multiple teams, how to manage dependencies with a simple board, and how to report progress when some teams use burnups and others use Gantt charts.

0:55 Why it matters

Why does this matter? Because most real projects contain different kinds of work, and forcing everything into one approach creates friction: detailed Gantt charts for exploratory software, or two-week sprints for concrete foundations. Hybrid lets each part work in the way that suits it. But hybrid introduces a new failure point: integration. The places where agile and predictive work meet, shared milestones, vendor interfaces, test environments and go-live, are where schedules slip and blame starts. And reporting has to translate between worlds, so a board can understand progress from a burnup chart and a Gantt chart in the same conversation.

1:38 The concept: common patterns

Here are four common patterns. First, a predictive frame with agile delivery inside: the overall phases and budget are planned, but the build phase runs in sprints. Second, an agile product with predictive gates: teams iterate continuously, but releases pass through fixed compliance or security gates. Third, parallel workstreams joined at milestones, like our airline: kiosks on a plan, the app in sprints, integration in between, all converging on shared dates. And fourth, hybrid with vendors: interfaces and contractual milestones are fixed, while features within them flex. Think of an orchestra where the strings, brass and percussion rehearse separately, in their own ways, but everyone knows exactly which bars they must hit together. The skill is in those shared bars.

2:30 Making hybrid work, step by step

Here's how to make it work. Step one: classify the workstreams and choose a lifecycle for each, using the scoring framework from earlier in the course. Step two: agree a small number of shared milestones and the interfaces between workstreams, including what each must deliver to the other and when. Step three: one governance structure, with one integrated RAID log and one dependency view, so risks and dependencies across workstreams are managed together. Step four: translate progress into a common language, typically confidence in hitting each shared milestone. The agile team converts its burnup into a probability; the predictive team reports schedule float against the same milestone. Now the board can compare them directly.

3:20 Scaling agile across teams

When several teams work on one product, they need coordination. The basics are the same whatever framework you use: a shared cadence so sprints line up, joint planning so teams see each other's dependencies, and integrated reviews where a combined increment is inspected. Several published frameworks structure this, such as SAFe, LeSS, Nexus and Scrum at Scale. They differ in how much structure they add, and each has its own guidance, so check the current version before adopting one. My advice: start with the minimum coordination that works. Many organisations add layers of roles and ceremonies before they've fixed the basics of shared cadence and a visible dependency board. More process doesn't fix unclear priorities or tightly coupled architecture.

4:12 Worked example one: a dependency board

Let's build a simple dependency board. Each row is one dependency: which team needs it, which team or vendor provides it, what exactly is needed, by when, and its status. For example: the app team needs version two of the check-in API from the vendor by week ten. The kiosk team needs network ports installed by facilities by week eight. The test team needs a production-like environment from infrastructure by week twelve. Review it weekly with all the leads, not just in a status report. When a dependency turns red, link it to the milestone it threatens and escalate with options. It's the simplest tool in hybrid delivery, and in my experience it prevents more integration failures than any sophisticated framework.

5:05 Worked example two: the UAE airline

Back to the fictional UAE airline. Kiosks followed a predictive plan through procurement, installation and certification. The mobile app was built in sprints. Integration with the departure control system was managed with a vendor, with fixed interface milestones. One programme board governed all three, with three shared milestones: kiosk installation at the first airport, an app release with a mobile boarding pass, and integrated go-live. Each month, the app team converted its release burnup into a confidence level for the integrated go-live. When the vendor's integration slipped, the app team didn't wait. They re-prioritised features that didn't depend on the integration, such as seat maps and notifications, so their work stayed valuable and the go-live date was protected. That's hybrid working as intended: independent where possible, coordinated where necessary.

6:01 Watch me do it: milestone confidence from a burnup

Let me show you how an agile team can give a predictive programme board a number it can use. For the milestone, take the remaining scope, say one hundred and twenty points, and the number of sprints left before the milestone date, say six. Take the team's recent velocities. Then run a quick simulation: for each run, randomly pick six velocities from the recent history, add them up, and check whether they cover the remaining scope. Repeat twenty thousand times. The share of runs that finish is the probability of meeting the milestone. Here it's only about sixty per cent. But look what happens if we reduce the release scope by just ten points: confidence jumps to almost certain. Now the board can compare that with the predictive team's float on the same milestone, and make a genuine trade-off decision about scope for that release. The code is in the lesson text.

7:07 Contracts, reporting, mistakes, recap and try this now

A note on contracts: in hybrid delivery with vendors, fix what must be fixed, interfaces, integration dates and quality standards, and leave room for features to flex, ideally with milestones based on outcomes. The common mistakes: separate governance for agile and predictive parts, so trade-offs are never made together; dependencies that live in people's heads; and adopting a heavy scaling framework before fixing the basics. So, to recap. Hybrid is the norm: choose a lifecycle per workstream, agree shared milestones and interfaces, run one governance with one RAID and dependency view, and translate progress into milestone confidence. Scale with the minimum coordination that works. Your try-this-now: create a dependency board for a multi-team or multi-vendor project and review it with the teams involved this week.