Scrum, day 05: where the work waits

Today's objective: trace a small change from start to usable result, identify avoidable waiting, and propose one improvement without weakening quality.

Read alongside: Scrum: A Pocket Guide, fourth edition, §1.6, “Combining Agile and Lean.” Allow roughly five minutes for this companion, plus the assigned reading. The examples and timing figures below are invented for ShiftSwap.

Follow the change through the calendar

The ShiftSwap team wants to make the approval status on a request easier to understand. Everyone agrees it is a small change. Yet the manager asks about it the following Friday, and it still has not reached the pilot café.

The developer reports that the interface took three hours. The reviewer spent one hour examining it. Checking the integrated flow took two hours, and preparing the release took another hour. Seven hours of direct work sounds reasonable. It does not explain the eight working days that elapsed between starting the change and making it usable.

The team reconstructs the journey from its work tracker and conversations. During the first few days, the change waited for a policy answer. Later it waited in a review queue, then for access to a shared test environment. Finally, it waited for someone familiar with the release process. Several waits overlapped, so adding every recorded delay would exaggerate the elapsed time.

The useful discovery is that speeding up the three hours of interface work would address only one part of the problem. The team needs to understand how work moves between those periods of active attention.

Ask what each wait protects

The Scrum Guide's discussion of theory connects Scrum with lean thinking and reducing waste. For this exercise, use that idea to examine a specific journey. The aim is to understand which activities contribute to a dependable result and which delays the team could reduce.

The approval-policy conversation establishes what the product should do. Code review may reveal a mistake. Testing the complete flow can uncover behavior that an isolated screen check misses. Calling all three “overhead” would hide their purpose.

The team separates the activity from the queue in front of it:

This is a description of this team's situation. A different team could have different reasons for the same visible wait. Removing a review because it appears late on a timeline would be a poor substitute for finding out why it is late.

Notice how starting more work changes the queue

While waiting for review, the interface developer begins another feature. The reviewer is also implementing a feature and postpones the review until after lunch. By then, a third request has arrived. Everyone can explain why their own decision seemed productive.

From the product's perspective, several partially finished changes now compete for the same attention. The developer who receives review feedback must reconstruct the earlier work. A dependency has changed in the meantime, adding another adjustment. The team has created more opportunities for delay without making any one person less diligent.

It tries a modest working agreement: before starting another item, check whether an existing item can be helped through review or verification. This does not require everyone to do every kind of work. A person might reproduce a failure, clarify an example, or help prepare the environment while a colleague handles the specialized part.

The agreement is an experiment, not a Scrum rule. Its usefulness depends on what happens to completed work, interruptions, and quality. The team should change it if it merely creates a new queue elsewhere.

Improve the system without inventing an easy villain

The shared test environment is another obstacle. The people managing it support several teams and are already overloaded. Telling them to “be more Agile” supplies neither capacity nor a clearer policy for access.

ShiftSwap's team brings a concrete example: a change needed two hours of checking but could not begin that check for two days. Together they investigate whether a smaller isolated environment could support this type of check, while retaining shared-environment verification where it is actually needed.

The release dependency needs a different response. Pairing during the next release and writing a short, tested procedure may let a second person help. Automating a reliable procedure could follow. Automating an unexplained sequence immediately would make it harder to tell which steps are necessary and which were accidental.

Each proposal addresses an observed cause. The team also considers the effort involved. A large infrastructure project would be a disproportionate response if a simple scheduling change removed most of the current delay.

Inspect more than the speed

For the next few comparable changes, the team records when work begins, when it becomes usable, and where it waits. It keeps the start and finish definitions consistent. It also records defects found after release and occasions when someone needs to work late to move an item along.

Suppose elapsed time decreases, but mistakes and after-hours work increase. That is evidence to investigate, not an uncomplicated success. The team may have transferred the cost of delivery to employees or users.

A handful of observations cannot establish a permanent improvement. They can tell the team whether its proposed change deserves another trial, a revision, or abandonment. Differences in item size and complexity should remain visible when comparing results.

Trace one piece of your own work

Choose a recently completed change. Mark its start and usable finish on a timeline. Add the periods of active work and the intervals where it awaited information, review, equipment, or a decision. If you do not know a duration, mark it as unknown instead of manufacturing precision.

Choose one wait and ask what the work was waiting for, who could help change that condition, and which quality protection must remain. Propose the smallest useful adjustment and name the evidence you will inspect afterward.

Reflection: if everyone became faster at their individual tasks tomorrow, which delay on your timeline would remain? That may be a useful place to investigate first.

The next companion examines how to use observations like these to change a decision, including when the available evidence is incomplete.