A framework is just a named way of working. Pick the lightest one that answers the question you have today. Each card below says what it is, when to use it, how a Scrum Master might apply it, what goes wrong, and where to read more.
Cards start folded. Expand one at a time. The open card fills the width and the rest move below.
Team methodology
Scrum
Lightweight agile framework with accountabilities, events and artefacts for a usable Increment each Sprint. The Scrum Master coaches effectiveness and empiricism.
When to use it
Stable team with a clear Product Owner
Need planning, review and retro cadence around a Sprint Goal
Value emerges through thin vertical slices and inspection
Example for a Scrum Master
Your primary map. Coach accountabilities and empiricism; protect event purpose; measure success by team ownership and Sprint Goal outcomes, not by how often you speak in events. Partner with the Product Owner on Goal clarity and with Developers on Definition of Done.
Things that go wrong
Ceremony without Definition of Done
Daily Scrum as status theatre to the SM or DM
SM acting as project controller or backlog owner
Team methodology
Kanban
Visualise work, limit WIP and manage flow. Strong fit inside Scrum when interrupt-driven demand or multitasking destroys finish rates.
When to use it
Unscheduled operational demand sits beside Sprint work
Flow metrics matter as much as Sprint commitments
Classes of service need to be explicit
Example for a Scrum Master
Introduce WIP limits and blocked-age reviews when Sprint boards show chronic multitasking. Make expedite policy explicit so urgent BAU does not silently erase the Sprint Goal. Use aging WIP in Daily Scrum and Retro conversations.
Things that go wrong
Board without WIP limits
Ignoring blocked age until everything is red
No policy for expedite versus standard work
Philosophy
Lean
Maximise value and minimise waste through small batches, fast feedback and relentless removal of queues.
When to use it
Queues and hand-offs dominate lead time
Need a shared waste language with sponsors
Approvals and batch size are starving the Sprint Goal
Example for a Scrum Master
Facilitate waste walks on hand-offs and approval queues that starve the Sprint Goal. Cut one real queue before asking the team to go faster. Pair Lean language with WIP and cycle-time evidence so sponsors see the constraint.
Things that go wrong
Lean theatre: posters without removing a real queue
Cost-cutting dressed as waste reduction
Blaming individuals instead of the system
Delivery performance
DORA
Four key metrics for software delivery performance and stability: lead time, deployment frequency, change fail rate and time to restore.
When to use it
Release pain dominates retrospectives
Speed versus stability debates need evidence
Automation investment needs a defensible case
Example for a Scrum Master
When release mechanics dominate retros, use DORA trends to justify smaller batches and automation. Keep metrics as learning signals, not league tables. Pair with DoD so faster deploys do not mean weaker quality.
Things that go wrong
Gaming metrics without outcomes
Using DORA to punish teams
Ignoring stability while chasing deploy frequency
Change
ADKAR
Individual change journey: Awareness, Desire, Knowledge, Ability, Reinforcement. Useful when adopting Scrum itself or a new working agreement.
When to use it
Adoption of new ways of working or tooling
Training alone is not moving behaviour
Resistance shows up as quiet compliance or zombie Scrum
Example for a Scrum Master
When the organisation is adopting Scrum, diagnose Desire and Ability gaps before mandating more ceremonies. Coach Reinforcement after events improve, so old status-theatre habits do not return the week after training.
Things that go wrong
Training before Desire exists
No Reinforcement, so old habits return
Treating ADKAR as a communications plan only
Facilitation
Liberating Structures
A repertoire of facilitation microstructures that distribute participation and replace status monologues with structured interaction.
When to use it
Retros or Reviews dominated by a few voices
Need stronger engagement without heavier process
Psychological safety needs structured turn-taking
Example for a Scrum Master
Replace open-mic retros with structures such as 1-2-4-All or Troika Consulting so quieter voices shape the experiment. Use structures to keep event purpose alive without you becoming the content owner.
Things that go wrong
Novelty for its own sake with no link to purpose
Facilitator over-scripting and killing ownership
Never closing on a single owned experiment
Organisation design
Team Topologies
Patterns for team types and interaction modes so cognitive load and hand-offs stay intentional rather than accidental.
When to use it
Dependencies between teams dominate impediments
Platform or enabling interactions are unclear
Org coaching needs a shared language for team boundaries
Example for a Scrum Master
When cross-team blockers dominate your impediment log, use team types and interaction modes to name the missing enabling or platform support. Escalate structural mismatch upstairs instead of only coaching the team to cope harder.
Things that go wrong
Renaming teams without changing interaction modes
Treating topologies as a reorganisation mandate
Ignoring cognitive load while adding ceremony
Scaling
SAFe
Enterprise scaling with Agile Release Trains and PI Planning. Heavyweight synchronisation when many teams must align on a shared cadence.
When to use it
Many teams must synchronise on a shared cadence
Portfolio-level planning already exists and cannot be ignored
You need a map for organisational impediments inside an ART
Example for a Scrum Master
If ARTs exist, protect team-level Scrum from PI theatre that ignores Sprint Goals. Escalate organisational impediments with evidence. Do not import SAFe ceremony onto a single healthy team that does not need it.
Things that go wrong
Ceremony without healthy team flow
Sprint Goals subordinated to PI fiction
Using SAFe to avoid naming a Product Owner
Civil Service standard
GDS Service Standard
Fourteen points on meeting user needs, providing a good service, and using the right technology for UK public services.
When to use it
UK public service build or iteration
Service assessment preparation
Need a shared quality bar across product, design and delivery
Example for a Scrum Master
Help teams evidence iterative working and user feedback for Service Standard assessments without turning Reviews into compliance demos. Put relevant points into Definition of Done and Sprint Review agendas with the Product Owner.
Things that go wrong
Paperwork-only assessment prep
Leaving accessibility and performance to the last Sprint
Treating the Standard as a reason to abandon empiricism
Civil Service standard
DDaT Profession Capability Framework
What good looks like at each career level for digital, data and technology roles in government, including agile delivery craft.
When to use it
Career conversations and capability gaps
Hiring or levelling Scrum Master / delivery roles
Need a shared language for profession expectations
Example for a Scrum Master
Use DDaT skill statements in coaching conversations and self-assessment. Align your ladder (facilitate to coach to organisational impediments) with the level expectations in your department, even when the local title differs.
Things that go wrong
Treating the framework as a tick-box CV
Ignoring department-specific role maps
Confusing title inflation with accountability growth
Accountability
RACI
Responsible, Accountable, Consulted, Informed matrix for decisions and activities across overlapping delivery roles.
When to use it
Ambiguous ownership across SM, PO, DM and PM
Escalations bounce between roles
Status reporting is duplicated
Example for a Scrum Master
Clarify overlaps with Delivery Manager, Product Owner and Project Manager so coaching time is not spent in role disputes. Publish who is Accountable for backlog order, Sprint Goal protection, RAID and board updates.
Things that go wrong
Matrix never published or updated
Everyone Consulted, nobody Accountable
Using RACI to avoid a difficult conversation
Team practice
Working agreements & Definition of Done
Explicit team rules and a shared quality bar for when work is truly complete. Core instruments of transparency in Scrum.
When to use it
Quality debates land late in the Sprint
Done means different things to PO, Developers and testers
Facilitate a short DoD and working-agreement session early, then revisit in Retro. Include non-functionals and accessibility for public services. Refuse to call work Done when the agreement is ignored, and coach the conflict into the open.
Things that go wrong
Agreements written once and never used
DoD as a tester-only checklist the team ignores
Too many rules nobody can remember
Leadership
Management 3.0 / stewardship practices
People-oriented management practices that treat motivation, feedback and empowerment as system design, not personality.
When to use it
Hero culture and burnout patterns appear
Motivation is treated as a pep talk problem
You need concrete team exercises beyond Scrum events
Example for a Scrum Master
Use lightweight practices (feedback wraps, moving motivators style conversations, delegation boards) when hero culture or quiet stand-ups signal safety or motivation problems. Keep experiments small and owned by the team.
Things that go wrong
Games without follow-through
Manager theatre that avoids hard impediments
Importing tools that clash with Civil Service HR constraints without checking
Decision context
Cynefin (for facilitation choices)
A sense-making framework that separates clear, complicated, complex and chaotic contexts so you pick probes and facilitation style appropriately.
When to use it
The team treats every problem as if best practice already exists
Need to justify experiments versus analysis
Stakeholders demand a plan for a complex problem
Example for a Scrum Master
In Retro or planning debates, name the domain: complex problems need probes and Sprint experiments, not bigger Gantt charts. Coach sponsors away from demanding certainty where only learning will work.
Things that go wrong
Using Cynefin jargon without changing behaviour
Calling everything complex to avoid commitment
Skipping clear-domain standards that already exist (for example accessibility)