SGD & Your Delivery Framework
SGD is not a delivery framework. It is a governance layer that sits alongside whatever framework your team already uses. It does not replace your ceremonies, your board, or your roles — it adds the structure that none of them provide for AI-assisted, multi-repo development.
Here is how SGD maps to the four most common frameworks.
Scrum
Scrum defines how work flows through a team. SGD defines what standards that work must meet and proves it met them.
| Scrum Concept | SGD Equivalent | How They Connect |
|---|---|---|
| Product Backlog Item | Feature Spec | Each PBI that involves code changes gets a feature spec. The spec adds structure: affected repos, acceptance criteria, architectural constraints. |
| Sprint Planning | Spec Review | During planning, the team reviews feature specs for upcoming PBIs. SGD's impact analysis shows which repos and capabilities each spec touches. |
| Definition of Done | Governance Checks | "Done" means all governance checks pass — design system compliance, spec alignment, ADR conformance, coherence score maintained or improved. |
| Sprint Review | Coherence Report | The coherence dashboard replaces vague "it works" demos with measurable evidence: drift scores, compliance coverage, traceability completeness. |
| Sprint Retrospective | Governance Trends | Retrospectives gain data: which governance rules caused the most rework? Which specs were underspecified? Where is coherence declining? |
Role mapping
Product Owner — Owns the feature specs. Defines what should be built and the acceptance criteria. SGD gives the PO visibility into whether specs are being implemented as written, across all affected repos.
Scrum Master — Uses governance metrics to identify process issues. If governance check failure rates are climbing, that is a signal — perhaps specs need more detail, or the design system rules need updating.
Development Team — Works exactly as before, but with better context. AI agents receive spec and design system context automatically via CLAUDE.md. Governance checks run on PRs without manual intervention.
Kanban
Kanban teams operate on continuous flow. SGD fits naturally because governance checks are continuous too — they run on every PR regardless of cadence.
How it maps
WIP Limits — SGD does not impose WIP limits, but coherence scoring provides a natural constraint. If a capability's coherence score is dropping, it signals that too many changes are landing without adequate governance — a leading indicator that WIP may be too high.
Pull-based flow — Feature specs sit in a "Ready for Development" state. Developers pull the next spec, and the governance context flows automatically to their AI tools and PR checks.
Real-time coherence — Kanban teams benefit most from SGD's live dashboards. There are no sprints to batch metrics into — coherence scores, drift trends, and compliance coverage update in real time as PRs merge.
Cycle time insight — SGD tracks time from spec creation to all governance checks passing. This gives Kanban teams a governance-aware cycle time metric that captures rework caused by drift or non-compliance.
SAFe (Scaled Agile Framework)
SAFe adds coordination layers for large organisations. SGD maps cleanly to these layers because it was designed for multi-team, multi-repo governance.
| SAFe Concept | SGD Equivalent | How They Connect |
|---|---|---|
| Agile Release Train (ART) | Capability Group | An ART's repos are grouped into capabilities. Coherence scoring operates at the capability level, giving ART-level visibility. |
| PI Planning | Spec Planning | Feature specs for the upcoming PI are reviewed for cross-capability impact. The DAG manifest shows dependency chains across teams. |
| PI Objectives | Governance Targets | Teams set coherence and compliance targets for the PI. Progress is tracked automatically. |
| System Demo | Coherence Review | ART-level coherence dashboards replace subjective integration assessments with measured scores. |
| Inspect & Adapt | Governance Retrospective | Data-driven: which capabilities improved? Which teams' governance check pass rates declined? Where are the systemic issues? |
| Enabler | Design System / ADR | Architectural enablers map directly to design system rules and ADRs. When an enabler is complete, the governance rules update to enforce it. |
| Solution Train | Cross-Capability DAG | For multi-ART solutions, the DAG manifest captures dependencies across capability groups, enabling impact analysis at the solution level. |
ART-level scoring
SAFe teams particularly benefit from ART-level coherence scoring. Each ART gets an aggregate score based on its constituent capabilities. This gives the Release Train Engineer a single metric for "how well is this train's codebase holding together?" — far more actionable than manual architecture reviews at PI boundaries.
Spotify Model (Tribes, Squads, Chapters, Guilds)
The Spotify model emphasises team autonomy. SGD provides the guardrails that make autonomy sustainable — squads can move fast because the platform catches drift before it compounds.
| Spotify Concept | SGD Equivalent | How They Connect |
|---|---|---|
| Tribe | Capability Group | A tribe's repositories are grouped into related capabilities. Tribe leads see coherence scores across their entire domain. |
| Squad | Feature Spec Owner | Each squad owns the feature specs for its domain. SGD enforces that squad-level changes stay coherent with the broader tribe. |
| Chapter | Design System Contributors | Chapters (e.g., "Backend Chapter") define and maintain design system rules for their discipline. When the backend chapter agrees on a pattern, it becomes a governance rule. |
| Guild | ADR Authors | Cross-cutting guilds (e.g., "Security Guild") author ADRs that apply across tribes. SGD enforces these organisation-wide decisions automatically. |
Autonomy with alignment
The Spotify model's core tension is autonomy vs. alignment. Without governance, autonomy leads to divergence (every squad invents its own patterns). With heavy-handed governance, autonomy is an illusion (every squad follows a rigid standard).
SGD resolves this by making governance measurable and specific. Squads have full autonomy over how they implement features. The platform checks whether the result is coherent with the agreed standards. If a squad wants to deviate from a design system rule, they propose an ADR — the decision is recorded, the governance rule is updated, and the deviation is intentional rather than accidental.
SGD doesn't replace your delivery framework
SGD doesn't replace your delivery framework — it adds the governance layer that none of them provide for AI-assisted development. Whether you run two-week sprints or continuous flow, whether you have one team or twenty ARTs, the six governance layers work the same way. Your framework defines how work moves. SGD defines what standards it must meet.