Kill the Sprint

The operating model is breaking

For seventeen years I have built and shipped software. First writing the code, later leading the teams and platforms that wrote it, with engineers spread across continents and time zones. In all that time, the way we organised the work barely changed. Plan in two-week sprints. Estimate in story points. Stand up every morning. Move cards across a board. Demo, retro, repeat.

That model made sense for one reason: writing code was slow and expensive. It was the bottleneck, and everything else was organised around it. Around the code sat a second tax every delivery leader knows by heart: dependencies. Waiting on another team's API. Waiting on a decision from product. Waiting on a review from someone eight time zones away. Half the art of shipping was untangling who was blocked on whom, inside a team and across teams.

AI has removed the first bottleneck almost overnight. An agent can write in an hour what took a developer days. But the second tax is still there, and now it is the whole bill. The code is ready. The organisation isn't.

This is not one role's problem, but everybody's. It's the product manager whose PRD goes stale the day after sign-off. The engineer whose agent builds the wrong thing, perfectly, because nobody updated the spec. The QA lead testing last month's requirements. The architect who learns about a design change from a pull request. The engineering leader still assembling status on a Thursday night. Every one of them is running a playbook written for a constraint that no longer exists.

Every big shift in how we build software has brought a new way of working: waterfall, then Agile, then DevOps. AI is the biggest shift of them all, and the pieces of its operating model are already appearing: spec-driven development, multi-agent orchestration, AWS's AI-DLC. Most of them make the engineering loop faster. None of them yet changes how the whole team works together, from product to engineering, QA and leadership. So most companies end up bolting agents onto sprints and calling it transformation.

So our thesis is simple: kill the sprint. Don't shorten it, don't tune it. Replace the operating model with one built for humans and agents working together. The industry has started calling this the AI-Driven Development Lifecycle, or AIDLC. Signals AIDLC is how we put it to work for the whole team, and the rest of this piece walks through the four shifts behind it.

Agile was a rationing system

I want to be fair to Agile, because it earned its place. In 2001, a group of practitioners wrote a one-page manifesto because waterfall projects were collapsing under their own documents. Requirements froze in month one and were wrong by month six. Agile's answer was to build a small piece, show it, learn, and repeat.

Underneath, it was an economic answer. Engineering hours were the scarcest thing a company had. So we sliced work small, boxed it into two weeks, estimated every story, and protected the team from change mid-sprint. Kanban, borrowed from Toyota's factory floor, carried the same logic: limit work in progress, because people can only hold so much at once. These were rationing systems for expensive human effort.

Over twenty years, the practices quietly became the point. We measured teams by velocity and burn-down charts. We judged health by how green the board looked. Planning meetings ran longer than the work they planned. The question slowly shifted from "did we ship something that mattered?" to "did we follow the process?" I was part of that. I ran those ceremonies and defended them in leadership reviews.

Now the thing being rationed is no longer scarce. When code becomes cheap, a system designed to ration code stops making sense. The constraint has moved somewhere else entirely.

Shift 1: Iteration stops being the unit of work

The sprint is the heartbeat of Agile. Build, show, learn, repeat, every two weeks.

That heartbeat only makes sense when each loop is expensive. When an agent can produce a working version of a feature in an afternoon, a two-week cycle isn't a feedback loop any more. It's a waiting room. The work was ready on Tuesday. It sits until the demo on Friday next week, because that's when the ceremony is.

I see this on my own team. An engineer pairs with an agent and has something real running in a few hours. Then it waits: for review, for the next planning session, for someone to update the ticket so the board looks right. The build took hours. The process around it took weeks.

Iteration doesn't disappear in AIDLC. It becomes so cheap and so fast that it stops being something you plan. You don't plan iterations; you plan decisions, and the iterations happen inside them, sometimes dozens in a day. AWS made a similar call in its own AI-DLC work, replacing the sprint with short "bolts" measured in hours or days.

In a sprint, the calendar decides when work ships. In AIDLC, the decision does.

Shift 2: From sequential to parallel

For most of my career, an engineer's day was a queue. Pick up a ticket, finish it, pick up the next one. Much of my job as a leader was ordering that queue well and protecting it from interruptions. Kanban made the rule explicit: finish before you start. It was right, because a person can only do one piece of deep work at a time.

Agents broke that limit. One engineer today can have four or five streams running at once: an agent writing a data migration, another generating tests, a third drafting the API change, a fourth chasing a production bug. The engineer isn't typing in any of those streams. They are deciding. Which approach. Which trade-off. Is this good enough to ship.

That is the new division of labour: humans make the decisions, agents do the execution. The limit on a team is no longer how much its people can build. It is how many good decisions they can make, and how fast the right decision reaches the right person.

The engineer's job moves from doing each task to deciding across many.

This is where most companies adopting AI are going wrong. They hand everyone a coding assistant and keep the sprint board exactly as it was. Agents produce in parallel; the process consumes in sequence. Code gets written faster, then queues for the same reviews, the same handoffs and the same release train. The delivery date doesn't move. I have watched teams spend serious money on AI tools and ship on the same calendar as the year before.

Speeding up one step doesn't speed up a pipeline that still runs in single file.

Shift 3: From context in silos to one unified context

Every team I have led had at least three sources of truth, and they never agreed.

Product lived in the PRD. Engineering lived in the design doc and the code. QA lived in the test cases. Each was written at a different time by a different person, and kept up to date on a different schedule, which usually meant never. I have sat in bug triages where the developer, the tester and the product manager were each right according to their own document. The requirement had changed weeks earlier, and only one document knew.

With teams spread across time zones, it got worse. A decision made on an evening call reached the other side of the world the next morning as a one-line chat message, with all the reasoning stripped out. For years, a big part of my job was being the human sync layer between those documents and those time zones. I was the integration bus. A slow and expensive one.

People can survive this, barely, because people fill gaps. A good engineer reads between the lines of a stale spec and walks over to ask.

Agents can't. An agent works from exactly the context it is given. Point it at an outdated PRD and it will build the outdated thing, quickly and confidently. Silos used to cost you a few days. With agents in the loop, they cost you whole features built in the wrong direction. Spec-driven development doesn't solve this on its own. A spec is only as good as the day it was last updated, and in most teams that day is already behind them.

AIDLC needs one unified context: intent, decisions, specifications, code, tests and the reasoning behind each, connected, live and updated with every iteration. Not a wiki someone promises to maintain, but the single place that product, engineering, QA and every agent read from and write to. When the intent changes, everything downstream knows.

Everyone, human or agent, reads from and writes to the same truth.

Shift 4: Stop chasing, start reading

Every delivery leader knows the weekly status chase. Leadership asks for an update. You message five leads, and three reply. One says "on track" about something you're fairly sure isn't. The fifth is on leave. You chase, consolidate and write it up, and by Monday it's already out of date.

I lived that week, again and again, for years. And even with all the chasing, the delays still happened and the updates were still incomplete. The daily standup was supposed to fix this. It turned status into a fifteen-minute recital of what the board should already say. The problem was never discipline. Status reporting exists because the work doesn't report itself. A tracker only knows what someone last typed into it.

In AIDLC, every decision, commit, test result and approval flows through the unified context, so the state of the project is something you read, not something you ask for. Progress, risks and blockers update as the work moves.

There is a second effect that matters even more over time. The context remembers. Every artifact and every decision, the why as well as the what, stays in one source of truth and updates itself with every iteration. When the next feature starts, a new teammate joins, or an agent picks up a change six months later, it starts from everything the team already knows instead of from a blank page and a stale wiki.

That removes the standup and the status meeting, and a large share of what we used to call project management. Leaders don't disappear. They stop being human message queues and go back to the work only they can do: making the calls, unblocking people, and deciding what matters.

Status becomes a by-product of the work, and the context becomes the team's long-term memory.

Signals AIDLC: multiplayer AI for software delivery

AIDLC is not "Agile plus a coding assistant." It is a different operating model built on one idea: humans own intent and decisions, agents own execution, and the system owns the truth.

I'm not alone in seeing this. AWS has open-sourced its own AI-DLC workflows, with agents carrying context across stages and humans approving at explicit gates. Microsoft's Agentic-Agile Manifesto puts it well: specifications and context are the new source code. But Microsoft calls its framework an evolution of Agile, "not a replacement." That's where I part ways. Adding agents to sprints is a better horse. We need a different vehicle.

Signals AIDLC is built for the space between people, not just for the person at the keyboard.

It works like a shared room. Product managers, engineers, architects, designers, QA and stakeholders gather around the same intent. AI agents sit in the room with them. They ask the questions that usually come up too late, surface ambiguity early, and help the team reach explicit decisions. The conversation itself becomes part of the project's working context.

From there, the lifecycle runs as one connected flow. An idea is captured. The team clarifies and aligns. The discussion turns into durable PRDs, technical specs and implementation plans. Approved context moves into focused execution windows, where developers and coding agents work in parallel. Pull requests and test results flow back into the shared room for review. And everything learned is kept, so the next change builds on every decision before it.

Because it all runs through one unified context, the things that used to need a project manager now happen on their own: status is live, risks surface early, and every line of code traces back to the decision and the intent behind it.

Signals AIDLC isn't another AI tool added to the old process. It is a new way for teams to get software built. For us, the lifecycle is the product.

Every stage reads from and writes back to the same context, so nothing is lost between steps or between features.

The proof is in our own release cycle

Here is what we have seen so far.

We build Signals using Signals AIDLC. A release that took us two to three weeks under a sprint model now ships in a day, two at most. Same kind of work, same team. Nobody types faster. What changed is that nothing waits: decisions reach the right person when they are needed, agents execute in parallel, and nobody loses a day assembling a status update.

That is roughly a tenfold compression in cycle time, and none of it came from heroics. It came from removing the rituals that sat between the work and the release.

We are now running Signals AIDLC with design partners, teams living with the same pain I lived with for seventeen years. Their results will make or break this thesis, and I will share them openly as they come in.

The next operating model

Here is my prediction. Within two years, the two-week sprint will sound the way the eighteen-month waterfall plan sounds today: a story you tell to explain how things used to be done.

Almost every company that builds software runs on some version of the old playbook today, and every one of them will have to change. Agile created an industry of tools, certifications and consultants around one operating model. DevOps did it again. The operating model for AI-native delivery is still unwritten, and whoever defines it will shape how the next decade of software gets built.

The winners won't be the companies with the most AI licences. They will be the ones that rebuild how they work around them: decisions instead of timeboxes, parallel execution instead of queues, one unified context instead of three conflicting documents, and live state instead of chased updates.

Between us, the Signals team has spent decades building and shipping software the old way. We have lived that era, with its sprints, handoffs and status chases, and we can see clearly what is changing now. We're building Signals with everything that experience has taught us, for the next generation of software teams.

If you lead product or engineering and this resonates, or if it makes you angry, we want to hear from you. Both are useful.

See it in action:orgsignals.com/ai-dlc