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 Delivery Manager 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 Product Owner, Scrum Master and Developers, plus Sprint events and a Definition of Done for a usable Increment.
When to use it
Stable team with a clear backlog owner
Need a predictable cadence of planning, review and retro
Value emerges through thin vertical slices each Sprint
Example for a Delivery Manager
As DM, treat Scrum as the team's operating system: protect Sprint Goal focus, keep refinement honest, and escalate outside the team when Sprint commitments are broken by unplanned demand you did not agree.
Things that go wrong
Turning Daily Scrum into a status report to the DM
Skipping capacity checks in planning
Calling it Scrum while ignoring Definition of Done
Team methodology
Kanban
Visualise work, limit WIP, manage flow. Strong fit for interrupt-driven or continuous-service teams.
When to use it
Unscheduled operational or support-heavy demand
Need flow metrics more than fixed Sprint commitments
Work types vary and cannot be batch-planned cleanly
Example for a Delivery Manager
Use Kanban when your delivery team is drowning in tickets. As DM, set WIP limits, make classes of service explicit, and report cycle time and blocked age instead of story points theatre.
Things that go wrong
No WIP limits means it is a board, not Kanban
Ignoring blocked age until the board turns red
Philosophy
Lean
Maximise value, minimise waste. Small batches, fast feedback, respect for people.
When to use it
Hand-offs and queues dominate lead time
You need a shared language for waste with sponsors
Optimising the whole value stream, not one team local optimum
Example for a Delivery Manager
Run a simple value-stream map of request-to-live. As DM, cut approval queues and batch sizes before you ask the team to 'go faster'.
Things that go wrong
Lean theatre: posters without removing a real queue
Cost-cutting dressed as waste reduction that burns capacity
Scaling
SAFe
Enterprise scaling with Agile Release Trains, PI Planning and layered roles. Heavyweight by design.
When to use it
Many teams must synchronise on a shared cadence
Organisation already committed to an ART model
Portfolio visibility across dozens of teams is the hard problem
Example for a Delivery Manager
If sponsors push SAFe, show them the MAP-01 scale/formality trade-off. As Lead DM, only adopt the PI Planning and ART coordination pieces you need; do not import every layer because the chart looks complete.
Things that go wrong
Installing SAFe as ceremony without fixing team-level flow
Role inflation that creates more hand-offs
Project + agile
PRINCE2 Agile
Keeps PRINCE2 control (stages, tolerances, business case) while teams deliver iteratively.
When to use it
Project-shaped funding with stage gates
Need clear tolerances for time, cost and scope
Agile teams inside a governed project wrapper
Example for a Delivery Manager
Use PRINCE2 Agile when the SRO needs stage control and the teams need Sprints. As DM, own the delivery interface: map Sprint forecasts into stage tolerances and keep RAID shared with the Project Manager.
Things that go wrong
Double reporting: project dashboard and agile board that disagree
Stage gates that freeze learning mid-discovery
Programme
MSP (Managing Successful Programmes)
Programme framework with 7 principles, 7 themes and 7 processes for outcome-led change across multiple projects.
When to use it
Multiple related projects serve one strategic outcome
Benefits realisation spans years and organisations
Need programme-level governance above team methods
Example for a Delivery Manager
In government multi-team programmes, run MSP at programme level and Scrum or Kanban inside workstreams. As Lead DM, hold tranches, benefits and cross-project dependencies while coaching workstream DMs.
Things that go wrong
Treating the programme as a big project with more slides
Benefits registers that nobody owns after go-live
Civil Service standard
GDS Service Standard
Fourteen points on meeting user needs, providing a good service, and using the right technology.
When to use it
Building or iterating a UK public service
Preparing for service assessment
Need a shared quality bar across product, design and delivery
Example for a Delivery Manager
As DM, put Service Standard points into the Definition of Done and show evidence (research, accessibility, performance) in reviews so assessment is not a scramble at the end.
Things that go wrong
Treating assessment as a paperwork exercise
Leaving accessibility and performance to the last sprint
Civil Service standard
GovS 002 Project Delivery
Mandated functional standard for portfolios, programmes and projects. Shall and should language.
When to use it
Government project or programme delivery
Need mandatory governance clauses clear to assurance
Aligning PMO, SRO and delivery teams on control expectations
Example for a Delivery Manager
Map your reporting rhythm and decision rights to GovS 002 shall clauses. As DM, use it to push back on invented local bureaucracy that is not required, and to insist on what is.
Things that go wrong
Gold-plating beyond the standard
Ignoring shall clauses until IPA assurance arrives
Business case
Green Book / Five Case Model
HMT appraisal guidance and the Strategic, Economic, Commercial, Financial and Management cases.
When to use it
Seeking or refreshing public funding
Comparing options with economic and strategic rationale
SOC to OBC to FBC lifecycle
Example for a Delivery Manager
As DM, own the Management Case delivery plan and benefits realism. Bring honest velocity and dependency risk into Economic and Financial cases before optimism bias is locked into a date.
Things that go wrong
Business case as fiction written once and never updated
Management Case that ignores team capacity
Delivery performance
DORA
Four key metrics: deployment frequency, lead time for changes, change fail rate, failed deployment recovery time.
When to use it
Need evidence that delivery is getting healthier
Debating speed vs stability with execs
Platform or product teams with deployable software
Example for a Delivery Manager
Report DORA trends alongside RAG. As DM, use them to show whether 'delivery at pace' is real flow or just pressure, and to justify investment in CI/CD and rollback.
Things that go wrong
Gaming metrics without improving user outcomes
Applying DORA to non-deployable work without adaptation
Prioritisation
MoSCoW
Must, Should, Could, Won't for a fixed timebox. Forces scope honesty under a deadline.
When to use it
Fixed deadline with negotiable scope
Stakeholder workshops that need a shared scope line
Example for a Delivery Manager
Facilitating scope talks as DM: lock Musts to capacity, keep a named arbiter (usually PO or SRO) so everything does not drift into Must.
Things that go wrong
Everything becomes Must
Won't list disappears after the workshop
Prioritisation
WSJF
Weighted Shortest Job First: cost of delay divided by job size for a defensible order of work.
When to use it
Several competing programme asks for the same capacity
Need a transparent ranking sponsors can challenge on inputs
Example for a Delivery Manager
Run a WSJF workshop when three directorates fight for the same platform team. As DM, facilitate cost-of-delay estimates and refuse to rank without named assumptions.
Things that go wrong
Garbage-in cost of delay
Treating scores as precision science
Prioritisation
RICE
Reach × Impact × Confidence ÷ Effort for product-style backlogs.
When to use it
Many small backlog items to compare
Product Owner wants a scoring scaffold for trade-offs
Example for a Delivery Manager
Support the PO with RICE when the backlog is noisy. As DM, challenge Confidence inflation and keep Effort estimates owned by the people doing the work.
Things that go wrong
Confidence theatre
Using RICE for large programme bets it cannot express