Scrum, day 26: collaboration across skills

Today's objective: redesign a handoff so that the people with relevant skills can resolve an important uncertainty earlier.

Read alongside: Mastering Professional Scrum, chapter 2, focusing on collaboration and team development. Look for a recurring handoff in your own work rather than trying to adopt every possible collaboration technique. Allow roughly five minutes for this companion, plus the book reading.

Follow the question that travels backward

The fictional ShiftSwap team is improving the manager's view of a pending request. A colleague sketches the screen, another implements the service behavior, and a third prepares to verify the result. The work moves smoothly between columns until verification raises a question: what should happen if a request is cancelled while the manager is looking at it?

The question travels backward. The service Developer explains the stored state. The person who designed the screen revises the interaction. Elena checks the intended behavior with a manager. Several people revisit work they considered finished.

The problem is not that different people have different skills. The problem is that the relevant perspectives met after decisions had already hardened into separate pieces of work.

Locate the uncertainty before rearranging people

A vague instruction to “collaborate more” could produce a meeting with the entire team for every item. That would consume attention without necessarily improving this decision.

The team identifies the uncertainty more precisely: when the request changes elsewhere, what should the manager see, and what actions remain safe? Answering it requires knowledge of user expectations, request state, interface behavior, and verification. Those perspectives need contact before the behavior is implemented.

The useful change is to bring that question forward. The team can still divide implementation tasks afterward. Collaboration is valuable where it creates understanding or coordinates dependent decisions, rather than simply increasing the amount of time people spend together.

Build one example together

Elena and Developers with interface, service, and verification experience discuss a concrete sequence. A manager opens a pending request. The employee cancels it. The manager then tries to approve the old view.

They decide what the employee and manager should observe, how the action should respond, and what evidence would show the behavior is correct. The discussion reveals that a warning message alone is insufficient if the service still accepts the outdated approval.

Now the implementation plan reflects a shared scenario. The interface and service work can proceed with compatible expectations. Verification can challenge the same scenario and explore variations instead of discovering the basic disagreement at the end.

This example discussion is a proposed practice for ShiftSwap. Scrum does not prescribe its participant list or duration. The team can adapt it according to the uncertainty and the people available.

Share enough knowledge to reduce a recurring dependency

The message service remains familiar to only one Developer. Whenever a change touches it, other work waits for that person. Pairing on a small, relevant change could help another colleague learn how the message sequence is produced and checked.

The learning objective should be concrete. After the session, can the second person trace a message to its originating event, explain the important failure case, and make a modest change with appropriate review? “We paired for two hours” describes activity, while those questions describe developing capability.

The experienced colleague also learns where the system is difficult to understand. A confusing setup step or an undocumented assumption may become visible only when somebody else tries to use it. Collaboration can improve both knowledge distribution and the work environment.

Preserve depth of expertise

Cross-functional teamwork does not require every person to become equally skilled in every discipline. A colleague with deep accessibility knowledge may notice problems others miss. Someone with operational experience may recognize a failure pattern that is invisible in a local demonstration.

The team benefits when that expertise influences decisions at the right time and when ordinary work does not depend unnecessarily on one person's availability. These aims can coexist. People can learn enough to collaborate effectively while continuing to develop distinct strengths.

It would be counterproductive to measure success by how many different job labels each person can claim. The practical question is whether the team can create and maintain a usable product, including when a colleague is absent or an unfamiliar problem appears.

Avoid replacing a handoff with constant interruption

Earlier collaboration does not mean everyone must answer every message immediately. ShiftSwap can agree on a short discussion when a relevant item is refined, arrange pairing for a difficult section, and use the decision record from day 24 to preserve the conclusions.

When a new uncertainty arises, the Developers can decide whether it needs an immediate conversation or can wait without blocking consequential work. They should make that decision using the actual dependency, rather than a blanket rule that all questions are urgent.

Focused individual work remains useful. The aim is to reduce the cost of incompatible decisions, not to eliminate quiet time or turn every implementation task into a group exercise.

Look for changes in the work, not attendance

After trying the earlier example discussion, the team inspects what happened. Did the cancellation scenario affect the plan? Did interface and service expectations stay aligned? What important differences still surfaced late? How much effort did the discussion require?

If everyone attended but nobody changed or clarified a decision, the meeting may not have addressed a meaningful uncertainty. If two people resolved a consequential issue in a short conversation, that may be a more useful example of collaboration than a well-attended workshop.

The team should also look for displaced waiting. A practice that helps one item but constantly interrupts a specialist needed by several others may need different timing or a deliberate investment in shared capability.

Redesign one handoff

Draw the path of a recent item through the people who worked on it. Mark where a question caused work to travel backward. Identify the perspectives that could have addressed that question earlier and the concrete example they would need.

Propose one earlier interaction with a clear purpose. State what people should understand or decide by its end. Then identify what can still happen independently afterward. This keeps the proposal focused enough to try without reorganizing the entire team.

If the same person appears at every difficult handoff, add a learning objective that could gradually reduce the dependency. Make room for that learning in the plan rather than expecting it to happen invisibly.

Reflection: which part of your current handoff is a useful transfer of work, and which part is a delayed conversation that should already have happened?

Next, day 27 makes the team's completion standard more concrete.