Posted on 7 Comments

Sprint Cadence at scale

A system called ‘Scrum’

Scrum is founded on empirical process theory. Scrum implements regular inspections and adaptations in a closed-loop feedback system to deal with unpredictable events, changes and circumstances. The output of the system is used to be compared against new or updated input in order to update the output.

Closed Loop Feedback

The input to the system of ‘Scrum’ is Product Backlog. The output generated defines the core purpose of the system, i.e. the availability of a Done Increment. The time of one cycle to create such a Done Increment, which can be used as input for a new cycle, is limited to 30 days, and often less. Such a cycle is called ‘Sprint’ in Scrum.

Closed Loop Feedback (Scrum)

Technically Scrum has 2 elements of feedback being fed into the next cycle, i.e. the results of the inspection of the product at the Sprint Review (the Increment) but also the inspection of the process at the Sprint Retrospective. The system internally implements an additional, daily inspection and adaptation at the Daily Scrum to assure the best possible progress toward creation of a Done Increment.

Done (of an Increment) reflects releasable. Every Increment has all the qualities that make it fit for use. Whether it is actually released is a separate decision, but it has no impact on what defines “Done.”

One Scrum Team

When one team develops and sustains a product through Scrum, their ability to create releasable Increments might depend on the availability of skills within the team, access to tools and infrastructure, and dependencies within their one-team system. They self-organize around the inner-team dependencies, their Scrum Master works hard to (help) remove the other.

Scaled Scrum - Singular Scrum

Sprint length is set to the right frequency to enable learning (and incorporating new insights in the next Sprint) about:

  • How valuable the product actually is,
  • The fitness of the applied technology,
  • Current market changes.

A few, or more, Scrum Teams

When a few teams are developing and sustaining a product though Scrum, additional complexity comes into play. Additionally the teams face cross-team dependencies to produce releasable Increments, where releasable includes integration. This results in the need for additional communication and alignment. It explains why velocity, the measure of producing releasable software, of a team working stand-alone is always higher than the velocity of that same team in a construct of multiple Scrum Teams.

Scaled Scrum - Multiple Scrum Teams

Often Scrum Teams find it easier to work on the same Sprint length to have a shared Sprint Review and thereby reduce complexity. Within the Sprint work is synchronized via a Scrum-of-Scrums, a Daily Scrum across the teams.

When many Scrum Teams need to co-develop one product, dependencies become huge. There are not only the inner-team dependencies that every single team faces, but also an exponentially growing number of dependencies in Product Backlog and in the codebase.

The goal of a system called ‘Scrum’ however remains to create releasable Increments by the end of every Sprint, where a Sprint takes no more than 30 days, preferably less. If such Increment is not created, the closed feedback loop is broken, and the opportunity to adapt is lost.

A solution that up to some level circumvents this, is to align Sprint lengths of the involved Scrum Teams. The goal of such enforced cadence has the purpose of ultimately synchronizing at joint Sprint Reviews, the ultimate way to create and review integrated software. At the slowest pace of the involved team(s) a fully integrated Increment is available.

It is however still a limitation of autonomy, and autonomy is the best possible weapon against dependencies.

Cultivating Your Green Tree

The autonomy of teams is reflected in their ability to autonomously set their own, proper Sprint length. Such autonomy can be largely increased by keeping all code of the product integrated. At all times.

The state of integration of the work is a source of inspection that might lead to adaptations that get priority over all other work to be performed. Integration needs to be fixed first before -upon a green integration light- new work can be added to the system. Work on your trunk only, and keep your trunk green at all times. Cultivate your green tree.

When work is kept integrated at such a rigorous rate, the need or necessity of shared Sprint Review meetings, as the way to ultimately synchronize results across multiple teams, dissipates. When work is rigorously kept integrated, all the time, each and every one of the involved Scrum Teams can derive a reviewable Increment from the integrated codebase autonomously and independently. The work performed during their Sprint can be reviewed with the Product Owner and specific stakeholders, allowing focus on a specific part of the system alone.

Scaled Scrum - Integrating Scrum Teams

Complexity is suddenly hugely reduced, while the ability to release integrated software is retained as well as the advantages of time-boxing the creation of output. No heated debates over big enough rooms for all shared meetings. No heated debates over the exact time-boxes across teams. Autonomy, and ultimately… self-organization.

Scrum's DNAThe system exhibits all core characteristics of Scrum as a closed-loop feedback system, the same characteristics that one team would exhibit; empiricism and self-organization. As a whole the system exhibits flow and continuity. The system operates at scale, yet is back to being… Scrum. The benefits of Scrum are scaled. Individuality, bottom-up energy, collaboration, self-respect are framed, not overruled, imposed or dictated, leading to autonomous teams creating cohesive product.

7 thoughts on “Sprint Cadence at scale

  1. […] Cet article est fortement inspiré par les schémas de Gunter Verheyden dans son article sur la cadence des sprints à l’échelle. […]

  2. Hi, I like the approach and fully understand cadance for teams working on 1 backlog, however do you believe the cadance for scrum teams using different backlogs and therefore working on different products should be using the same sprint cadance and release dates ?

    1. Willy, my points is that not even teams working off of the same Product Backlog need the same cadence.

      1. Hi Gunther,
        Thank you for replying to my question, much appreciated. I hear you and I also agree with you. One of my customers has however the strange idea that the whole company should have the same cadance of 2 weeks sprints for every scrum team regardless of the application code language, complexity, backlog and interdependancy. My advice was to not force this to all the application teams, certainly knowing that they have little to no experience with scrum and sprint developments.

        1. A strange idea, indeed. And a correct advice. An organisation can standardise on Scrum without industrialising it. Forcing every team, regardless of product, technology, market on the same Sprint cadence ignores context, and is a meaningless decision. Long time ago I formulated some considerations on Sprint length,

  3. […] Cet article est fortement inspiré par les schémas de Gunter Verheyden dans son article sur la cadence des sprints à l’échelle. […]

  4. […] Cet article est fortement inspiré par les schémas de Gunter Verheyden dans son article sur la cadence des sprints à l’échelle. […]

Leave a Reply