Skip to main content
Reference — generated from the toolkit

Source of truth: toolkit/templates/operating-model-retro.md. Edit it there; this page is regenerated on build.

Operating-model retrospective — {pilot: StudyBuddy}

  • Pilot: {StudyBuddy} Date: {YYYY-MM-DD} Facilitator: {Agile Coach}
  • Attendees: {squad + shared specialists + SMEs}

Rules

  • Every finding is dispositioned keep or change — no "we should probably".
  • Every change gets a record: an ADR (template, per the decision-records standard) where it alters the operating model for future squads, or a named owner and date where it is a one-off action.
  • Findings are evidence-backed — friction-log entries, metrics, or a named example. Vibes are discussed, then either substantiated or dropped.

Squad shape

Did the minimum squad hold when agents did the typing? Which roles were over- or under-loaded? Was the Senior Dev's review capacity the constraint? Did the tester split (manual + auto) match the work?

FindingKeep / ChangeRecord (ADR / owner + date)

Ceremonies

Which ceremonies earned their keep at RAPID pace, per the delivery cadence? What was theatre? What coordination happened outside ceremonies that should be named and kept?

FindingKeep / ChangeRecord

UK–India handoffs

Did the overlap windows in the UK–India playbook work in practice? Were handoff artefacts sufficient for the receiving side to direct agents without re-deriving context (async comms)? Where did work queue overnight that shouldn't have?

FindingKeep / ChangeRecord

Specialist engagement

Did pooling (shared specialists) work — response times, availability at gates, capability actually transferred into the squad rather than dependency created? Which specialisms did the pilot need more or less of than planned?

FindingKeep / ChangeRecord

SME cadence

Was insurance-SME availability matched to iteration pace (SME engagement)? Did validation turnaround ever block the loop? Was the domain brief good enough that SMEs corrected details rather than re-explaining fundamentals?

FindingKeep / ChangeRecord

The before/after story

The narrative for internal advocacy — the version every squad hears before their own transition. Built from the pilot charter's measured results, not adjectives:

  • The numbers: lead time, deployment frequency, change-failure rate, MTTR — legacy vs RAPID, from the metrics platform.
  • One concrete tale: a representative change under the legacy process vs an equivalent change through the RAPID loop — dates, hours, hand-offs counted.
  • In the squad's words: two or three direct quotes — including the honest ones about what was hard.
  • What we'd tell a sceptical squad: the pitch, and the caveats we stand behind.

Shared through the Community of Practice and leadership comms.

Outputs

  • This document, with every finding dispositioned, goes to the CXsmart scale-up gate.
  • Operating-model changes land as PRs to the handbook and toolkit — the retro is only done when the changes are merged or ADR'd, not when the meeting ends.