Scrum, day 51: recognizing an unsuitable approach

Today's objective: identify where a delivery approach assumes knowledge the organization does not yet possess, and propose a way to obtain useful evidence sooner.

Read alongside: Software in 30 Days, chapter 1. The publisher's contents locate the reading. This 2012 book predates the current Scrum Guide; use the current Guide for framework definitions. Allow roughly five minutes for this companion, plus selected passages from the chapter.

A complete plan can contain unanswered questions

Imagine the fictional organization behind ShiftSwap preparing a wider rollout. A project plan specifies three months of requirements, two months of implementation, and a final acceptance period. Managers sign off the requirements before the team observes how the new cafés handle unusual swaps.

The plan may coordinate some work effectively. It also assumes that important user needs and operating rules can be settled before the team encounters the situations that reveal them. If that assumption is wrong, later discoveries will be treated as exceptions to a plan that was never fully informed.

The useful diagnosis concerns the relationship between the work's uncertainty and the approach used to manage it. A method's label alone does not establish whether it fits.

Identify what is already known

Some rollout activities may be predictable. The organization may know how to create accounts, schedule a training session, or apply an established configuration. Those activities can benefit from clear coordination and repeatable steps.

Other questions remain uncertain. Will supervisors understand the new handover view? Do different qualification policies require different behavior? Will employees interpret the final state correctly under a busy shift change?

Treating all these questions as equally predictable obscures the important differences. The team should identify which assumptions require observation, experimentation, or implementation learning before a confident decision is possible.

Trace where feedback arrives

In the proposed plan, the first realistic use occurs during final acceptance. By then, many decisions may depend on the same untested assumptions. A misunderstanding about supervisor responsibility could affect the interface, stored information, messages, training, and support guidance.

The late discovery becomes expensive because the assumptions spread, not merely because the team failed to write enough documentation. More detailed documentation of the same untested interpretation would not necessarily prevent the problem.

The organization should ask when a relevant user can inspect a usable result and when the team can act on that observation. The delay between those points is a practical feature of the approach worth examining.

Distinguish legitimate coordination from false certainty

The café owner needs to coordinate staffing and training. The team cannot dismiss those needs by saying that plans change. It can offer a different kind of plan: a clear direction, smaller usable steps, explicit assumptions, and review points that inform later commitments.

For example, the organization might begin with one café's ordinary swap flow, observe real use, and refine the next step before announcing a broader rollout. Training preparations can advance where the behavior is already dependable and wait where a consequential decision remains unresolved.

This approach still requires discipline. It replaces unsupported precision with information that supports staged decisions. The organization must be willing to use the feedback, including when it challenges a favored feature or date.

Examine incentives that preserve the unsuitable approach

If managers are rewarded for keeping the original scope unchanged, they may classify useful discoveries as failures. If a supplier is paid only for delivering a fixed list, both parties may spend effort arguing about whether an observation counts as a change request.

These arrangements influence behavior. Introducing Sprint events inside the same incentives may make the work more visible without making adaptation easier. The organization needs to examine what happens when evidence suggests a better course.

The response need not begin with a complete contractual or structural redesign. It can start by identifying a specific decision that needs flexibility and agreeing how the people involved will handle new information.

Avoid an automatic cure

Recognizing a problem with the current approach does not establish that adopting Scrum will solve every difficulty. The team still needs skills, product authority, access to users, and the ability to create usable Increments.

If those conditions are missing, a new vocabulary can conceal the same sequence of handoffs. A “Sprint” devoted entirely to isolated implementation followed by a later testing phase may preserve the delayed learning pattern.

The case for change should explain the mechanism expected to improve the work. Shorter feedback opportunities, transparent progress, and real authority to adapt are more concrete than a promise that a named method will automatically make everything faster.

Locate one premature commitment

Choose a plan from your own work. Identify an important assumption treated as settled before the organization has evidence for it. Describe the later work that depends on that assumption and the consequence if it proves wrong.

Propose an earlier usable result or bounded investigation that could inform the decision. Identify which coordination commitments can remain stable and which would benefit from waiting for evidence.

Reflection: where does your current approach require people to predict something they could instead learn in time to make a better decision? That is a useful starting point for evaluating a change.

Next, day 52 turns that diagnosis into a testable case for improvement.