Scrum, day 09: a team that can finish

Today's objective: identify a dependency that prevents a team from creating a usable result, then propose a practical way to reduce it.

Read alongside: Scrum: A Pocket Guide, fourth edition, §2.5, “Playing the game,” focusing on its discussion of the team, and Scrum.org's explanation of self-managing teams. Allow roughly five minutes for this companion, plus the assigned reading.

Look beyond the team's job titles

The fictional ShiftSwap team has several capable people. One understands the interface, another the approval rules, and another the message-delivery service. A fourth has extensive experience testing confusing combinations of events. Their individual skills look well suited to the product.

Yet the correction from day 08 remains unfinished. The team needs to check delayed messages in an environment it cannot configure. A specialist outside the team controls that environment and is occupied elsewhere. The Developers have written code, but they cannot yet verify the complete behavior against their quality standard.

This is a useful moment to examine what it means for a Scrum Team to be cross-functional. Collectively, its members need the skills to create value each Sprint. A list of impressive job titles does not establish that the team can complete the actual work its product requires.

Describe the path to a usable result

The team maps what this particular correction needs. It starts with understanding how a misleading notification affects a shift arrangement and ends with a verified change that can be operated reliably.

This map is an optional exercise. Its value comes from the conversation it starts: which capabilities are missing, which are concentrated in one person, and which exist but cannot be used because of an organizational constraint?

Those situations need different responses. Training someone will not by itself grant access to a system. Granting access will not by itself supply the judgment needed to use it well.

Keep expertise while reducing dependence

Cross-functionality does not require every person to be equally skilled at every activity. The test specialist may continue to notice cases others miss, and the message-service specialist may continue to make the hardest implementation decisions.

The team can still spread useful knowledge. Two Developers work through the delayed-message correction together. The specialist explains which ordering assumptions are safe and how to reproduce the failure. The colleague then adds a related check and explains it back. That provides stronger evidence of learning than merely attending a walkthrough.

The team also writes a short description of the setup and the important failure cases. The document supports future work; it does not replace practical experience. After another person successfully repeats the check, the team knows that some capability has actually become more widely available.

There is a cost. Pairing may make this particular task take longer than having the specialist do it alone. The team can weigh that cost against the recurring delays and fragility it observed. It should inspect whether the investment reduces dependence over subsequent work, rather than declaring success because a training session happened.

Distinguish choosing the work from being assigned every task

Self-management concerns the team's ability to organize its own work within clear goals and constraints. The Scrum.org reference emphasizes goals, boundaries, and accountabilities as conditions that support it.

Here, the Developers decide how to arrange the investigation, implementation, and checking. They can change that arrangement when they discover a bottleneck. Elena remains accountable as Product Owner for product value and backlog management; self-management does not erase that accountability or make every product decision a vote.

The Scrum Master can help the team examine its dependency and work with the organization to improve the conditions around it. A manager can help by clarifying authority and making learning time possible. Neither needs to choose a named assignee for every implementation step.

A board where all tasks are preassigned by someone outside the team would conceal an important opportunity: the people closest to the work may know a better way to complete the whole result.

Bring an organizational obstacle to its actual owner

The environment dependency cannot be solved entirely inside the Scrum Team. The specialist's group needs to protect a shared service and support several teams. ShiftSwap needs a reliable way to test a common failure mode.

Together they consider a bounded arrangement: the specialist helps create a repeatable setup for delayed-message checks, and the ShiftSwap team learns to use it within agreed limits. Unusual changes still receive specialist help. If that arrangement is insufficient, the organization may need to reconsider staffing, service boundaries, or access decisions.

External collaboration can remain valuable. The question is whether a recurring dependency prevents the team from producing a usable Increment each Sprint, and what can realistically improve that situation. Calling a team autonomous while leaving it unable to complete its regular work does not remove the dependency.

Check that completion is shared

At the next planning conversation, the team considers its complete capability and current availability. It avoids treating “implementation finished” as equivalent to the product being Done. The examples, checks, and operational work required by its quality standard belong in the delivery plan.

When the specialist is unavailable for part of the Sprint, the team makes that fact visible. It can select a smaller coherent result, arrange support early, or invest in the capability it lacks. The choice should be deliberate, with its consequences understood by the Product Owner and Developers.

Map one real dependency

Choose an improvement your team recently struggled to finish. List the capabilities needed to make it usable. For each, ask whether the team has the skill, the time, and the authority to do the work. These are three separate questions.

Choose one dependency to reduce. Describe a small learning or organizational change, the person or group who can help, and how you will know another person or the team can now complete the relevant work.

Reflection: if your most specialized colleague were unavailable next week, what useful result could the team still finish? Use the answer to identify a learning opportunity, without expecting everyone to become interchangeable.

The next companion turns to direction: how a Product Goal helps this capable team decide which results are worth pursuing.