Iteration speed: what fast teams actually measure

Smiling person in layered hair w/eyelashes,gesturing

Published on 14 August 2026 by Zoia Baletska

The fastest iteration loops in the world right now are not in software.

Since 2022, drone and counter-drone development in the Russo-Ukrainian war has compressed to a cycle that defence correspondents and the manufacturers themselves describe in weeks. A jamming or interception technique appears at the front. Designs change in response. The changed design meets a new countermeasure, and the loop starts again. Conventional defence procurement, by contrast, is organised in years — requirements, tender, integration, acceptance.

Why those loops are fast

Not because anyone adopted speed as a value, or ran a transformation programme. They are fast because the feedback is immediate and unambiguous, and because the cost of being slow is absolute. A design either survives contact or it does not, and the answer comes back within days. Nobody has to build a dashboard to find out which it was.

That is worth stating plainly, because it is also where the comparison stops. This is a war in which people are being killed, and the forcing function behind those short cycles is not one any software organisation has, wants, or should imitate. The useful observation is narrower and it runs the other way: when feedback is fast and unambiguous, iteration speed takes care of itself. Everywhere else, it has to be built deliberately — and what most teams are missing is not urgency, it is the loop.

AI put every engineering team on a compressed cycle

The second place this is visible right now is much closer to home. Assistants, review bots and test generators change on a monthly cadence, and the working practices around them change with each one. Any team that adopted an AI coding tool in the last two years is running an experiment, whether or not anyone is treating it as one.

The difference between teams that get something out of that and teams that do not is rarely the tool. It is whether anyone can tell what changed. That starts with knowing what to track before the code arrives — we set out the adoption signals worth collecting in measuring AI adoption and tool usage, and the wider picture in what AI actually bought your engineering team.

In software, a slow loop is invisible

This is the real problem. The cost of a slow iteration in software is never absolute and almost never immediate. A release slips a quarter. A competitor ships something similar first. A design decision made in March turns out to be wrong in September, by which point four other things depend on it. No single moment announces itself as the one where it was lost, so nobody escalates and nothing gets fixed.

Teams compensate by asking each other how it feels. It feels slower than last year. It feels like reviews take longer. Sometimes that is right, and sometimes the thing that actually changed is that one queue got longer while everything else stayed exactly as it was. Feelings are a reasonable place to start a conversation and a poor place to end one.

What iteration speed is actually made of

It breaks down into four measurable things, and they are worth separating because they fail independently.

Lead time for changes — from commit to running in production. This is the honest end-to-end number and the one most teams have never actually looked at.
Deployment frequency — how often you can ship, which sets the smallest change you are able to make. A team that deploys monthly cannot iterate weekly, whatever anyone decides in planning.
Cycle time — from starting work to finishing it. The internal half of the picture, and the one that moves when review or QA capacity changes.
Where work waits — review queues, approvals, environments, dependencies. In most pipelines this is the largest share of elapsed time and the one nobody is tracking.

The first two are DORA metrics, and if the distinction between the third and the second is not obvious, it is worth ten minutes: cycle time and lead time answer different questions and get mixed up constantly. For where the four came from and what the research behind them does and does not say, start with what DORA metrics are and why they matter.

Speed on its own is not the goal

A team that ships twice as often and breaks production twice as often has not improved anything; it has just moved the cost somewhere less visible. Iteration speed only means something when it is read next to change failure rate and time to restore. Fast and stable is the combination that separates teams, and it is also the combination that is hard to fake — you can game either number on its own, but gaming both at once amounts to doing the work properly.

Making the loop visible

This is the part Agile Analytics is built for. It connects to the systems the work already runs through — your ticket system, your repositories, your pipelines — so lead time, deployment frequency and cycle time come from events that actually happened rather than from anyone's recollection in a retrospective. Sprint Insights shows where the time went inside a sprint, including the work that never made it onto the board.

What that buys you is not a number to report upwards. It is a loop of your own: change one thing — the review policy, the size of a batch, who is on call, whether AI assistance is on — and watch whether lead time moves. Then keep the change or drop it. That is the same mechanism the fast domains have, reconstructed for a domain where reality does not report back on its own.

Iteration speed is not a virtue you adopt. It is an outcome of a feedback loop that is short enough to learn from, and the first step is being able to see the one you have.