14The small-project myth

A common belief holds that Scrum works for small projects but not for large ones, still less for long-lived or regulated products. The belief is understandable, because Scrum-in-name-only teams do fail in those settings. The failure belongs to the drift, not to the framework.

Large products

The Scrum Guide sets the size of a Scrum Team at typically ten people or fewer. That is the size of a team, not of a product. Scrum scales by combining teams around one Product Backlog, not by enlarging them, and several frameworks describe how: Nexus (Ken Schwaber), Large-Scale Scrum or LeSS (Craig Larman and Bas Vodde), Scrum@Scale (Jeff Sutherland) and SAFe.

These frameworks differ widely in philosophy, but they share a revealing feature: at scale, they bring PMBOK's knowledge areas back, distributed and adapted.

Table 6 · Scaling frameworks restore the accountabilities that single-team Scrum leaves outside its scope.

Large-scale Scrum works when these accountabilities return. It fails when organisations multiply Scrum teams without them, which is the same drift at a larger scale, with more people caught in the loop.

Long-lived products

Scrum is arguably better suited to long-lived products than to short projects. The Scrum Guide speaks of products and Product Goals rather than project closure, and the Agile Manifesto's eighth principle calls for a pace that can be sustained indefinitely. The condition is technical excellence. Without continuous attention to design, debt accumulates until delivery stalls, as section 08 described. The longer the product lives, the more that condition matters, and the more visibly Scrum-in-name-only fails.

Regulated products

Medical device software shows that Scrum and regulation are compatible.

• IEC 62304 requires activities and deliverables; it does not prescribe a lifecycle model or a sequence.
• AAMI TIR45 gives specific guidance on applying agile practices to medical device software, and the FDA recognises it as a consensus standard.
• Design controls, which in the United States now sit under the Quality Management System Regulation aligning 21 CFR 820 with ISO 13485, require traceable design inputs, outputs, verification and reviews. These can be produced incrementally, sprint by sprint, rather than in a single upfront phase.

The real difficulty is documentation discipline: keeping the architecture description, the traceability and the risk file current every sprint, instead of reconstructing them before an audit. That is a Definition of Done problem, not a framework problem. Regulated teams that build documentation into "done" often end up with better traceability than waterfall projects, because it is maintained continuously instead of written in a rush at the end.

Scope changes follow the same logic. Each one enters through the backlog, is assessed against the release goal and, as IEC 62304 requires, for its impact on the risk analysis and on verification. A late addition also changes what the customer will have to validate. Here agile scope management meets what the PMBOK Guide calls integrated change control: the mechanism differs, but the discipline is the same.

The overall pattern is consistent. Small projects are simply where the drift has the least time to cause harm. As size, lifespan and regulatory weight increase, Scrum-in-name-only fails faster and more visibly, while Scrum practised with its essence holds up.