Your Team Says It Does Agile. Your Release Frequency Says Otherwise.

Seventy-one percent of organizations use some form of Agile in their software development lifecycle.1 Most of them have standups. Most of them have sprint boards. Most of them have retrospectives.

Most of them still ship unpredictably.

The ceremony isn't the problem. The operating cadence is.

Agile as Ceremony vs. Agile as Operating System

There is a version of Agile that is a set of meetings, and a version that is a commitment to delivering working software on a regular, measurable tempo. Most companies practice the first version while believing they practice the second.

The original Agile Manifesto, published in 2001, defines this clearly.2 Among its twelve principles: deliver working software frequently, with a preference for the shorter timescale. Respond to change over following a plan. Working software is the primary measure of progress. The manifesto says nothing about standups. It says nothing about story points. Those came later, as tools. The tools became the practice.

When a team has standups but no regular release cadence, it has the tools without the operating system. The tools are not harmful. They are just not the point.

What a Real Operating Cadence Looks Like

The most effective engineering organizations run on nested planning cycles. A longer horizon for strategic alignment. A medium cycle for execution focus. A short cycle for accountability and adjustment.

A typical pattern that works: six-month planning arcs that establish what the team is trying to accomplish and why. Six-week sprints that define what the team is committing to build within that arc. Two-week delivery checkpoints that force a review of what was actually completed and what needs to change.

Six weeks is not a rule. Some teams run four-week sprints; others run five. Consumer product teams with faster feedback loops often prefer shorter cycles. Enterprise teams building complex integrations often need longer ones. The specific length matters less than the consistency. Pick a sprint length that your team can actually honor, and hold to it. A team that reliably ships at the end of every four-week sprint is operating better than one that theoretically runs six-week sprints but routinely slips into eight.

Each layer serves a different purpose. The six-month horizon connects engineering work to business goals, which prevents the team from building in isolation. The six-week sprint is long enough to accomplish something meaningful and short enough that planning doesn't drift. The two-week checkpoint is the accountability mechanism. Without it, sprints become mini-waterfalls, with work piling up at the end and exceptions accumulating unnoticed.

The key is that each cycle produces a visible, measurable output. Not a status update. Not a list of things in progress. Working software, shipped to production, countable.

---

Figure 1. Three nested planning cycles in a high-performing engineering organization. Sprint length varies by team (four, five, or six weeks are all common) but the nesting logic holds regardless. Each cycle produces a distinct accountability output, with cooldown periods built in after each sprint for planning, bug fixing, and recovery.

---

Release Frequency as the Acid Test

One of the clearest tests of whether a team has a real operating cadence is simple: how many production releases happened in the last quarter, and is that number consistent with the quarter before?

Not commits. Not merges. Not story points completed. Releases to production.

Release frequency is not the goal by itself. It is the visible symptom of whether the system can turn plans into production reliably.

A team with a functioning cadence produces a predictable release frequency. It might be weekly for a consumer product, monthly for an enterprise application, or something in between. The specific number is less important than its consistency. A team releasing 12 times per quarter, every quarter, for three consecutive quarters, is operating well. A team that releases 20 times one quarter and 4 times the next has a process problem.

New products and new repositories start with high release frequency as the team builds toward functionality. Mature products have lower but steadier frequency as the product stabilizes and the changes become more incremental. Both patterns are healthy. The warning sign is a consistent decline across all repositories simultaneously. That's usually hidden technical debt, organizational friction, or both.

Scrumban: The Hybrid Most Teams Actually Need

Pure Scrum is often a better fit for teams with more plannable feature work in defined sprints. It can struggle when work arrives unpredictably, when support and maintenance load competes with planned development, or when the team grows beyond a certain size.

Pure Kanban is often a better fit where interrupt-driven work is dominant, but it can lack the planning discipline that connects work to business outcomes.

The most effective mature teams run a hybrid: they use Scrum's sprint structure to create planning rhythm and commitment discipline, and Kanban's continuous flow visibility to manage work that doesn't fit neatly into a sprint. This is sometimes called Scrumban. Most teams end up here without naming it.

The important thing is that neither approach works without a consistent deployment cadence. You can have a perfect sprint board and still be shipping nothing. The board is the plan. The release is the result.

---

Figure 2. The gap between Agile ceremony adoption and consistent delivery cadence. Most teams have the meetings. Fewer have a predictable release tempo.

---

Embedded QA as a Cadence Multiplier

One structural decision that often has an outsized impact on release cadence is where QA lives in the team.

In most engineering organizations, QA is a gate. Work moves through development, then hits QA as a separate phase, then (sometimes) gets released. The QA phase is where cadence dies. It's the point where batches accumulate, releases get delayed, and the sprint board stops reflecting reality.

When QA is embedded in the delivery team rather than staged as a separate function, quality is built into the process rather than appended to it. QA engineers participate in planning, catch issues earlier, write automated tests as features are built rather than after. The result is a shorter feedback loop and a more consistent release cadence.

This is not a new idea. DORA's research consistently favors shared ownership, reduced handoff friction, and strong delivery practices over siloed, phase-gated models.3 Embedding QA is how you operationalize that result.

The Question to Ask This Week

If someone asked you how often your team ships to production, and you had to produce the number in five minutes, could you?

If not, your team doesn't have a release cadence. It has intentions.

The number is the starting point. Once you have it, you can ask whether it's consistent. Once you know whether it's consistent, you can ask why or why not. The answer to that question is where the real engineering work is.

---