The same problem is back in your retrospective: turn the lesson into a change
“We need clearer handovers.”
The action looked reasonable last month. It is back on the retrospective board this month, alongside another late report and another hurried conversation about who was waiting for what.
The team has noticed the problem. It has even written down a lesson. What remains unclear is which part of the work will change and how anyone will know whether that change helped.
The UK Defence connection
The Ministry of Defence’s 2017 Defence Knowledge Strategy discusses a familiar organisational problem: identifying lessons without reliably applying them. It supports evidence-based reviewing and feeding experience back into processes and guidance.
That historical document offers a useful principle for tech teams. A lesson needs to affect how work is done, then be checked in use. The small record below is my suggested adaptation for a retrospective; it is not an official Defence template or a claim about current mandatory policy.
A practical tech example
For example, a data team prepares a monthly service report using files from several operational teams. The report has been delayed more than once. People remember chasing spreadsheets, but the retrospective action remains “improve communication”.
Looking at the latest cycle reveals a more specific issue. One input arrived with different column names, and nobody knew who could confirm the correct mapping. Another file arrived after the team had begun combining the data.
The team now has two observable problems to investigate. Calling both of them “poor communication” would hide the decisions needed to prevent a repeat.
How to put it into practice
Separate observation from explanation
Purpose: Give the team something it can verify.
Record what happened using the evidence available: which input was late, which format differed and where work stopped. A missing timestamp should stay unknown rather than become an estimate presented as fact.
Then explore explanations with the people doing the work. Perhaps the expected format was only described in an old email. Perhaps the contributor received the request too late. Avoid deciding that someone needs more reminders before checking whether the handover was workable.
Choose a change within reach
Purpose: Replace the broad intention with a specific adjustment.
For the column-name issue, the team might agree a small input specification showing required fields, accepted names and the person who resolves uncertainty. Test it with a contributor before treating it as finished.
The late file needs its own discussion about the reporting sequence, source availability and cut-off. If the information is not available earlier, a stricter deadline will not create it. The report owner may need to change the reporting window or explain a limitation to its readers.
Give the action ownership and capacity
Purpose: Make implementation part of planned work.
Name who can coordinate the change and who needs to agree it. For the input specification, that might be the data lead working with the operational contributor. Confirm what work will be deferred if preparing and testing it takes time.
Keep unresolved dependencies visible. If another team cannot change its export before the next cycle, decide how the mismatch will be handled in the meantime and who has capacity for that work. An action can be worthwhile and still need a realistic place in the plan.
Check implementation and usefulness separately
Purpose: Distinguish completing a task from improving the outcome.
First check whether the input specification exists, has been agreed and can be found by the people who need it. Then inspect its use during the next reporting cycle.
Did contributors understand the fields? Did the team still need clarification? Did a different issue cause the delay? Use the answers to keep, adjust or replace the change. One smooth cycle is encouraging evidence, not proof that every future handover will work. Agree whether a later check is needed before closing the action.
A record you can use
What to try next
In your next retrospective, choose one recurring issue and follow it through this record. Keep the evidence and the action close enough that somebody joining later can understand why the change exists.
If nothing has changed in the work, keep the lesson open or record an explicit decision to accept the limitation. A completed meeting should not make an unresolved problem disappear from view.
Source: UK Ministry of Defence, Defence Knowledge Strategy, version 1.0 (2017). The tech examples and working tools are Coded Female adaptations.
You May Also Like
Product Strategy: Dissecting Apple’s Winning Product Strategy
Town hall meetings for companies: a practical guide for tech teams
