Scrum, day 57: moving beyond one team

Today's objective: identify which conditions behind a successful local change can transfer and which organizational obstacles need a different response elsewhere.

Read alongside: Software in 30 Days, selected passages from chapters 8–9; optionally revisit Scrum: A Pocket Guide, fourth edition, §4.2. Allow roughly five minutes for this companion, plus the reading.

A successful pilot invites a premature template

The fictional ShiftSwap pilot attracts interest from other parts of the café organization. A central group proposes copying its board columns, meeting schedule, estimation approach, and reporting format to every software initiative.

Some shared practices may help. The proposal nevertheless risks copying visible arrangements without understanding the conditions that made them useful. ShiftSwap had a coherent product, available users, clear product authority, and a sponsor willing to resolve priority conflicts.

Another initiative may lack those conditions. Installing the same board would not automatically create them. The organization needs to transfer the reasoning and investigate the local constraints, not merely reproduce the pilot's appearance.

Separate principles, requirements, and local techniques

The current Scrum framework provides common requirements and purposes. A specific board design, estimation scale, or refinement meeting is a local technique. The distinction helps the organization decide what needs consistency and where teams should adapt their approach.

For example, a shared understanding of Done for teams working on the same product is important. Requiring every team to use identical column names may be less useful if their work and information needs differ.

The organization should be able to explain the purpose of any proposed standard. A standard that supports integration or necessary transparency has a stronger justification than one chosen mainly to make reports look uniform.

Find a constraint that crosses team boundaries

Several teams report waiting for the same environment approval. Each has improved its request process, but the central queue remains unpredictable. Treating this as a separate coaching issue for every team would duplicate effort while leaving the common cause untouched.

The organization can examine demand, safeguards, authority, and available capability across the whole service. It may need a clearer access model, improved tooling, or different allocation of expertise.

This is an example of a wider change that local success can reveal. The pilot provides evidence about the consequence, but the remedy requires people with authority over the shared system.

Avoid comparing teams through incompatible measures

A central dashboard proposes ranking teams by story points completed. Different teams use different sizing conventions and work on different products. The apparent comparison may encourage larger estimates or easier selections rather than better outcomes.

The organization should ask what decision the comparison is intended to support. If it needs to understand investment and product progress, it should examine relevant outcomes, constraints, quality, and forecasts in context.

Some measures can be shared usefully when their definitions and interpretation are clear. The goal is not to avoid measurement, but to prevent a uniform number from creating false comparability or harmful incentives.

Let teams learn from one another's decisions

ShiftSwap can share a concrete account of its work-in-progress experiment: the problem observed, the initial limit, the exceptions, the results, and the adjustments. Another team can then examine whether the mechanism applies to its own situation.

That exchange is more useful than requiring every team to adopt the same limit. It preserves the reasoning and the evidence, including where the practice did not help.

Communities of practice, demonstrations, and shared examples can support this learning if they remain connected to real work. They become less useful when they mainly distribute approved terminology or collect compliance reports.

Expand at a pace the support system can sustain

The organization has a limited number of experienced coaches, specialists, and decision-makers. Expanding adoption faster than those people can help may create teams with new expectations but little practical support.

It can choose a smaller next group, address a common constraint first, or invest in developing internal capability. The decision should consider both the demand for change and the organization's ability to support it.

A slower rollout can still be wasteful if it produces no learning. A faster rollout can be effective when conditions are ready. The useful question is what evidence supports the chosen pace and how the organization will recognize when it needs to adjust.

Preserve room to change the adoption plan

Suppose the next team finds that its product boundary is unclear and its Product Owner lacks authority over several contributing departments. That discovery may require a structural conversation before more local practices can help.

The organization should allow the adoption plan to respond. A fixed checklist that requires the team to declare success on schedule can conceal the very information the change effort needs.

Wider adoption is itself complex work. The organization can use small steps, visible evidence, and explicit decision points rather than assume the pilot has already answered every question.

Prepare a transfer conversation

Choose one practice that helped a team. Describe its original problem, the conditions that supported it, and the evidence of benefit. Then examine a second setting and identify which conditions are present, missing, or different.

Propose a local experiment or an organizational decision appropriate to that second setting. Include one element that should remain consistent and one that should be adapted, explaining the purpose of each.

Reflection: what part of your proposed rollout copies a visible practice, and what part creates the conditions that made the practice useful?

Next, day 58 makes the adoption effort open to inspection and adaptation.