Platform Recovery Sprint

Duration and scope

Duration

4 weeks with a fixed start and end date. Inside them sit 12 days of our time, spread across three days a week. The rest of the time belongs to your team: they decide, review and merge. Without that time the sprint does not work.

Scope

The sprint is anchored to exactly one reference service from your production estate, named before day one. Everything we build is built against it and can be carried to further services afterwards. Three results are always included — baselines, ownership, one golden path. On top of those you pick 2 more focus tracks from the three available at scoping. The third is deliberately left out: four weeks do not carry it at a depth worth paying for.

When the sprint is the right step

• A release took production down and nobody can reconstruct which change did it.
• Deployments have become an event: they need a slot, an approval, and someone willing to press the button.
• The pipeline is slow and unreliable, and people re-run it until it goes green.
• The person who held the platform in their head has left. What they owned is written down nowhere.
• An assessment or an internal review named the problems long ago — a quarter later, none of it has been implemented.
• Kubernetes is running but operations are not: no runbooks, alerts nobody trusts, and a lot still done by hand.
• New joiners take weeks to get their first change into production, because there is no paved road.

When it is not

• You do not yet know what is actually wrong. An analysis is the more honest first step — the sprint implements, it does not investigate.
• You are in an active outage. A sprint with a fixed start date does not help you today; call anyway and we will tell you who you need.
• You do not have a platform yet and want one built. That is a build engagement on a different timescale, not a sprint.
• You are looking for someone to run operations permanently. We hand over at the end — that is the whole point.
• Nobody on your team can work alongside us during those four weeks. Then the result stays with us instead of with you, and the sprint has missed its purpose.

The six outcome tracks

The four weeks

1. Week 1

   Measure and fix the scope: access, baseline measurement from your systems, ownership written down, reference service confirmed, sprint backlog frozen. From the end of this week the scope does not grow.

2. Week 2

   The first selected focus: we work on the path a change takes to production today — in pull requests, with your team, not in a side project.

3. Week 3

   The golden path: by the end of the week the reference service runs entirely through the new path — at minimum into the last environment before production.

4. Week 4

   The second selected focus, runbooks, the repeat baseline measurement and the handover. On the final day someone from your team deploys while we are not in the room.

What you have at the end

• measurement

  A measured delivery baseline — taken from your systems, repeated at the end with the same method, both figures in the handover document.

• merged change

  Merged changes to your pipeline and deployment configuration, in your repositories, through pull requests your team reviewed.

• running system

  The reference service runs through the new path — in production, or in the last environment before it, depending on what you can release within four weeks.

• merged change

  A reusable golden-path template: project scaffold, pipeline and deployment manifests a second service can adopt to take the same route.

• document

  An ownership map: every platform component with a named person and an escalation path, confirmed by exactly those people.

• document

  Runbooks for the incidents that actually hit you — written during the sprint and rehearsed at least once during it.

• merged change

  The recurring manual steps in the selected focus are automated or abolished, not merely documented.

• document

  A handover session with your team and a written remaining backlog: what we did not do, why, and in what order it would make sense to.

How this differs from an analysis

The analysis is not published as a separate offer yet. The left column describes what an analysis delivers, so you can tell whether you need that or the sprint.

When the sprint is finished

• Someone from your team has deployed the reference service through the new path, at least once, without us in the room.
• The baseline has been measured again with the same method as in week 1, and both figures are in the handover document — whatever they show.
• Every component in the ownership map has a person who has confirmed the assignment.
• Every runbook written during the sprint has been executed once by someone from your team.
• The remaining backlog is written down, prioritized, and has a named owner per entry.
• Our access can be revoked on the final day without anything we built ceasing to work.

What we need from you

• One counterpart with decision authority, reachable throughout the four weeks.
• Access in week one: repositories, CI, cluster or runtime, observability. Granted later, the sprint gets shorter — it does not get extended.
• The reference service, named before day one.
• Roughly one day a week per involved team member, for reviews, decisions and working alongside us.
• Permission to deliver to the main branch through pull requests, and a non-production environment we are allowed to work in.

Price

A fixed price for a fixed scope, not a day rate: a sprint billed by time spent no longer has a fixed scope. We do not publish a price list — the price comes with the proposal, together with the scope, before you commit to anything.

What comes next

Afterwards there are three honest options: you carry on alone — the normal case, and the purpose of the handover; you extend the golden path to further services and we accompany the first few; or you bring in interim technical leadership. None of these is part of the sprint, and none of them is a precondition for it working.

Plainly: there are no before-and-after figures from earlier sprints on this page. The offer is newly scoped, and numbers from earlier engagements were never captured in a way that would prove anything here. What we have built and cleaned up is in the references — without metrics, because we did not measure them.