The Sprint, Compressed

A follow-up to "The Team, Recalculated."

Last time we wrote about the team getting smaller. This one is about the clock.

When code stopped being the slow part, the sprint stopped needing two weeks. Work that used to fill a fortnight now often fits into a day or two. Before anyone reads that as “we threw out how software gets planned,” we didn’t. Scrum still makes sense. It just runs a lot faster.

‍

‍

The framework stays. The cadence changes.

There’s a temptation to read “AI made us faster” as “we don’t need process anymore.” That’s wrong, and it’s the kind of wrong that produces a mess three months in.

A client still needs to see where things stand. Someone still has to decide what gets built next and in what order. There still has to be a point where work is reviewed and either accepted or sent back. That’s what an agile framework gives you, and it matters more when the pace picks up, not less. Speed without structure is just churn.

So we keep the scrum skeleton: a defined scope for the cycle, a review at the end, and a client who can see progress the whole way through. What we change is the length of the cycle.

Two weeks becomes one to three days.

‍

Why the cycle collapses.

Two things pull the sprint down to a couple of days.

The first is the Context Engine. Before a Pod writes a line of code, the client’s processes, documents, and decisions are already loaded into their enclave, sitting on top of the industry knowledge we bring. The team doesn’t spend the first three days of a sprint reverse-engineering how the business runs. They start with it loaded.

The second is where the engineers spend their time. In an AI-native Pod, most of the effort goes to architecture, integration, and judgment, not to typing code by hand. The distance between “we agreed what to build” and “it’s running in production” is mostly judgment now, and judgment is fast when the context is already there.

How short the cycle goes depends on the client. A business with clean, documented processes and clear decision-makers can run one-day cycles. A business still working out what it actually wants runs two to three days, because part of each cycle is spent deciding, not just building. We match the cadence to how ready the client is, and readiness improves as we work together.

‍

Short cycles are a risk strategy.

Speed is the obvious benefit. The less obvious one is risk. A short cycle is a safer cycle, and that’s the part most people miss.

Here’s the plain version. A big release bundles a lot of changes together. When something breaks after go-live, you’re left digging through everything that shipped to find the cause. A small release changes one thing. If it breaks, you know what broke, and you can pull it back in minutes.

The technical version is about batch size and blast radius. A large increment has a large surface area: more code changed, more that can interact badly, and more to test and reason about at once. Shrink the increment and you shrink the diff, the number of things that can regress, and the cost of rolling back. This is what the continuous delivery research behind DORA and Accelerate has shown for years. Teams that deploy in small pieces, often, run lower change-failure rates and recover faster than the ones shipping big releases on a slow schedule. Small and frequent beats large and rare.

So keeping cycles short does two jobs at once. You get outcomes sooner, and every deployment carries less risk than the last big-bang release would have. The discipline is in resisting the urge to let scope pile up. The moment a cycle starts bundling “just one more thing,” the batch grows and the risk climbs with it.

‍

What this looks like for a Swiss SME.

Say a fiduciary firm wants to rework how it onboards new clients. The old way was a project: weeks of spec, a build, one large go-live, and a demo at the end where everyone finds out whether it fits. By then, the requirement had often moved on. What made sense at kickoff no longer matched how the firm worked two months later, so the first real job after go-live was reworking what had just shipped.

The Vantikai way is a working slice on Tuesday. The firm uses it, reacts, and another slice lands Thursday. Each piece is production-ready, not a mockup. If something isn’t right, it’s caught after two days of scope, not six weeks. The firm steers the whole way through instead of waiting for a reveal.

The team got smaller. Now the cycle gets shorter. Both close the same gap: the distance between deciding what to build and having it running in the business.