TL;DR. When release frequency swings, your IT system is telling you something about the balance between capacity and demand. Stability is the signal of equilibrium. Speed is not.
Proposition
A variation in software release frequency indicates an imbalance between IT production capacity and demand.
A reminder: Little's Law
Formulated by John D. C. Little in 1961 and since applied to call centres, factories, hospitals, and software delivery alike, the law states that in any stable system:
Cycle time (W) = Work in progress (L) / Throughput (λ)
Arrival rate (λ) is the pace at which new demand enters the system. In software, this is the inflow of requests, features, incidents, change orders.
Work in progress (L) is the stock of items currently inside the system, neither arrived nor delivered.
Cycle time (W) is the average time an item spends in the system, from arrival to delivery. It is what release frequency measures at the outlet.
In a stable system, arrival rate and throughput are equal, hence the shared symbol λ.
The equation is mechanical. Two consequences follow.
First consequence. If arrival rate and throughput remain equal, WIP stabilises and cycle time stabilises. Release frequency is steady.
Second consequence. If arrival rate exceeds throughput, WIP accumulates and cycle time grows. Release frequency drops. If throughput exceeds arrival rate, WIP drains and the system generates idle capacity. Release frequency rises, often on artificial work.
This is not a framework. It is an identity. Which is why the three scenarios below are not possibilities among others. They are the only three regimes the system can occupy.
Demonstration
In an Agile organisation practising continuous delivery, demand for software and services flows continuously, and scope adjusts continuously in return. Within that flow, three scenarios shape release cadence.
1. Demand exceeds capacity
The production cycle slows. Quality drops under pressure, scoping eats time, prioritisation churns, morale frays. Productivity follows. A sudden injection of capacity does not fix it. Onboarding creates inertia, disrupts team dynamics, and delays the payoff. Release frequency trends down.
This is the territory Brooks mapped in 1975: adding people to a late software project makes it later.¹
2. Capacity exceeds demand
Engineers need something to build. Free time becomes feature creep: unnecessary work added to stay busy. Over-engineered solutions generate rework and corrective releases. Cycle time shortens, output multiplies, release frequency trends up. The numbers look good; the substance is noise. This is Parkinson's Law in code: work expands to fill the time available.²
Case in point: AI coding assistants, 2024 to 2026. GitHub Copilot reached twenty million users by mid-2025. An estimated 41% of new code is AI-generated or AI-assisted, rising to 46% among Copilot users. Pull request throughput per author is up 20% year on year. Release frequency has rarely been higher.³
Now the other side of the ledger. Median pull request size grew by a third through 2025. Incidents per pull request rose 23%. The 2025 Stack Overflow Developer Survey names AI-generated code that looks right but is subtly wrong as the single greatest frustration for developers. Nearly half say debugging AI code takes longer than writing it themselves.⁴
The effect reaches users. Organisations now run an average of 130 SaaS applications, up 18% year on year. 96% of employees report dissatisfaction with their workplace tools. Research on SaaS usage consistently shows that 80% of a product's value comes from 20% of its features, yet feature inventories keep growing.⁵ Users overweight capability before purchase and usability after. Capability sells. Usability retains.⁶
Capacity is exceeding demand at industry scale. The cadence is up. The substance is noise.
3. Capacity matches demand
Teams ship relevant features, on time, at a sustainable pace. Quality holds. Cycle time stabilises. So does release frequency. This is the state every other scenario points towards.
Case in point: a programme inside a global financial messaging infrastructure. Over two quarters, release cadence dropped by 50%. The backlog was saturated, the team was exhausted, quality was starting to erode. The instinctive answer was to add capacity. The working answer was the opposite. We ran a scoping conversation with product and sponsor, arbitrating feature by feature: what is mandatory this quarter, what is not. 60% of the backlog was deferred to a future release. One further initiative was kept, gated on incident rates stabilising first. The residual scope matched realistic throughput. Three sprints later, cadence had recovered and stabilised. Throughput returned without a single additional hire. Equilibrium was one scoping conversation away, not one recruitment cycle away.
The principle holds well beyond this case. Donald Reinertsen formalised it in 2009 across 175 principles of product development flow: cadence is a regulation mechanism, not a target.⁷ Toyota's Heijunka, production levelling to match takt time, is the same idea applied to cars since the 1950s. The field knows this. Organisations forget it.
Reading the signal
A rising cadence suggests overcapacity.
A falling cadence suggests undercapacity.
A stable cadence signals equilibrium: production flow matches demand flow.
Scholia
Chasing higher release frequency is a goal, not a strategy. The right target is stability over time, with capacity or demand adjusted to context.
Stability is not a fixed number. Release frequency must remain a floating indicator whose movements drive structural decisions.
Two distinctions matter.
Long-term deviation from the mean. A signal of structural over or undercapacity. Structural action required.
Temporary deviation. An expected or periodic imbalance. No structural action required.
A sudden burst of releases to absorb a demand surge, produced by a pre-existing safety margin, is desirable. A seasonal dip during winter holidays, driven by reduced capacity, is expected.
This is not an argument against high deployment frequency. Research on high-performing engineering organisations shows elite teams deploy multiple times per day.⁸ The argument is about targeting. Goodhart's Law applies: when a measure becomes a target, it ceases to be a good measure. Release frequency is valuable as a diagnostic. It is dangerous as an objective.
Read the signal. Act on the signal, not on the number. That is the first movement of the method: Read. Reduce. Deliver.
Notes
¹ Fred Brooks, The Mythical Man-Month (1975).
² C. Northcote Parkinson, "Parkinson's Law" (The Economist, 1955).
³ GitHub Copilot adoption and AI-assisted code productivity. See AI Coding Assistant Statistics 2026, GitHub Copilot Statistics 2026, AI Is Writing 46% of All Code.
⁴ Code volume, PR size, incident rates, and debugging fatigue under AI-assisted development. See AI Copilot Code Quality 2025 (GitClear), The AI Productivity Trap (CIO), AI vs Human Code Generation Report (CodeRabbit).
⁵ SaaS application inventory, employee tool dissatisfaction, and the 80/20 rule of feature value. See SaaS Fatigue Syndrome 2025 (Lemon Learning), App Fatigue (Strety), Feature Fatigue (Userpilot).
⁶ Thompson, Hamilton, Rust, "Feature Fatigue: When Product Capabilities Become Too Much of a Good Thing" (Journal of Marketing Research, 2005). See also AI and Feature Bloat (Medium).
⁷ Donald G. Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development (2009). John D. C. Little, "A Proof for the Queuing Formula L = λW" (Operations Research, 1961).
⁸ Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and High Performing Technology Organizations (2018). See also the DORA Research Program.