We take the Agile Manifesto at face value, which is exactly why we stopped running sprints. What we do instead, and why it works for startups.
We don't run sprints. People are sometimes surprised by that, because we describe ourselves as agile. We are. We just mean it in the original sense.
The Agile Manifesto is four lines long. It values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. There's nothing in it about two-week cycles, story points, velocity charts or a ceremony every other Tuesday.
Those things came later, mostly to help large organisations manage risk at scale. That's a perfectly good thing to want. It just isn't the problem a startup has.
The problem a startup has
A startup doesn't have scale. It has urgency.
When three engineers and a founder are trying to get to their first customer before the money runs out, the biggest risk isn't a lack of process. It's stalling. Every hour spent grooming a backlog, estimating tickets or demoing to a stakeholder who could have watched it happen is an hour not spent finding out whether anyone will pay for the thing.
So our rule is simple. Your tolerance for process should grow with the maturity of the business. On day one, it should be almost zero.
What we do instead
We treat reality as the source of truth. Most teams treat the backlog as the authoritative record of where things stand, then spend their energy forcing reality to match it. We do the opposite. What's actually happening on the ground is the truth, and the backlog follows it. When the ground shifts, as it does several times a week in a startup, the tickets move. Nobody pretends the plan is still the plan.
We narrate our work. Every engagement has a shared log channel where our engineers post a running commentary: what they're doing, what they've just learned, what they're stuck on, and the demo from ten minutes ago. It's noisy on purpose. The founder can mute it, but whenever they want to know where things stand, it's all there.
We plan in checkpoints, not sprints. A checkpoint is a moment where the product can do something new and meaningful, something the founder can put in front of a customer or an investor. We agree them together and work towards them relentlessly. Some take a few days and some take a few weeks. The calendar doesn't decide when we're done. The product does.
We bias towards action. Waiting on a code review? Message the reviewer. Still nothing? Post it in the channel, say you'll merge in ten minutes unless someone objects, then do it. Before there are customers on the platform, the risk of that is tiny. The risk of losing momentum isn't.
"Trusting professionals to be professional"
None of this works with people who need to be managed. It works because we hire experienced engineers who understand the business they're building for, and then we get out of their way.
That's the real trade. Ceremony is a substitute for trust. If you can't trust your team to say when something's wrong, you build a process to drag it out of them every fortnight. If you can, you don't need the process, and you get the time back.
It also changes the founder's experience. Instead of a demo every two weeks and silence in between, they can watch the product take shape day by day and steer it while it's still cheap to steer.
When we do use the tools
We're not against standups, boards or tickets. They're tools, and we use them when they earn their place. A bigger team, a regulated product or a client with an established process all shift the dial, and we shift with them. What we won't do is run a ritual because a book said so.
Read the four lines again. That's the bit we hold on to.
If you want the longer argument for why this matters even more now AI is writing most of the code, read Reality Is the Source of Truth.