Why We Ditched Sprints

Controversial opinion time. In startup land, we’ve found that two-week sprints often damage both code quality and the team’s psychology. Even if you try to make it clear that it’s an observation of velocity, people change their behaviour counterproductively.

The artificial deadline of a sprint can encourage developers to cut corners simply to “get the story in” before the time is up, or to meet the stretch goals. The focus shifts from solving the problem in front of you to hitting an arbitrary target. It creates an illusion of control for managers but anxiety for engineers.

It incentivises people to focus on low hanging fruit and new features rather than ambitious problems - a lesson I became aware of thanks to David Cox.

It struggles to accept new, ad-hoc work or pivots that inevitably come the way of a small startup dev team.

For a small, experienced team, it’s unnecessary overhead. We prefer to operate in a continuous flow. We have a clear vision, tickets (long term memory), and high-trust, high-bandwidth communication (short term memory). It’s a model built on trusting professionals to be professional.