Project Delivery
Use retrospectives to change a working agreement
A retrospective should produce a change people can try, not another list of frustrations. Use observable events to choose one working agreement, define a small experiment, and review whether the new behavior helped.
Teams can discuss the same delivery frustration repeatedly without changing how they work. A retrospective becomes useful when an observation leads to a specific working agreement that people can test. The agreement should describe an action under a clear condition, not a wish such as “communicate better.” Start with one recurring coordination problem that the team can actually influence.
Move from a complaint to an observable event
Ask what happened, when the handoff failed, and what information or decision was missing. Separate the event from assumptions about a colleague’s intentions. A useful example might be that a review request arrived after the reviewer’s working hours and lacked the tested build, not that someone was unhelpful.
The Scrum Guide defines the Sprint Retrospective as a way to plan improvements in quality and effectiveness.[1] It also includes interactions, processes, tools, and the Definition of Done within inspection.[1] Our recommendation is to turn that inspection into a small behavior change rather than an unlimited list of actions.
Write an agreement that can be tried
Describe the trigger, expected action, responsible role, and exception route. Agree on where the rule lives and when the team will review it. Assign someone to help the experiment happen, but do not make that person solely responsible for everybody else’s behavior.
Test the proposal against these questions before adopting it.
- Does the agreement address an event the team actually observed?
- Can people tell when the new behavior is required?
- Is the expected action within the team’s authority?
- What evidence would show improvement or added friction?
- When will the team keep, adjust, or stop the experiment?
Hypothetical example: a late review handoff
In a hypothetical document service, reviewers repeatedly receive changes without a usable preview. The team agrees that a review request must include a preview link, the intended behavior, and the checks already completed. If the preview is unavailable, the requester explicitly asks for design feedback rather than implementation approval.
At the next retrospective, the team inspects a sample of requests and asks whether reviewers could start without clarification. The group also checks whether preparing previews created avoidable delay. The experiment may need adjustment if a small text correction now requires the same preparation as a complex workflow change.
Keep learning separate from blame
A working agreement cannot solve missing authority, chronic capacity constraints, or a dependency controlled by another organization. Record those limits and escalate them to the right owner. Do not present a local communication rule as a solution to a structural problem.
Too many agreements can become rules people ignore. Retire obsolete rules and keep the active set easy to find. Choose one experiment after the next retrospective, explain how it changes tomorrow’s work, and reserve time to inspect the result. The meeting is not complete merely because the action list has an owner.
