Scrum, day 56: building lasting capability

Today's objective: identify what the organization must retain after a pilot so it can continue delivering, operating, and improving the product without exceptional support.

Read alongside: Software in 30 Days, chapter 7, focusing on capabilities you want to develop beyond the initial trial. Allow roughly five minutes for this companion, plus selected passages from the chapter.

Success can depend on conditions that will disappear

The fictional ShiftSwap pilot produces a useful result. Managers can handle the supported swaps, and the team has adapted several decisions using feedback. During the pilot, an experienced coach was readily available, an operations specialist gave unusual priority to requests, and the sponsor resolved conflicts immediately.

The organization now wants to declare the capability established. Before doing so, it should ask what will happen when those exceptional arrangements end.

A successful episode and a lasting ability are related but different. The organization needs to retain the knowledge, authority, relationships, and technical conditions that made the useful result possible.

Identify what the pilot relied on

The team lists the decisions and activities that repeatedly required special help. The coach facilitated difficult product conversations. The operations specialist diagnosed environment failures. The sponsor clarified priorities when other managers made competing requests.

Some support should remain available because it serves a continuing organizational need. Some can become ordinary team capability. Some may reveal a structural problem that should be addressed rather than transferred to another heroic individual.

This inventory is more useful than asking whether everyone has completed Scrum training. Training can support understanding, but it does not by itself establish the ability to handle the product's actual work.

Transfer capability through practice

If the coach has been facilitating difficult discussions, a team member can gradually take a larger role while receiving feedback. If the operations specialist holds a recurring diagnostic skill, a Developer can learn it through a relevant change and demonstrate it on a different example.

The transfer should include judgment, not only steps. People need to understand when a technique helps, what evidence to inspect, and when to seek additional expertise. A checklist can preserve useful knowledge while still requiring interpretation.

The organization should make time for this learning. Expecting capability to transfer automatically while everyone remains fully occupied with new scope makes the desired transition less credible.

Preserve the product's operating knowledge

ShiftSwap needs a dependable account of supported behavior, important quality expectations, deployment and recovery procedures, and routes for user feedback. The information should be maintained where the people doing the work can find and use it.

The team does not need a comprehensive manual written for an imaginary future reader. It needs enough shared knowledge to answer recurring questions and avoid unnecessary dependence on memory.

A useful check is to ask someone who did not create a change to explain how they would investigate a plausible problem. Their difficulties can reveal missing context, inaccessible information, or an operational capability that still exists only in one person's head.

Make product authority durable

During the pilot, Elena's decisions may have been respected because the sponsor watched closely. Afterward, other managers may return to issuing separate instructions directly to Developers.

The organization needs a stable agreement about product decisions and competing priorities. That includes a route for disagreement and a way to revisit the product direction using evidence. Authority that exists only when a particular sponsor attends a meeting is fragile.

Durability does not mean decisions become permanent. It means the organization can adapt them through an understandable process without dissolving the team's focus whenever pressure increases.

Budget for maintaining the ability to change

A product that continues serving users needs ongoing attention to quality, operation, learning, and technical constraints. Funding only new visible features can gradually consume the capability that made the pilot successful.

The team should explain these investments through their product consequences. Reliable verification, shared knowledge, and manageable internal design preserve future choices and reduce recurring dependencies.

The organization can inspect whether those investments help rather than treating them as either automatically justified or permanently optional. A lasting capability requires continued judgment, not a one-time purchase of a method or tool.

Test independence without withdrawing support abruptly

The organization can gradually reduce exceptional assistance and observe what happens. The team might lead the next stakeholder discussion, handle an ordinary operational question, or plan a change with the coach available only for consultation.

This creates evidence about what has become dependable and what still needs support. Abruptly removing all help can create avoidable failure without providing a clear diagnosis.

The test should also examine the wider system. If the team acts effectively but a shared approval queue remains unpredictable, the remaining need is organizational rather than a failure of individual learning.

Define what should remain

List three capabilities the pilot depended on. For each, decide whether it should live within the team, remain available through a dependable service, or require an organizational change.

Describe how the capability will be maintained and how someone could demonstrate it in ordinary work. Identify one temporary support arrangement that should be made explicit before the pilot ends.

Reflection: if the most helpful person from the pilot were unavailable next month, which part of the organization's apparent capability would disappear with them?

Next, day 57 examines how to carry learning into a wider organizational setting.