I Wrote Two Books on Agile. Then I Ran 344 Sprints Alone With AI Agents.

On Monday I gave a talk at AgileDC in Washington. The program called it "I Wrote Two Books on Agile. Then I Ran 112 Sprints Alone With AI Agents." The 112 was the count at launch in March. By release 3.17.2 on October 16 it was 344: 297 numbered sprints through early June, then 47 larger theme sprints tracked in Jira.

This is the talk, written down for the people who were not in the room.

The claim it tested is one I have made for most of my career. The governance model does not care about team size. It cares whether you have the discipline to follow it. I built JobIntel alone, with two teams of AI agents doing the work, to find out whether that holds at a team size of one. Mostly it did. Where it broke is the useful part.

The triangle moved

Every project manager learns the iron triangle. Scope, time, cost: pick two. Plan-driven delivery fixes scope and lets time and cost run. Agile fixes time and cost and lets scope flex, because capacity is the scarce thing.

With agents, capacity stopped being scarce. I have shipped 14 production releases since July 20. Everything in my books this year, the AI, the tools, the cloud, two Mac Studios and the travel, comes to $97,917, from a quick export of my own finance software rather than an audit. Neither number is where the pressure sits.

The pressure moved to quality. More agent hours buy more code. They do not buy confidence that the code does what I think it does. So the triangle did not break. It moved. With agents, you fix quality and let the rest flex.

What happened to the ceremonies

I went through the practices one at a time and gave each a verdict.

Standup: gone. It is a coordination artifact, and there was nobody to coordinate with.

Estimation: gone. Estimation exists to allocate scarce capacity. When another agent run needs no hiring and no capacity plan, the estimate answers a question nobody is asking. Sequencing by risk replaced it.

The sprint boundary: kept, repurposed. It is no longer a commitment window. It is a verification checkpoint. There were 112 of them in the 24 days to launch because the checkpoint got cheap, not because the work got small.

The retrospective: kept, and made mandatory. It is the one practice that got more valuable. There is no second person to notice a pattern for you, so every lesson goes into a running log.

Code review: the crisis. No second pair of eyes.

The Definition of Done: load-bearing. The only structure left holding weight, which is also why it is what failed hardest.

The line I most wanted people to leave with: half of agile is about getting humans to agree, and that half vanished. The other half is about not lying to yourself, and it got harder.

What replaced the second pair of eyes

Three things, each built because there was nobody to do code review.

Adversarial agents, from day ten. Three read-only agents whose only job is to find what is wrong: one for security, one for regulatory exposure, one for data integrity. They ran on every pull request until May, when the cost stopped making sense at that frequency. Now they run every night, at about $13.54 a pass.

Production waits for me. Agents write the infrastructure code, plan it against the live environment, and apply it to test and preview. Production changes only with my approval, against a ticket.

Testing as a layered contract. Agents develop everything test-first. At release 3.17.2 the codebase carries 20,118 automated tests, up from 4,869 at launch, 1.68 lines of test for every line of product code. What each layer is for is in 20,118 Tests and 3 Red Team Agents: Why AI-Built Software Doesn't Have to Be Fragile.

None of that caught what came next.

The Definition of Done that lied for 58 days

Six pull requests. Pushed. Tests green. Tickets moved to Done, each citing a real commit. Every signal a delivery dashboard reads said finished.

The pull requests were not merged. They sat open for 24 to 67 days, with a median of 58, while nine production releases went out without them. Two of the six held the browser tests for the résumé flow, including the only test that uploaded a résumé the way a user does and checked what appeared on screen. Those tests were in no repository's main branch for the whole window.

The mechanism is the part that applies to every team. Done had quietly come to mean "I did the work," when it needed to mean "the work is in main." A commit in a ticket looks like proof. It proves the work exists somewhere. Not that it shipped.

Why nobody caught it is the other half. On a team, a second developer is blocked on your branch, or a reviewer wonders where it went, or someone is watching the merge queue. Alone, none of that exists. AI did not cause this. AI removed the friction that would have surfaced it.

The fix was to make Done something a machine can check:

• Merged-to-main verification before any ticket can reach Done. The ticket cites the merge commit on main, never a branch.
• A nightly drift check against live Jira and live git, which flags any Done ticket whose work is not in main.
• A stale pull request gate. A pull request open past three days raises itself.

Then the guards caught themselves. One night the stale pull request check crashed before it looked at anything, and still filed a ticket saying pull requests were stale. The drift check had its blocking policy backwards: it blocked on problems already fixed and waved through one class of problem that was still live. An automated conscience needs a conscience too.

What carries over to a real team

The coordination half comes back the moment there are two people. Standups and estimates have a job again. The quality half is what transfers. The last slide before questions had seven lessons on it:

1. Split your practices into coordination and quality. AI makes the coordination half cheap and puts the quality half at risk.
2. Make "Done" machine-verifiable. A commit in a ticket proves the work exists, not that it shipped. Ask of your own definition: if the work had silently not shipped, would the check look any different? If the answer is no, it verifies effort, not delivery.
3. Audit the gate, not just the output. My guards were wrong twice, and both times what they produced looked like a correct result.
4. Put adversarial review in from the beginning, and budget it. Mine started on day 10 of a 24-day build: every pull request at first, nightly once I saw the bill.
5. Govern on test-to-code ratio, not coverage percentage. It is harder to game with generated tests that assert nothing.
6. Keep retrospectives even when there is no team. With nobody else to spot a pattern, the written log is your only memory.
7. Restore the friction AI removed. Your old signals came free from other humans noticing. Rebuild them.

The caveat

AI supplied speed. Experience set direction. Twenty-five years of architecture decisions, security modeling and knowing when an AI is confidently wrong is what pointed it somewhere useful.

Someone without that background can replicate the speed. Whether they can replicate the quality is a different question, and my answer for now is not yet. Nobody knows where things will stand in a year or two.

I wrote the playbook. Then I became the case study. And the case study found a defect in the playbook.