...the organization has one or more Cross-Functional Teams working in Sprints.

✥       ✥       ✥ 

The Scrum Team and the rest of the organization are out-of-step, causing either waiting time or Sprint interruptions.

Scrum Teams depend on finances, sales and marketing, support, and other functions in an organization. Though we want Scrum Teams to be largely Autonomous Teams, they are rarely wholly independent units. A Scrum Team needs to coordinate with the rest of the organization and other teams. For example, when integrating a component from a supplier, doing integration test, or introducing new tools, the Scrum Team usually interacts with other departments or enterprises that feed its Value Stream. If the surrounding organizations have a monthly pulse owing to their business rhythm, and the Scrum Team has starting or ending dates for its Sprints that clash with those of the partner teams, the organization as a whole risks being out-of-step. The same is true if the Scrum Teams have different Sprint lengths.

On one hand, we want the surrounding organization to respect the teams’ Sprints and to not disturb them arbitrarily. At the same time, we need to support the flow from the broader organization into the Scrum Teams so we avoid unnecessary waiting or untimely interrupts.

Sharing common Sprint lengths can take away some freedom from each team. On the other hand it’s important to optimize flow by harmonizing Regular Product Increments with the organization’s rhythm.

Therefore:

Synchronize the rhythms of the Scrum Teams’ Sprints and the rhythms of the surrounding organization. Let the organization as a whole follow a monthly rhythm that can harmonize flow for Scrum Teams’ Sprints, as well as for the financial rhythm of the business. Allow teams and departments to choose shorter Sprints. For example, use a Sprint length of 1, 2, or 4 weeks.

✥       ✥       ✥ 

As a manager from a Scrum organization with Organizational Sprint Pulse formulated it:

Since things are done in Sprints of equal length, it is easier to synchronize. For example, if department A needs something from department B, it can be expected to be worked on in the near future. At least the progress can be followed.

In other words, working at the same cadence reduces mura (inconsistency) by keeping the workflows in balance and aligning Sprint start and end dates. Cadence creates natural synchronization points across the enterprise, and without synchronization points, inventory can build up. Consistent cadence helps smooth out flow ([1], pp. 176–78), reducing muri (stress). Being in sync makes it possible for all teams to work together to resolve dependencies immediately, in real time, instead of waiting for the next opportunity to align and to “get in step.” Reducing both mura and muri contribute to reduced waste. Organizational Sprint Pulse makes it easier for teams to share goals and to work together, and makes it easier for all teams to share a single instance of each of the major Sprint events of Sprint Planning, the Sprint Review, and the Sprint Retrospective. These combined waste reductions contribute to achieving the Greatest Value.

Most Scrum organizations in the wild use Organizational Sprint Pulse—and the literature generally recommends using it ([2]). This is particularly important in large development efforts or when there are several firms working together on a product, as in Development Partnership.

Organizational Sprint Pulse can appear to compensate for lack of Cross-Functional Teams and Stable Teams in order to keep specialization and resource management reminiscent of pre-Scrum times. Explicit synchronization points can be (ab)used to move team members between teams or to coordinate between specialized teams. This is not the intention of the pattern. Organizational Sprint Pulse works best with Cross-Functional Teams and Stable Teams.

Organizational Sprint Pulse focuses on external coordination, while Scrum of Scrums focuses on internal (to the jointly developed product) coordination. For some deeper considerations about cadence, see Follow the Moon.

[1] Donald Reinertsen. The Principles of Product Development Flow: Second Generation Lean Product Development. 2009, Redondo Beach, CA: Celeritas Publishing, pp. 176–78.

[2] Ulrik Ecklund and Jan Bosch. “Applying Agile Development in Mass-Produced Embedded Systems.” In Proceedings of XP 2012, C. Wohlin, ed. Heidelberg: Springer-Verlag, 2012, pp. 31–46.

Picture credits: Cicero Castro / Shutterstock.com.