Scaling, Adoption and Continuous Improvement in the Agile Organisation
This domain tests whether you can reason about Scrum beyond a single team: how frameworks coordinate multiple teams, what makes adoption succeed or stall, and how improvement is evidenced rather than asserted.
Scaling
Scrum itself says nothing about scaling; scaling frameworks add coordination structure on top of it. Nexus organises roughly three to nine Scrum Teams on one product, with a Nexus Integration Team accountable for integration and a single Product Backlog. LeSS keeps one Product Owner, one backlog and one Definition of Done across many teams, with overall Sprint Reviews and Retrospectives. SAFe groups teams into an Agile Release Train that plans together at regular intervals. Scrum@Scale centres on a Scrum of Scrums and a scaled Product Owner function. Select on the basis of dependency and product shape, not popularity.
Adoption
Adoption is organisational change, not tooling. A sequence that works: make the case in business terms, pick one product with a real customer and a willing sponsor, form a genuine cross-functional team with an empowered Product Owner, install a coaching Scrum Master, and only then expand. Predictable barriers are structural: annual budgets and fixed-scope contracts, appraisal and bonus schemes rewarding individual utilisation, component teams with hand-offs, and middle managers whose role disappears unless it is redefined.
Continuous improvement and measures
Improvement must be evidenced. Retrospective actions should be tracked and reviewed. Velocity is a planning aid for one team, never a productivity target or a cross-team comparison. Better measures come from evidence-based management: current value, time to market, ability to innovate, and unrealised value. Shift conversations from output to outcomes.
Worked example
Sixty people want to "go SAFe" because delivery is slow. Reasoning: first check whether a single team can produce a Done increment each Sprint. If not, scaling multiplies the dysfunction. First move: one product, one empowered Product Owner, three component teams merged into two cross-functional teams, and a shared Definition of Done. Then measure dependency and lead time. If cross-team coordination is still the constraint, add a coordination layer such as Nexus or a Scrum of Scrums rather than a full framework.
Traps
- Using velocity as a performance KPI, which predictably inflates estimates.
- Scaling before single-team Scrum actually works.
- Adopting framework ceremonies and titles without changing budgets, appraisals or decision rights.
- Keeping component teams and calling the result agile - hand-offs remain the bottleneck.