My co-author Jesse White and I wrote a book called Run on Rhythm about building businesses that do not require burning yourself as fuel. It was written for small teams — five to fifty people — who are drowning in well-intended improvisations.
I just applied its core principles to an AI software project. The results were immediate.
The Problem
Sprint 9 had 155 story points planned. Our measured velocity was 38. That is a 4x overcommitment. We had been doing this for eight consecutive sprints — planning by ambition, measuring nothing, and wondering why every sprint ended in a scramble.
The test suite had 8 failing tests that nobody had investigated. A quality gate was blocking our UAT transition with 10 unresolved items. The team review had flagged six systemic issues. And the memory system that was supposed to make our AI agents intelligent was returning empty results for every query.
This is exactly the pattern Jesse and I describe in Run on Rhythm Chapter 1: a business that has learned to run on emergency energy. Emergency energy has a shelf life.
The 80% Capacity Rule
Run on Rhythm Chapter 2 introduces a counterintuitive principle: schedule your team at 80% capacity, not 100%.
The missing 20% is not slack. It is where reality lives. The job that runs long. The interruption that requires immediate attention. The process improvement that reduces future friction. The moment of rest that keeps someone from burning out.
We applied this directly. Sprint 9 went from 155 points to 42. Seven stories. Infrastructure first — SSL, test coverage, accessibility foundations, API documentation, end-to-end pipeline verification. None of these are features. All of them are things we had been skipping while shipping features.
The 19 stories that got moved are not deleted. They are planned, decomposed into tickets, and prioritized for Sprint 10. But they are not pretending to fit where they cannot fit.
The Risk Radar
Chapter 3 introduces the Risk Radar — a fifteen-minute weekly meeting where everyone names one thing that could go wrong. Not to solve it. Just to name it.
We had been running something similar through the ORCHESTRATE MCP framework, but we were treating RAID entries as documentation artifacts rather than living early warning signals. After applying the Run on Rhythm approach, we added explicit triggers to every risk: the specific signal that tells you the risk is materializing, and the pre-decided Plan B.
The memory system failure is the perfect example. Nine AI personas reported the memory system was dead. We filed it as a critical risk. The MCP developer looked at the data: 64 memories existed. The search was failing because agents wrote queries as sentences when the engine expected keywords.
A Risk Radar with the right trigger would have caught this: "If recall_memory returns empty for a persona with known stored entries, check query format before escalating to architecture review." Two lines of documentation fixed what we had been treating as a fundamental architecture failure.
Repair Over Blame
Chapter 1 introduces the concept of repair: when you miss a commitment, you own it and fix it. Not an explanation. Not a justification. Acknowledgment and corrective action.
When the test suite was failing, the instinct was to investigate root causes and file tickets. The Run on Rhythm approach was simpler: fix the tests. The 8 failures were all caused by a service rename from Sprint 8 that had not been propagated to the test files. Three edits. Zero failures. 4,394 tests passing.
The blameless approach also applied to the team review findings. When 9 of 14 personas agreed the memory system was broken, the old instinct would have been to ask: whose fault is this? The Run on Rhythm approach asks: what did the system reward? The system rewarded natural-language queries. The tool description taught natural-language queries. Nobody was wrong — the system was designed in a way that produced the failure.
What Developers Can Take From This
Run on Rhythm was written for small business operators managing HVAC crews and furniture shops. But the principles translate directly to software:
Load at 80%. If your sprint velocity is 38 points, plan 32-38 points. Not 155. The buffer absorbs reality — the PR that needs extra review, the dependency that breaks, the test that reveals an edge case. Without buffer, every variance becomes overtime.
Name risks before they arrive. A fifteen-minute weekly risk scan with triggers and Plan B costs almost nothing. The alternative — discovering risks at the deadline — costs everything.
Repair, do not explain. When the test suite is red, fix it. When the deployment fails, restore it. When the commitment slips, own it. Explanations come later, in the retrospective. In the moment, the priority is action.
Do not fill the buffer. The 20% breathing room is sacred. When you see empty calendar slots, the instinct is to schedule more work. Resist. The buffer is how quality breathes.
These are not software engineering principles. They are operational principles. They apply whether you are scheduling HVAC technicians or deploying Docker containers. The physics of overcommitment, hero dependency, and emergency energy are the same.
The Books
If any of this resonates, here is where to go deeper:
Run on Rhythm: Build a Business That Doesn't Run You — the full 5P framework (Proper, Preparation, Prevents, Poor, Performance) with stories, systems, scripts, and a 90-day implementation blueprint. Written for small teams who are tired of running on emergency energy.
The ORCHESTRATE Method: Structured Prompting for Professional AI Outputs — the framework behind the MCP server that enforces the methodology described in this post. Objective, Role, Context, Handoff, Examples, Structure, Tone, Review, Assure, Test, Execute.
Both books are the foundation of what we are building here: AI tools that augment humans to operate at a level they could not reach alone, without burning out in the process.
Sprint 9: 42 points. Infrastructure first. Buffer sacred. 4,394 tests green. The sprint that finally fits the team that has to run it.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.