How a team delivered 48% more per maker hour

Why the process changed

An organization had depended on off-the-shelf software for two decades. Three successive platforms still left it with data the team could not fully trust. The organization hired Atomic Object to build a replacement it could own and change.

The multidisciplinary team began with Atomic's established agile delivery process. Developers used AI-assisted editors for cleanup, suggestions, and occasional task-level experiments. That was normal use of AI in early 2026. The team's planning, review, and knowledge-sharing practices still assumed people would write most of the code.

Partway through, the team hit the central risk of any large rewrite. Two decades of accumulated workflow, spread across three prior platforms, surfaced scope that no proposal-stage analysis could have fully mapped. The system revealed its true size only as the team got inside it, and the original delivery date was no longer feasible.

The team went to the client with a revised date and a plan for hitting it: additional developer capacity, and a change to how the team itself worked. Reworking the delivery process gave the team a way to deliver more within the client's existing budget.

The delivery lead was skeptical that an agentic process belonged on this project. The architecture and domain were complex. Prior systems had failed because of unreliable data. The project had more ways to be subtly wrong than a simple greenfield application.

Two existing strengths made the change plausible. The team had already built unusually thorough project documentation, and Atomic helped it set up an agent harness that connected those materials to the code. The agents could work from reviewed specifications and recorded decisions instead of relying on a developer to restate the domain in every session.

What the team changed

Start with the bottleneck people already feel

The team did not adopt every practice at once. The delivery lead asked one question: "What is painful for you on this project that you don't want to keep doing?" The answer was PR review.

A hopes-and-fears exercise helped the team see why PR review had become a standing queue: it carried two jobs. Reviewers checked code quality, and they also used each PR to learn what other parts of the team were building. The team moved the context-sharing job into a dedicated developer sync. AI review took the first pass on code quality, with a person reviewing after it. That relieved the queue while preserving the shared understanding developers had been getting from PRs.

That first change mattered because it solved a problem the team had named. It gave skeptical developers one useful experience with agents before the team changed how implementation worked.

Make written direction executable

The next experiment was spec-driven implementation. The delivery lead wrote the first product specs with a product-minded developer. During sprint 12, one stream of work used those specs and the harness while the rest of the team continued with its existing approach.

That stream completed roughly two to three sprints of planned work in one sprint.

The harness connected the project's Knowledge Base to the repository. A reviewed product spec could sit beside the code, and an implementation agent could read the exact document. Meeting transcripts and prior decisions stayed available with their sources, which reduced the need to reopen settled questions. Maintaining that Knowledge Base took real time. The delivery lead's assessment was simple: cumbersome, and worth it.

This is the mechanism described in the book's Definition chapter. Written direction becomes a build input. The agent receives the same product decision the team reviewed, without another paraphrase between the decision and the implementation.

Adapt the model when the project teaches you something

The team adapted the agentic engineering process to fit its project. The choices below reflect what it learned along the way.

• Feature champions carried work across both tracks. The book distinguishes definition work from implementation work. This team tried an approach with separate team members doing each. The sprint in which people who hadn't written the spec were the ones handing it to agents was among their lowest-delivery sprints on record. What they run now is feature champions: one person owns a domain area from definition through implementation. In a complex domain that requires judgment and expertise, this keeps the understanding developed during definition with the person guiding implementation.
• Two-week sprints remained. The team kept its original sprint cadence, including internally. The new review and implementation practices happened inside those sprints.
• Jira tickets stayed detailed. The client used the backlog as a source of truth, so a strong spec did not remove the need for readable tickets.

What the numbers show

Project timesheets and Jira records show that the team delivered 12.0 story points per 100 maker hours across sprints 5 through 10. Across sprints 12 through 17, after adopting the new process, it delivered 17.8. That is a 48% increase, rounded from the reported averages. The project is ongoing; the figures below cover the six completed sprints after adoption.

A maker hour is any hour contributed to the project by any role. It includes developers, design, delivery, and QA. This denominator accounts for staffing changes and time off. Total hours per sprint rose from 535 to 564, about 6%, while output per hour rose 48%.

Both comparison windows already included developers using AI-assisted editors. The later window added a delivery process designed around agents. The comparison therefore says more about the process change than it does about adopting an AI coding tool for the first time.

The project was maturing at the same time. Developers knew more about the domain, and the codebase had more established patterns. This is an observed association rather than a controlled experiment. Moving the baseline window produces gains from 47% to 55%; the reported 48% sits near the conservative end of that range.

Five of the six post-adoption sprints beat the prior average. Raw output rose from about 64 to 100 points per sprint. Of the 2,000-point initial scope, the team had delivered 1,244 points through sprint 17, leaving 756. At the observed pace, the remaining work was projected to finish around sprint 24 or 25. Holding the earlier pace would place it around sprint 29, roughly two months later.

What failed

One sprint fell below the old baseline

Sprint 15 delivered 9.8 points per 100 maker hours. It was the only post-adoption sprint below the earlier 12.0 average. Three complex streams started at the same time, and a newly released model tended to run beyond the requested boundary.

The delivery lead's lesson was to stagger the start of complex agentic work. A team may be able to run several mature streams in parallel and still struggle when several uncertain ones begin together.

The first tasks were too small, then too large

The team's existing tickets were sized for people picking up discrete pieces. Agents made those boundaries wasteful. Three small tickets often belonged in one delegation.

The team then pushed too far in the other direction. Given a large area, an agent would cross the intended boundary and begin future work that had been deferred because of dependencies. Cleaning that up took additional time.

Compounding work across the team

The developer syncs have also become a place to improve how the team works with agents. Developers bring recurring problems, compare approaches, and refine shared project guidance with Atomic's development practice lead. These conversations turn experience from individual tasks into improvements the whole team can reuse.

One recent example involved agents repeatedly missing project conventions despite written best-practices guidance. The team split that guidance into six focused skills for particular activities. By the next sync, developers reported that the smaller skills were working well. They also identified a cost: overlapping workflows were triggering repeated tests and reviews. The discussion shifted to when those checks should run and how to group work into meaningful review phases.

This is what the process calls Compounding Work: investing in improvements that make future delivery easier. For this team, that includes developing the judgment to use agents well. Developers are learning how much work to delegate, where human review helps, and which recurring corrections belong in shared guidance. One developer described how more reliable skills let her focus on broader decisions and begin overlapping agent implementation with planning and review. The shared workflow and the team's ability to use it are developing together.

What to carry forward

1. Solve a named pain first. The team began with its review queue, not a wholesale process rollout.
2. Make project knowledge available to the agent. Specs and recorded decisions reduced paraphrase and repeated debate.
3. Keep the comparison honest. The measurement includes every project role, excludes the transition sprint, and states the other factors that changed.
4. Treat a bad sprint as useful data. Sprint 15 showed the cost of starting several complex streams together.
5. Keep understanding with the work. Feature champions bring developers into definition and carry their domain understanding through implementation.
6. Improve the shared workflow as the team learns. Developer syncs turn recurring agent problems into focused skills and better decisions about testing and review.

The team had AI tools before it had an agentic delivery process. Six sprints after the change, output per maker hour was 48% higher. The result came with maintenance cost, uneven sprints, and adaptations to the book's default process.

Related reading: Engineering Sustainable Speed explains the review layers, harness work, and architectural discipline that keep higher implementation volume usable.