SHIFT Agile Framework

The Coordination Failure. When organisations have more than one team, most frameworks break down. Scrum of Scrums is a band-aid. SAFe adds so much ceremony that teams spend more time coordinating than delivering. Most organisations end up with an informal coordination layer of side conversations and management escalations that do not scale.

The Innovation Failure. Delivery pressure always wins over exploration. The people closest to the problems, the delivery team, are also the people best positioned to solve them. But they never get protected space to try. SHIFT makes exploration structurally mandatory, not aspirational.

The Alignment Failure. Teams set OKRs in January and discover in March that the sprint work had no measurable connection to them. Most frameworks do not have a mechanism for mid-sprint alignment checking. SHIFT does.

The AI Transition Failure. Teams adopt AI tools within frameworks designed before AI existed. Story points were never designed for a production function where one well-specified task produces ten times the output of a vague one. SHIFT was built knowing that AI-assisted work is the default, not the exception.

An Adaptive Collaboration Node is the primary delivery unit in SHIFT. The word 'node' is deliberate: it implies connectivity, not isolation. An ACN has clear internal structure, a defined scope of ownership, and explicit interfaces to other nodes.

An ACN owns a capability domain, not a feature list. It is responsible for the full vertical slice of work within that domain: from specification through testing through deployment. It owns outcomes, not outputs. An ACN forms around a capability domain when that domain requires more than two cycles of sustained delivery.

Node size runs from a minimum of 3 to a maximum of 9 people. The optimal size for full SHIFT operation is 5 to 7. Every ACN maintains an AI Responsibility Map: a one-page document defining which tasks are AI-assisted, which are AI-led with human review, and which are human-only. Every ACN publishes a Node Health Card after each sprint: throughput trend, DOI alignment status, IIS status, and open cross-node dependencies, readable in 90 seconds.

ACNs dissolve when their capability domain is complete, when throughput signals indicate sustained delivery failure, or when team size drops below three without approved backfill. Dissolution takes two sprints. The dissolving node's Learning Cards remain in the shared pattern library permanently.

A Lean Governance Pod is SHIFT's answer to the governance tax problem. In most scaled frameworks, governance consumes 20 to 40 percent of senior contributor time with minimal delivery impact. LGPs reduce governance overhead to under 10 percent of any individual's time while maintaining decision quality and traceability.

An LGP is not a steering committee or an approval board. It is a decision-making forum with a defined scope, a time budget, and an explicit anti-bureaucracy mandate. Maximum 7 participants. 75 minutes per bi-weekly session. Three decision types only: Unblock (resolve or assign a delivery blocker), Approve (ratify prepared proposals), or Defer (assign an owner, a due date, and specify the exact information missing). Any item not fitting one of these three types does not belong in the LGP.

The pre-read is distributed 24 hours before every session. If an item is not in the pre-read, it is not discussed today. This single rule prevents the LGP from becoming a fire-fighting forum. Any item that appears in three consecutive pre-reads without resolution is automatically escalated to the Alignment layer.

SHIFT runs in 2-week sprints grouped into 12-week cycles (six sprints per cycle). The cycle is the primary strategic alignment unit. The sprint is the primary delivery unit.

Within each sprint: Day 1 is the Spec Review Session. Days 1 through 10 carry the daily AI-First Standup (async-first, 15 minutes). Day 6 or 7 is the Mid-Sprint DOI Check-in. Day 10 is the Sprint Review (which includes the IIS Review when applicable), followed by the AI-Augmented Retrospective.

Within each cycle: Sprints 1 and 2 are standard delivery. Sprint 3 introduces IIS (15% capacity ring-fenced). Sprints 4 and 5 are standard delivery. Sprint 6 combines delivery, IIS, and the Cycle Portfolio Review. At the cycle end, the LGP re-validates objectives, reviews ACN composition, ratifies IIS themes for the next cycle, and runs the Maturity Model self-assessment.

Total ceremony overhead per person per sprint is approximately 6.7 hours, around 8% of available sprint capacity. This compares with Scrum at 12 to 16 hours and SAFe at 20 or more hours per person per sprint at scale.

IIS is SHIFT's mechanism for sustaining exploratory work within a delivery-focused framework. The standard IIS allocation is 15% of sprint capacity per node. This is ring-fenced before sprint planning, not distributed from what is left over. It requires LGP approval to reduce below 10%.

IIS differs from 20% time, hackathons, and innovation sprints in four ways: the time is structurally protected (not informal), outputs follow a defined format (Learning Cards), a promotion funnel connects good ideas to real investment (not just to a parking lot), and themes are selected based on DOI connection to cycle objectives (not personal preference).

An IIS theme must have three elements: a question (what are we trying to learn?), a connection (how does this relate to a Cycle Objective or known limitation?), and a testability statement (how will we know in 1.5 days whether this is worth pursuing?). The output is a Learning Card: what was done, what was learned, what was not learned, a signal (Positive, Neutral, or Negative), and a recommendation (Promote to Pilot, Continue Exploring, Archive, or Share Externally).

Promoted items move through a funnel: Learning Card, Pilot Sprint (one sprint, defined success criteria, standard delivery capacity), LGP Approval, then Cycle Portfolio Investment. A pilot that misses its success criteria is archived, not extended. Extensions require a new LGP approval.

Dynamic Objectives Integration keeps sprint delivery connected to strategic objectives in real time, not retrospectively. Every sprint backlog item is tagged Green (directly serves a Cycle Objective), Amber (indirectly supports one), or Red (no objective connection) during the Spec Review Session.

Red items are challenged at sprint planning: delete, defer, or explicitly reclassify with a documented connection. Items kept as Red (for example, compliance or technical debt work) are acknowledged and tracked. The DOI Health Score is calculated as the percentage of Green contributions out of total Sprint Contributions. A score of 80 or above is strong. Below 40 triggers escalation to the Alignment layer.

The Amber Trap is the most common DOI failure: teams keep items Amber indefinitely to avoid the visibility of Red. SHIFT enforces an automatic conversion: any Amber item that has not moved to Green within four calendar days becomes Red. The Delivery Lead cannot override this rule. Only the Governance Steward can, with documented justification.

When a Red item is declared, the protocol is: declare within four hours (notification to Anchor, Governance Steward, and adjacent node Delivery Leads), initial response within four hours (resolve within node or proceed to resolution meeting), resolution meeting within 24 hours with named action, owner, and deadline. All Red items from a cycle are reviewed at the Cycle Portfolio Review for pattern analysis.

AI-first teams operate with a fundamentally different production function. When AI tools can produce a working implementation from a clear specification in hours, the constraint shifts from coding capacity to specification quality. Vague requirements produce unreliable output regardless of the AI tools involved.

Spec-Driven Development treats the specification as the primary engineering artefact. A complete spec contains: a problem statement, acceptance criteria (each independently testable), edge cases, integration constraints, AI guidance notes (where AI output is expected and what review is required), and a definition of done. This spec is reviewed, challenged, and signed off before any implementation begins.

SDD changes what sprint planning is for. Planning is no longer primarily about task decomposition and effort estimation. It is about spec quality review. A sprint is ready to begin when every item has a spec that any contributor, human or AI, could implement without interpretation. SDD changes retrospectives too: the first question is not 'why did delivery take longer than expected?' but 'where did the spec fail us?'

The SEMI model is SHIFT's estimation and sprint-readiness system. It replaces story points. Each work item receives four scores on a 1 to 3 scale before it can enter a sprint. The composite score (minimum 4, maximum 12) determines sprint entry eligibility, not calendar duration.

S is Specification Quality: how clear, complete, and testable is the specification? Score 1 if an engineer can start without clarifying questions. Score 3 if acceptance criteria are missing or untestable. E is Effort Uncertainty: has the team done this before? Score 1 for known work with precedent. Score 3 for novel work where the approach is unclear. M is Multi-system Impact: how many external systems, teams, or dependencies does this touch? Score 1 for fully contained work. Score 3 for work touching multiple systems with compliance implications. I is Implementation Confidence: how confident is the team in the chosen approach? Score 1 for a proven pattern. Score 3 when a spike may be needed before implementation begins.

Sprint entry rules: SEMI 4 to 6 (Green band) enters the sprint immediately. SEMI 7 to 8 (Amber band) enters only with a documented mitigation for the highest-scoring dimension, agreed by the Delivery Lead and Anchor. SEMI 9 to 10 (Red band) is returned to the Anchor for specification improvement before it can be re-scored. SEMI 11 to 12 (Black band) must be decomposed into child items.

SEMI scores tracked across sprints reveal systemic patterns: consistent S=3 signals specs are written too late. Consistent E=3 on one work type signals the team is not building pattern familiarity. Consistent M=3 signals the node's capability domain is too wide. Consistent I=3 signals a capability gap that an IIS theme should target.

Velocity-based forecasting collapses in AI-first teams. A team's effective output can double between sprints as prompting skills improve or new tooling is adopted. Effort-weighting becomes noise. SHIFT uses throughput: counting the number of work items completed per sprint, regardless of estimated size. An item is complete when it meets all acceptance criteria, has passed its required review step (including human review for AI-assisted outputs), and is deployed or integration-tested.

For release date forecasting, SHIFT uses Monte Carlo simulation. The team's historical throughput distribution is sampled across thousands of simulated completions to produce a probability distribution of outcomes. The output is communicated in probability bands: P70 for sprint goal-setting and internal commitment, P85 for stakeholder commitments, P95 for contractual commitments. 'Based on our last 10 sprints, we have 85% confidence this will be complete by 14 March' is more honest and more useful than a single predicted date.

Monte Carlo requires a minimum of 8 sprints of internal throughput data before it replaces reference class benchmarks. Before that, teams use industry-baseline throughput distributions, blended with actual data from sprint 3 onwards, and clearly flagged to stakeholders as external estimates rather than internal forecasts.

The SHIFT Maturity Model is a navigation tool, not a certification programme. Teams use it to understand where they are, what to focus on next, and what good looks like at each level. It is run at cycle end, facilitated by the Governance Steward, and takes 30 minutes.

Level 1, Established Foundation: ceremonies are running, SEMI scoring is applied before sprint entry, throughput is being tracked, the ACN structure is defined, and every contributor owns the review step for their AI-assisted outputs.

Level 2, Aligned Delivery: the DOI map is live and maintained, at least one Red item has been declared and resolved in the current cycle, IIS is running with Learning Cards as output, the LGP pre-read is distributed 24 hours before every session, and throughput data from the last six or more sprints is available.

Level 3, Adaptive Intelligence: Monte Carlo forecasting from internal data is in use and communicated to stakeholders in probability bands, at least one IIS Learning Card has been promoted through the full funnel to a cycle investment, the pattern library has at least ten entries and is actively consulted, and retrospective actions are completed at a rate above 70%.

Level 4, System Contribution: pattern library content is being shared with other teams, AI agent roles from the node are being used or adapted by other nodes, SEMI calibration is accurate enough to rarely produce surprise scope overruns, and a new team member can contribute meaningfully within five days using documented materials.

SHIFT is adopted in four phases over 12 sprints. Phase 0 (one week before Sprint 1): map existing teams to ACN candidates, assign roles, write the capability domain in one sentence, draft the AI Responsibility Map, and SEMI-score the top 20 backlog items. Sprint 1 planning selects only items scoring 6 or below.

Phase 1 (Sprints 1-3): introduce the AI-first standup and throughput tracking immediately. Add the Spec Review ceremony in Sprint 2. Introduce IIS at 10% capacity and the 3-track retrospective in Sprint 3. Do not yet introduce DOI, LGP, or Monte Carlo. Milestone: Maturity Level 1.

Phase 2 (Sprints 4-6): introduce Cycle Objectives and the DOI map in Sprint 4. Stand up the LGP and run the Red Item Protocol for the first time in Sprint 5. Run the first Cycle Portfolio Review and calculate the first DOI Health Score in Sprint 6. Milestone: Maturity Level 2.

Phase 3 (Sprints 7-9): introduce Monte Carlo forecasting using reference class data and communicate the first P85 forecast to a stakeholder. Retire reference class data at Sprint 8 (8 sprints of internal data available). Evaluate Learning Cards for pilot promotion. By Sprint 9, full SHIFT operation is the target. Milestone: Maturity Level 3.

Ricardo uses SHIFT in transformation engagements where organisations are navigating the move from traditional Agile to hybrid, distributed, or AI-first working. The framework provides enough structure to align stakeholders and enough flexibility to adapt to context.

Engagements typically begin with an ACN design workshop, a Lean Governance Pod setup session, and a two-cycle pilot with a willing team before broader rollout. The downloadable guide provides the full framework documentation, ceremony facilitation notes, SEMI scoring reference tables, and the Monte Carlo forecasting model Ricardo uses with clients.