The Agile Sprint That Never Ends

In 2001, seventeen software developers met at a ski resort in Utah and wrote a document that was supposed to change how software gets built. The Agile Manifesto. Four values. Twelve principles. The central idea was simple and genuinely radical: working software delivered frequently, in close collaboration with customers, by teams trusted to figure out how to do the work.

Twenty-five years later, the average software engineer is in more meetings than ever, has less autonomy than the manifesto envisioned, and is measured by a velocity number that has almost no relationship to the value they are producing. Agile has become the thing it was designed to replace: a rigid process that serves the organisation’s need to feel in control rather than the team’s need to do good work.

This is not what the people in that Utah ski resort had in mind.

What agile was actually trying to solve

The problem agile was designed to address was a specific failure mode of large software projects in the 1980s and 1990s. A team would spend six months writing a requirements document. Another three months on a design document. Another year building what the documents described. And then, at the end of all of that, they would hand the software to the customer and discover that what the customer actually needed was different from what the documents specified, which was different from what the customer had originally asked for, because the customer’s understanding of what they needed had evolved over the two years it took to build it.

The solution was to shorten the loop between building and feedback. Instead of delivering once after two years, deliver something real every few weeks and let the customer tell you whether you are going in the right direction. The feedback is what makes the process work. Without real feedback, you are back to waterfall with shorter documentation cycles.

This is the thing that most agile implementations miss entirely. The sprint is not the point. The feedback is the point. The sprint is just the container that forces a regular conversation between the people building the software and the people who need it.

When the feedback loop is genuine, short iterations are powerful. When the feedback loop is theatre, short iterations just mean you are going in the wrong direction faster.

How it became theatre

Sprints became theatre through a sequence of institutional pressures that each made sense in isolation and combined into something harmful.

Managers need to report progress. Progress in software is genuinely hard to measure. Story points became the proxy. The team assigns points to tasks based on relative complexity and the number of points completed per sprint becomes velocity. Velocity becomes the number that gets reported. The number that gets reported becomes the number that people are implicitly evaluated on.

Once velocity is the number being watched, the incentives shift. The team is no longer optimising for working software delivered to users. They are optimising for points completed per sprint. These are not the same thing, and the ways they differ are instructive.

Points are easier to accumulate on small well-defined tasks than on large ambiguous ones. So teams break work into small well-defined tasks, even when the work does not naturally decompose that way, and even when the decomposition creates overhead that slows down the actual delivery of value.

Points are easier to accumulate when scope is estimated conservatively. So teams learn to estimate conservatively, which gives the appearance of high velocity while padding every estimate with buffer that absorbs real complexity. The padding is not dishonest. It is rational given the incentives.

Points are zero for work that is not in the sprint. So operational work, learning, helping colleagues, investigating production issues, and the dozen other things that engineers do that are genuinely valuable but hard to put on a card become invisible. They happen between the official work, in the margins of a process that does not account for them.

The sprint review happens every two weeks. The team shows what they built. Stakeholders nod. Feedback is surface-level because the demo is polished and the real questions require context that a thirty-minute meeting does not provide. The meeting ends. The cycle continues.

The feedback that was supposed to make this whole approach work is not happening. It has been replaced by a performance of feedback.

The estimation ceremony

Sprint planning is where agile theatre is most visible.

A well-functioning sprint planning session is a conversation about what the team is going to build and what they understand about the work. Complexity surfaces. Dependencies get identified. Ambiguity gets resolved. The team arrives at a shared understanding of the work before starting it. This is genuinely valuable.

What happens in most organisations is different. The team is handed a prioritised list of tickets by a product manager. The team estimates each ticket in story points using planning poker or a similar ritual. The estimates are aggregated against the team’s velocity to see if the sprint is overloaded. Items are added or removed until the numbers look right. The meeting ends.

What the meeting has not done: resolved the ambiguities in the tickets, identified the dependencies that will block work mid-sprint, questioned whether the prioritisation reflects actual user value, or given the team any real input into what they are being asked to build or why.

The ceremony happened. The planning did not.

The sprint begins. Midway through the sprint, a ticket turns out to be three times more complex than estimated because the ambiguity that was not resolved in planning revealed itself in implementation. The sprint ends with some items incomplete. Velocity dips. Someone asks why. The answer, that the estimation was based on insufficient understanding, is the answer that the process should have prevented but did not.

The process is working as designed. The design is broken.

The meeting that replaced thinking

There is a running joke in software teams that the worst outcome of a meeting is scheduling another meeting. Agile processes have made this joke structurally true.

Sprint planning. Daily standup. Sprint review. Sprint retrospective. Backlog grooming. Story time. Architecture reviews. Team syncs. One-on-ones. These meetings are not all useless. Some of them are genuinely necessary. Together they can easily consume thirty to forty percent of an engineer’s working week.

The problem is not any individual meeting. The problem is that the time spent in meetings is time not spent thinking, which is the primary activity through which engineering value is produced. Software is a thinking discipline. The code is the output of the thinking, but the thinking is the work. A team that is interrupted constantly, that moves between contexts continuously, that has its attention fragmented by a process that requires frequent synchronisation, is a team that does shallow thinking most of the time.

Shallow thinking produces code that solves the immediate problem without considering the adjacent problems. It produces designs that are good for the simple case and brittle for the complex case. It produces estimates that are based on optimistic assumptions because the estimator did not have time to think through the pessimistic ones.

Deep thinking requires time. Not a lot of time necessarily, but uninterrupted time. The kind of time that becomes scarce when a calendar is full of recurring ceremonies that cannot be moved because they are the process.

The best work most engineers have done happened during stretches of time when they could think through a problem fully, follow a line of reasoning to its conclusion, encounter an obstacle and work through it rather than deferring it, and arrive at a solution that they understood completely before they wrote a line of code. This kind of work requires hours of uninterrupted attention. It is incompatible with a schedule that fragments the day into thirty-minute blocks between meetings.

What the retrospective is not fixing

The sprint retrospective is the mechanism by which the agile process is supposed to improve itself. Every two weeks the team reflects on what went well, what went poorly, and what they will do differently. Action items are generated. The next sprint begins.

In practice, retrospectives in most teams are producing the same action items repeatedly. Communication could be better. Tickets need more detail before they enter the sprint. Estimates are too optimistic. Dependencies should be identified earlier. These items appear, get acknowledged, and do not change because the conditions that produce them are structural rather than behavioral.

Communication is not insufficient because the team is bad at communicating. It is insufficient because the process creates conditions where people do not have enough context about each other’s work to communicate usefully. Tickets lack detail not because product managers are negligent but because the sprint schedule does not allocate enough time for the discovery work that would produce that detail. Estimates are optimistic not because engineers are unrealistic but because the estimation process does not allow for the kind of investigation that would reveal the complexity.

The retrospective is designed to surface behavioral problems in a process that is fundamentally sound. Most teams have structural problems in a process that has been implemented in a way that undermines its own goals. The retrospective cannot fix structural problems through behavioral action items.

What works instead

The teams that have figured out how to build software well, actually well rather than agile-process-compliant-well, tend to have some things in common.

They have a short feedback loop with real users, not with internal stakeholders performing user representation. Something gets built. Real users encounter it. The team finds out what happened. This is what the sprint was supposed to enable, and it is worth having whatever the ceremony around it looks like.

They have protected time for thinking. Not as a perk or a policy that gets overridden when things are busy. As a structural commitment that is treated with the same seriousness as customer commitments. The engineers who are doing the hardest thinking are the most expensive people in the organisation to interrupt and the ones who are interrupted most frequently by process overhead.

They have genuine autonomy over how the work gets done. Not over what gets built, necessarily. The business has legitimate input into priorities. But over the sequence of the work, the technical approach, the pace at which things move. Engineers who are told not just what to build but how to build it and at what speed are engineers whose expertise is not being used.

They measure outcomes rather than output. Working software that users value rather than story points completed. Features that are used rather than features that are shipped. Systems that stay up rather than systems that were delivered on time. Outcomes are harder to measure than output. They are what the work is actually for.

None of this requires abandoning iteration or collaboration or responsiveness to user feedback. Those ideas from Utah in 2001 were right. The encrustation of ceremony and measurement and process overhead that has accumulated around them is what went wrong.

The manifesto said individuals and interactions over processes and tools. Most agile implementations have given teams processes and tools while managing the individuals and interactions out of existence.

That inversion is where the sprint that never ends was born. The sprint is not what needs to end. It is the inversion.