Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Sprint Cadence (At Scale)

DZone's Guide to

Sprint Cadence (At Scale)

Integrating work across Scrum teams can lead to more autonomy in the Scrum process, and reduce the number for Sprint Reflections.

· Agile Zone
Free Resource

Download this white paper to learn about the ways to make a Scrum Team great, brought to you in partnership with Scrum.org

A System Called ‘Scrum’

Scrum implements empirical process control. Scrum mitigates risk and optimizes value through regular inspections and adaptations in a closed-loop feedback system.

Taking a step back shows that the overall input to the system called ‘Scrum’ is a stream of options, ideas, possibilities and requirements ordered into a Product Backlog. Observable working results are created as Done Increments in short cycles called 'Sprints,' where a Sprint takes no more than 4 weeks, and often less.

Closed Loop Feedback (Scrum)

Sprint length is set to the right frequency to capture, and enact upon, insights about:

  • How valuable the product actually is,
  • The fitness of the applied technology.
  • Current strategic conditions (market, company).

On the inside of the system, several additional feedback loops help a team work towards a Done Increment (Daily Scrum, delivery practices, the definition of Done).

One Scrum Team

When one team develops and sustains a product through Scrum, the team's 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 external elements that block or slow down the creation of Done versions of the product.

Scaled Scrum - Singular Scrum


A Few, or More, Scrum Teams

When a few teams, or more, are developing and sustaining one product through Scrum, additional complexity comes into play. There are cross-team communication and integration needs, dependencies in Product Backlog and in the codebase. This results in the need for supplemental feedback loops, understanding that the goal of the 'Scrum' system invariably remains the creation of releasable Increments, where an Increment is for the product, not for a team.

Scaled Scrum - Multiple Scrum Teams

Within the Sprint, work is often synchronized via a Scrum-of-Scrums, a Daily Scrum across the teams, enabling the teams to replan their work based on the other teams' progress.

Often Scrum Teams find it also easier to work on the same Sprint length. The goal is to ultimately synchronize realizations and expectations at joint Sprint Reviews, which is the ultimate point to review one integrated version of a product.

It is however still a limitation of autonomy, and autonomy is the most optimal strategy to eliminate dependencies.

Cultivating Your Green Tree

The autonomy of teams is partly reflected in their ability to autonomously set their own, proper Sprint length. The autonomy of teams can be hugely 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 should get priority over all other work to be performed. Why add code to a codebase if the existing code isn't integrating? Cultivate your green tree!

When work is kept integrated in a rigorous way, 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, or shared. The work performed during their Sprint can be reviewed with the Product Owner and specific stakeholders as needed, allowing focus on a specific part of the system alone.

There are good reasons to have shared Sprint Reviews, but the inability to create integrated work should not be one of them. Shared Sprint Reviews may still be organized to address the need of collective adaptation against the new market, strategic or company evolutions, and insights that get processed in an updated Product Backlog. Time for reflection is still much needed. It will enhance the cohesion of the product being created.

Scaled Scrum - Integrating Scrum Teams

Complexity is suddenly hugely reduced, while the ability to release integrated software is improved. Autonomy is increased, and ultimately self-organization.

Discover what Scrum Teams do to make themselves great, brought to you in partnership with Scrum.org.

Topics:
scrum ,sprints ,agile

Published at DZone with permission of Gunther Verheyen, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}