In software engineering, we often talk about the “iron triangle” of constraints: time, resources, and features. You can rarely fix all three. At many companies, when scope creeps or resources get 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 constraint.

This isn’t 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 rigorous operational rhythm internally, and for over 20 years, we have honored this commitment.

Here is 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. It drives accountability and ensures we ship features on time.

To make this 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 go 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 the effort.

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

• Midcycle Review: Three months in, we hold a “Virtual Sprint” to check our progress. Crucially, we review any “bad news”, in which we immediately identify items that will not ship or are at risk. By addressing what won’t happen upfront, leadership can make informed decisions to course-correct immediately rather than letting a deadline slip.

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

The two-week pulse

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

Crucially, these pulses are synchronized across the entire company, on a cross-functional basis. Marketing, Sales, and Support all operate on this same frequency. When a team member says, “we will do it next pulse,” everyone, regardless of department, knows exactly what that means. This creates a shared expectation of delivery that keeps the whole organization moving in lockstep.

Sprints are for in-person connection

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

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

We also stagger these sprints to separate context. Our Engineering Sprints happen in May and November (immediately after an Ubuntu release) so teams can focus purely on technical roadmapping. Commercial Sprints happen in January and July, aligning with our fiscal half-years to focus on business value. This “dual-clock” system ensures that commercial goals and technical realities are synchronized without overwhelming the teams.

Managing the exceptions

Of course, market reality doesn’t always adhere 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 let unverified requests disrupt the roadmap. A Review Board assesses every non-standard request before we make a promise.
• Conscious trade-offs: If a new request is critical, we ask: “What are we removing to make space for this?” It forces a conscious decision. We review the roadmap and agree on what gets deprioritized to satisfy 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

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

This operational discipline is what enables up to 15 years of LTS commitment on a vast 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 sticking to this rhythm, we ensure that Canonical remains not just a source of great technology, but a reliable partner for the long haul.