Scrum, day 43: growing capability

Today's objective: plan a learning investment that reduces a recurring dependency and produces observable capability rather than attendance alone.

Read alongside: Mastering Professional Scrum, chapter 6, focusing on individual and team capabilities. Allow roughly five minutes for this companion, plus the book section.

A holiday reveals the dependency

The fictional ShiftSwap team plans a change involving delayed messages. Only one Developer is comfortable tracing a message through the system, and that colleague will soon be away. The team can postpone the change, ask for work to be completed before the absence, or invest in another person's ability to handle the relevant behavior.

Each option has a cost. Repeatedly rearranging work around one person's availability may preserve immediate output while leaving the team fragile. Training everybody on everything would be expensive and unfocused.

The useful question is which capability would most improve the team's ability to complete and maintain the product. The answer should connect learning with a recurring need in the work.

Define a capability in observable terms

“Learn the message service” is broad. The team narrows it: another Developer should be able to trace a message to the request event that produced it, identify whether its state is outdated, and make a small behavior change with appropriate checks and review.

This description gives the learning a practical boundary. It does not require the colleague to become the system's leading expert immediately. It identifies a useful level of independence for ordinary work.

The experienced Developer helps identify prerequisites, including access, local setup, and knowledge of request states. A training session that ignores those prerequisites may produce familiarity with a diagram without enabling anyone to perform the work.

Learn through a relevant piece of work

The team chooses a modest message change that already matters to the product. The experienced colleague and learner first explain the intended behavior and relevant examples together. They then trace the current implementation and make the change.

The learner should actively navigate and explain decisions, rather than watch an expert type quickly. Questions reveal assumptions that the expert may no longer notice. The pair can improve a confusing setup step or record a useful diagnostic path as they go.

The work still needs to meet the product's quality standard. Learning is not a reason to bypass review or verification. The plan should account for the additional time and the expert's attention.

Check understanding through a different example

Repeating the exact steps demonstrated can show memory without establishing transferable understanding. After the paired change, the colleague tries a related but different sequence, such as a message arriving after cancellation rather than after approval.

They explain what they expect, where they would inspect the behavior, and how they would verify a change. The experienced Developer remains available to review and help, but avoids taking over at the first hesitation.

The team can then distinguish what the learner can do independently, what still needs support, and what remains outside the agreed learning scope. This makes the result more useful than a binary “trained” label.

Make the investment visible in planning

Pairing may reduce the amount of unrelated work the two people can start that day. The team should discuss that trade-off openly. Hiding learning in spare time makes it vulnerable to every urgent request and encourages unrealistic forecasts.

Elena can help compare the investment with upcoming product needs. If several likely changes depend on message behavior, the benefit may be substantial. If the component is about to be retired, a smaller transfer of operational knowledge may be sufficient.

The decision belongs in a product context. Capability development supports future options, quality, and resilience; those benefits should be explained rather than assumed to justify any training proposal automatically.

Preserve the expert's own growth

The experienced colleague should not become a permanent bottleneck for every learning activity. They may also need opportunities to develop new skills and work without constant interruption.

The team can agree on focused pairing time, a useful record of common questions, and gradual transfer of ordinary tasks. As another person becomes capable, both can contribute to helping the next colleague where that would be worthwhile.

Knowledge sharing should not be framed as making expertise unnecessary. Deep expertise remains valuable. The aim is to make ordinary delivery less dependent on a single person's constant availability while preserving a route to specialist judgment for harder problems.

Inspect the effect on the team

After the holiday, ShiftSwap examines what happened. Could the team investigate the relevant issue without waiting? Did the new capability improve the quality of discussions? Did another hidden dependency, such as environment access, still prevent progress?

A successful training session may not resolve the whole system constraint. That is useful evidence for the next improvement. The team can retain what it learned while addressing the remaining access or coordination problem.

The Scrum.org discussion of self-managing teams connects autonomy with the skills needed to act. For ShiftSwap, growing capability makes an existing decision boundary more usable in practice.

Plan one learning outcome

Choose a recurring task that waits for one person. Define a modest capability someone else could develop, the relevant work through which they could learn, and the support needed to keep the result dependable.

Describe a different example that would demonstrate understanding. Include the learning effort in the plan and identify the future work likely to benefit. Set a point to inspect whether the dependency has actually become smaller.

Reflection: what evidence would distinguish someone who attended a session from someone who can now help the team finish? Use that distinction to shape the learning plan.

Next, day 44 examines how a Scrum Master's intervention can support lasting improvement.