Retrospectives That Lead to Change
A team has held twenty-six retrospectives in a year and can name three things that changed as a result. Nobody has behaved badly. The meetings ran, people were honest enough, observations were captured and written up, and the writing up is where most of them stopped. The team has learned, quite reasonably, that the hour produces a document, and it brings the effort appropriate to producing a document.
Section 5 of the PMBOK® Guide Eighth Edition includes the techniques teams use to inspect and improve how they work, and the difference between a retrospective that changes something and one that does not sits almost entirely in what happens to the output. The format is a much smaller variable than it is usually treated as.
One change, owned, done
Small enough to finish before the next one. A change that will take a quarter is a project, and it will lose every week to delivery work. A change that can be completed inside the next cycle gets completed, and the team sees it, which is the mechanism by which people start believing the meeting is real.
Owned by a name. Actions assigned to the team are assigned to nobody. One person, named in the room, who has agreed to it out loud, is the difference between an intention and a change, and it costs eight seconds to establish.
Visible when it is done. The first two minutes of the next retrospective belong to what happened to the last one. Where the answer is that it was done, the room's attention improves immediately. Where the answer is that it was not, the reason is the most useful thing that will be discussed in the hour, because the reason is usually a structural one that will block the next change too.
Getting past the safe topics
Start from evidence. Human memory of a fortnight is dominated by the last two days and by whatever was annoying, so a discussion opened with an invitation to reflect will produce the same three topics every time. Bringing something concrete, the actual dates work moved, the days items sat waiting, the number of times the environment was unavailable, moves the conversation onto things that can be examined rather than felt.
Separate what the team controls from what it must escalate. A great deal of what genuinely obstructs a team sits outside it: another team's release cycle, an approval queue, a tool the organisation mandates. Treating those as team improvement actions guarantees failure and teaches the team to stop raising them. They need a different route, to somebody with the standing to change them, and naming that route in the meeting is part of the facilitator's job.
Four months of the word communication
A team running data centre migrations for a services provider held a retrospective after every migration weekend. Across four months, the output was some version of the same observation: communication could be better, particularly with the client-side teams.
It was true and it was useless, because nobody could act on it. What changed the meeting was one piece of evidence. The delivery lead pulled the timestamps from the last six migrations and laid out how long each phase had taken against its plan, and one number stood out: the handover from the build team to the test team had taken between forty minutes and four hours, every time, against a planned fifteen minutes.
The conversation that followed was specific in a way that four months of reflection had not been. The build team finished at different times and had no way to signal readiness other than finding somebody, the test team was often in a client call, and the handover included three checks that the build team could not perform and the test team had to repeat. Two of those were within the team's gift and one was not.
The change taken that week was the smallest of the three: a shared readiness signal in the channel the whole team watched, with the three checks listed against it. It took an hour to set up. The next migration's handover took twenty-five minutes, and the one after that seventeen. The third issue, which was the client-side calls colliding with the migration window, was escalated to the account manager with the timestamps attached, and the window moved.
The word communication did not appear in the next retrospective. It had never been the problem; it had been the name the team gave to a problem it had no evidence about.
Format and frequency
Rotate the format for attention, not for diagnosis. Changing the questions occasionally keeps people from answering on autopilot, and it is worth doing a few times a year. It will not fix a meeting whose output is not being completed, and teams that keep changing format while nothing changes are treating the symptom they can see.
Match the frequency to the cycle of the work. A team delivering fortnightly can usefully inspect fortnightly. A team on a six-week release cycle probably cannot, and monthly with better preparation beats fortnightly with nothing new to say. Predictive work has the same need under other names, and a stage-end lessons session that produces one change before the next stage is doing exactly this job.
For a PMP® candidate, the useful reading is that improvement events are judged by what changes, so a scenario describing a team that inspects regularly and improves slowly is pointing at the output and not the meeting. A response that redesigns the session has adjusted the part that was working. Situations where the practice is being followed and producing nothing get close scrutiny in a structured PMP exam preparation course.
The check takes five minutes. Look back at the last three improvement sessions of any kind and write down what changed after each one. Where the honest answer is nothing, the next session is worth spending entirely on one small change with a name against it, and on why the previous three did not survive the fortnight.
Interested in going further?
A team that has learned its improvement meeting produces paper will keep attending and stop investing, and winning that back takes one completed change rather than a better agenda. Omega's PMP® Exam Preparation works through improvement as a delivery activity with owners and dates.
The inspection and improvement techniques behind this are collected in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A192: Sprint Review vs Retrospective
A178: SWOT Analysis in Project Management
A180: Facilitation Techniques for Difficult Project Conversations
A161: Expected Monetary Value Explained
A182: Multicriteria Decision Analysis Explained
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
