The Rhythm of Reliability: Inside Canonical’s Operational Cadence

In software engineering, we often talk about the “iron triangle” of constraints: time, resources, and features. You can rarely fix all three. In many companies, when scope creeps or resources become tight, the timeline is often the first element of the triangle to slip.

At Canonical, we take a different approach. for us, time is the fixed limit.

It’s not just about strict project management. It is a mechanism of trust. Our users, customers and the open source community need to know exactly when the next Ubuntu release is coming. To deliver that reliability externally, we need a tight operational rhythm internally, and for more than 20 years we have delivered on this commitment.

Here’s how we orchestrate the business of building software, from our six-month cycles to the daily pulse of engineering:

Fig. 1 Canonical’s operating cycle

The six month cycle

Our entire engineering organization operates on a six-month cycle that aligns with the Ubuntu release cadence. This cycle is our heartbeat. This drives accountability and ensures we ship features on time.

To make it work, we rely on three critical control points:

• Sprint Readiness Review (SRR): This is where prioritization happens. Before a cycle begins, we don’t just ask “what fits?”: we ask “what matters?” We sift through feedback to find the most valuable engineering opportunities, ensuring we prioritize quality and impact over volume. We don’t start the work until we know the scope is worth it.

• Product Roadmap Sprint: The SRR culminates in this one-week, face-to-face event. This is the formal moment of truth where we close the previous cycle and leadership signs off on the plan for the next one. This ensures that each team leaves the venue with a clear, approved mandate.

• Midcycle Review: Three months later we hold a “Virtual Sprint” to check our progress. It is extremely important that we review any “bad news” in which we immediately identify items that will not ship or are at risk. By paying attention in advance to what won’t happen, leadership can make informed decisions to make immediate course corrections rather than letting a deadline slip.

This discipline ensures that we remain nimble, and that we can adjust our trajectory halfway through without derailing the entire delivery.

The pulse of two weeks

While the six month cycle determines the destination, the “pulse” takes us there. A pulse is our version of a two-week agile sprint.

It is extremely important that these pulses are synchronized across the company, on a cross-functional basis. Marketing, sales and support all operate on the same frequency. When a team member says, “we’ll do it next pulse,” everyone, regardless of department, knows exactly what that means. This creates a shared expectation of delivery that moves the entire organization into the barrage.

Sprints are for personal connection

We distinguish between a “pulse” (our virtual, two-week work iteration) and a “sprint.” For us, a sprint is a one-week physical event where teams meet face-to-face.

We are a remote-first company, which makes these moments priceless. Sprints provide the high-bandwidth communication and human connection needed to sustain us through months of remote execution.

We also scaffold these sprints to separate context. We Engineering sprints happen in May and November (immediately after an Ubuntu release) so teams can focus purely on technical roadmaps. Commercial sprints happens in January and July, which corresponds to our fiscal half-year to focus on business value. This “double clock” system ensures that commercial goals and technical realities are synchronized without overwhelming the teams.

Manage the exceptions

Of course, the market reality does not always conform to a six-month schedule. Customers have urgent needs, and high-value opportunities appear unexpectedly. To handle this without breaking our rhythm, we use the Commercial Review (CR) process.

The CR process protects our engineering teams from chaos while giving us the agility to say “yes” to the right opportunities.

• Protection: We don’t allow unverified requests to disrupt the roadmap. A review board assesses each non-standard request before we make a pledge.
• Conscious Considerations: If a new request is critical, we ask, “What are we removing to make room for this?” It forces a conscious decision. We review the roadmap and agree on what is deprioritized to meet the new request.

This ensures that when we do deviate from the plan, it is a strategic choice, not an accident.

Quality as a natural habit

The foundation of this whole rhythm is a commitment to quality standards. We follow the Plan, Do, Check, Act (PDCA) cycle, a concept rooted in ISO 9001. While we subscribe to these formal frameworks, it has become a natural habit for us at Canonical.

This operational discipline is what up to 15 year LTS commitment on a large portfolio of open source components, providing long-term support for the entire, integrated collection of application software, libraries and toolchains. Offering 15 years of security maintenance on our entire stack is only possible because we are operationally consistent. Long-term stability is the direct result of short-term discipline.

By keeping to this rhythm, we ensure that Canonical remains not only a source of great technology, but a trusted partner for the long term.