Hybrid delivery and agile exam questions

Project Compass was hybrid from the start: a predictive fit-out, predictive and incremental technology work, an adaptive app and a transition to operations. This last lesson pulls the course together by looking at how the parts were governed, contracted, reported and integrated, and how the app reached the soft opening. It ends with habits for answering the agile and hybrid questions that make up most of the 2026 PMP exam.

Common hybrid patterns

Hybrid projects come in several recurring shapes. In the first, a predictive project contains one or more adaptive components, as Compass does. In the second, adaptive teams work inside predictive governance: the organization funds work in stages with gates, while teams deliver in sprints between gates. In the third, the approach changes over time, for example iterative discovery and prototyping, then agile development, then a predictive rollout to many sites. In the fourth, agile practices are used selectively within a predictive project, such as daily stand-ups and visual boards on a construction site or iterative reviews of a design.

Integrating the parts

The hardest part of a hybrid project is usually the seams. The predictive and adaptive parts run at different rhythms and measure progress differently, yet they depend on each other. The Compass project manager identified three integration points early and put them on both plans: the catalogue test environment had to be ready before app sprint 3; the end-to-end test of kiosks, gates and app against the live catalogue had to happen after substantial completion and before the soft opening; and staff training needed a stable build of release 1 two weeks before opening. Each integration point had an owner, a date and acceptance criteria.

Integration also needs shared rhythms. The project manager attended app sprint reviews to see the product and hear stakeholder feedback, and invited the product owner to the fortnightly construction coordination meeting. A monthly integrated planning session, where leads from fit-out, technology and app looked at the next two months together, caught several dependencies, including the need for wireless access points to be live before app testing in the branch.

Governance and funding

Agile work challenges governance designed for predictive projects. Stage gates that require a fully detailed scope before funding, or change control boards that must approve every backlog change, fight against adaptive delivery. Useful adaptations include gates based on demonstrated increments and outcomes rather than documents, funding a team's capacity for a period rather than a fixed scope, and delegating backlog decisions to the product owner within agreed boundaries such as the product goal and budget.

On Compass, the board approved the app as a capacity budget: one team for up to ten sprints, within the time and materials ceiling of $210,000. The change control board continued to control changes to the project scope baseline, the overall budget, the opening date and the contract, but changes within the app backlog were the product owner's decisions. When the board later considered adding a second community room, a change to the fit-out, that went through change control (PMP-131, lesson 11); when Amara moved renewals to release 1.1, it did not.

Contracts for agile work

Fixed-price, fixed-scope contracts sit uneasily with adaptive delivery, because they assume scope can be defined in advance. Common alternatives include time and materials with a not-to-exceed ceiling, which Compass used; fixed price per sprint or per increment, with scope chosen sprint by sprint; capped time and materials with shared savings; and graduated fixed-price arrangements. Jeff Sutherland described two clauses sometimes added to agile contracts: "change for free", where the customer can swap backlog items of equal size without cost, and "money for nothing", where the customer can stop early once enough value has been delivered and pay a fraction of the remaining value.

Whatever the model, agile contracts work best when they focus on collaboration and transparency: frequent reviews, shared access to the backlog and burn-up, clear definitions of done and acceptance, and mechanisms for changing scope without renegotiating the whole contract. The Compass contract required the firm to provide sprint reports and attend reviews, and made the library's acceptance depend on the definition of done.

Risk in agile work

Agile approaches manage many risks through their structure: short iterations limit how far a team can go in the wrong direction, frequent reviews surface misunderstandings, and working increments reduce the risk of ending with nothing. Teams also manage risk explicitly. A risk-adjusted backlog places risk-reduction work, such as spikes and early integration, high in the order; the WSJF calculation in lesson 8 did this by scoring risk reduction. Risks that teams cannot handle themselves, such as vendor delays or funding, go to the project-level risk register, where the project manager manages them with the sponsor.

One status view

A hybrid project still needs a single, honest picture for the sponsor. The Compass monthly board pack combined earned value for the fit-out and technology with the release burn-up for the app, a risk summary and the integration milestones. The code reproduces the month 6 headline figures.

# One status view for a hybrid project: earned value for the predictive parts,
# release burn-up for the app. Money in thousands of dollars.
pv, ev, ac = 1440, 1290, 1400
print(f"Fit-out and technology: SPI {ev / pv:.2f}, CPI {ev / ac:.2f}")
done, scope, velocity, sprints_left = 128, 190, 21.3, 3
need = (scope - done) / sprints_left
print(f"App release 1: {scope - done} points left, needs {need:.1f} per sprint vs velocity {velocity}")
print("App release 1 on track" if velocity >= need else "App release 1 at risk")

Fit-out and technology: SPI 0.90, CPI 0.92
App release 1: 62 points left, needs 20.7 per sprint vs velocity 21.3
App release 1 on track

The predictive parts were behind schedule and over cost (SPI 0.90, CPI 0.92, as PMP-130 and PMP-131 analysed), while the app looked on track on averages. Lesson 9 showed why the app's "on track" needed a closer look: with variability and scope growth, the chance of finishing all of release 1 in three sprints was only about one in five, which led the product owner to move renewals to release 1.1. A good status view shows both kinds of evidence side by side without forcing them into one misleading index.

How release 1 landed

Release 1 (search, holds with queue position and notifications by email, account management, accessibility to WCAG 2.1 AA) was deployed behind a feature flag a week before the soft opening, tested by staff in the branch and switched on for patrons on opening day. Renewals followed in release 1.1 two weeks later, as forecast. In the first two months, about a third of Eastgate holds were placed through the app, short of the 40 % target, and task completion for sign-in was low. The team's first post-launch sprint focused on simplifying sign-in, guided by those outcome measures. Release 2, room booking and event sign-up, moved into the library's ongoing product work after the project closed, with the app team funded from the operating budget.

Transition is part of hybrid delivery too. The project's closure (PMP-131, lesson 12) handed the app to a product team rather than to a maintenance group, with the product owner, backlog and definition of done carrying on. That choice reflected the app's nature: a product that would keep evolving, not a deliverable that would be finished.

Answering agile and hybrid exam questions

Because about 60 % of the exam draws on adaptive and hybrid approaches, it pays to have a set of habits for these questions. The PMP exam does not test one framework's rulebook; it tests judgement consistent with agile values and PMI's guidance. The patterns below summarize the course.

Two cautions complete the picture. First, watch the words "first" and "next": understanding the situation (talking to the product owner, reviewing the board, asking the team) often comes before acting. Second, the most agile-sounding option is not always right. If a project has a fixed regulatory deadline, a contract or safety constraints, the best answer respects them while applying agile practices where they fit. Tailoring, not ideology, is what PMI rewards.