12What Scrum doesn't cover

The Scrum Guide describes the framework as purposefully incomplete. That minimalism is a strength when organisations complete it. When they don't, the missing pieces are either ignored or handled by a project manager who officially does not exist.

The gaps

Section 05 showed that several PMBOK knowledge areas have no home in Scrum. In practice, the main gaps are:

• Funding and cost. Budgets, business cases and cost tracking.
• Contracts and procurement. Fixed-price contracts, suppliers and subcontractors whose commitments must align with a backlog that changes every sprint.
• Dependencies between teams. Scrum describes one team. Products built by several teams need coordination that the framework does not provide.
• Portfolio decisions. Which products to fund, continue or stop.
• Release, operations and support. Go-live coordination, run activities and incident handling.
• Regulatory deliverables. Design documentation, traceability, verification records, risk files and submissions.

How the shadow project manager appears

Organisations that do not consciously complete Scrum end up completing it unconsciously, in one of three ways. A Scrum Master quietly becomes a project manager, chasing tasks and producing status reports. A project management office maintains a parallel plan outside the team, disconnected from the backlog. Or a scaling framework is introduced as a package, without understanding which accountabilities it is meant to restore. In each case, the project manager comes back without the authority, clarity and tools the role used to have, and the team pretends the role does not exist.

The honest alternative is to name the accountabilities Scrum does not cover, decide who owns each of them, and connect them to the Scrum events. Some will be held by the Product Owner, some by a programme or delivery manager, some by functions outside the team. Bringing in a project manager is perfectly compatible with Scrum, provided the role coordinates what lies outside the team instead of directing the work inside it.

Scope is a good example. In a shadow-managed project, changes arrive as requests to whoever seems to be in charge, and their effect on the plan is discovered later. In Scrum, every change goes through the Product Backlog, is weighed against the goal of the current release, and is communicated to stakeholders with its impact on the forecast. With a fixed date, something comes in only if something of similar size goes out. Flexible scope is managed scope, not unmanaged scope.

Regulated teams, an accidental control group

Regulated industries offer an instructive contrast. In medical device software, IEC 62304 requires a documented software architecture for safety classes B and C, together with traceability between requirements, design, code and tests. Regulation forces back into the project some of the outer loop that Scrum-in-name-only teams drop elsewhere.

Regulated teams therefore drift less on architecture and planning, but they can drift differently. The most common pattern is documentation produced once, shortly before an audit, while the code continues to evolve away from it. The architecture exists on paper and nowhere else. The same lesson holds: an accountability that is satisfied for an external audience, instead of being owned by the team, decays just as surely.