Scrum, day 48: expanding responsibly

Today's objective: identify what must improve before adding more teams is likely to help the product rather than multiply existing dependencies.

Read alongside: Mastering Professional Scrum, chapter 7, focusing on outcomes and scaling; optionally revisit Scrum: A Pocket Guide, fourth edition, §3.8. Allow roughly five minutes for this companion, plus the reading.

More requests make expansion attractive

Several café owners express interest in the fictional ShiftSwap product. The organization proposes adding another team so it can deliver more features at once. The existing team welcomes help but knows that request-state logic, operational verification, and product decisions already create coordination challenges.

Adding people may increase capability. It may also increase the number of changes waiting on the same specialist or the same unresolved product rule. The team needs to identify the actual constraint before choosing a larger structure.

The question is what additional capacity would enable and what conditions must change for that capacity to produce usable results.

Examine the current path to a usable Increment

The team traces a recent change across design, implementation, integration, verification, and operation. It asks where work waits and which decisions require the same few people.

If the main delay is a shared environment queue, two teams could create a longer queue. If the main difficulty is conflicting product priorities, two separate feature lists could deepen the conflict. If the product has a clear direction and teams can complete coherent changes with dependable integration, additional capacity may be more useful.

These are hypotheses to investigate. The team should avoid both automatic enthusiasm for expansion and a blanket claim that more teams can never help.

Keep one product understandable

If multiple Scrum Teams work on the same product, the current Scrum framework calls for a shared Product Goal, Product Backlog, and Product Owner, along with a common Definition of Done. See the Scrum Team and Definition of Done sections.

For ShiftSwap, this means product choices remain coherent across the employee and manager experiences. Two teams should not independently promise incompatible request behavior or use different standards for claiming their changes are complete.

Shared direction does not require every person to attend every discussion. It requires enough coordination that the combined product remains understandable and usable, and that local decisions do not quietly undermine the common goal.

Avoid organizing around permanent handoffs by default

One proposal creates an interface team and a service team. Each would have a clear specialty, but most user-visible changes would need both. A third group might then verify the combined result.

That structure could institutionalize the handoff problems the current team has been trying to reduce. Each group might report progress while the connected capability remains unfinished.

The organization should examine whether teams can be formed around coherent product work with the skills needed to finish it. There may still be shared expertise and dependencies, but those should be explicit design considerations rather than surprises discovered after the reorganization.

Establish integration as ordinary work

If teams develop separately and combine their work only before a major release, incompatible assumptions can accumulate. Each team's local checks may pass while the product's request sequence fails.

ShiftSwap needs a practical way to integrate and verify changes frequently enough to detect those problems while they remain manageable. That includes shared examples for cross-cutting behavior, compatible environments, and clear responsibility for the combined result.

The particular tools and coordination practices depend on the product. Adopting a named scaling approach does not remove the need to solve these concrete integration problems.

Invest in the limiting capability first

The organization might improve the shared verification environment, reduce dependence on one specialist, or clarify product boundaries before forming another team. These investments can make later expansion more effective and may improve delivery immediately.

It should compare that option with adding people directly. What result is expected from each investment? How soon could evidence appear? Which existing difficulty might become worse?

The purpose is not to demand perfection before growth. It is to avoid expanding a system whose main constraint is already known and unlikely to improve through additional parallel work alone.

Treat expansion as an inspectable change

If the organization adds a team, it can define what it expects to improve and what it will watch. Useful observations include the ability to produce integrated changes, time spent waiting on dependencies, clarity of product decisions, and user outcomes.

Counting two teams instead of one does not establish twice the capability. A temporary slowdown may occur while people learn and relationships form. The organization should make room for that transition while checking whether the intended benefits become visible.

If coordination grows but useful delivery does not, the structure or supporting conditions may need adjustment. The investment should remain open to inspection rather than become untouchable because a reorganization has already been announced.

Prepare an expansion question

Choose a product considering more teams. Identify its current delivery constraint, the expected benefit of expansion, and one reason expansion might worsen the constraint.

Describe a capability or organizational change that would make expansion more credible. Then define evidence to inspect after the change, including the quality and coherence of the combined product.

Reflection: if another team started tomorrow, which shared decision or dependency would receive twice the demand? Addressing that point may be more urgent than choosing a scaling vocabulary.

Next, day 49 reviews how your understanding has changed across the series.