It is no secret feedback is important. In this world of agile and devops and continuous development it is imperative to pause and reflect. Easy to get caught up in the excitement, noise and hurry. Easy to want to keep going forward without looking back.
Feedback is important. Feedback as a collective effort is important.
Retrospective is a key ceremony in Agile. Rightly so. No matter how or what way you perform, it is imperative you do it after every release or after every 4 sprints or 2. But stick to it, no matter what the frequency you choose.
If you are starting, a google on ‘Agile Retrospective’ will give you a plethora of formats that you can use. Pick one and experiment, your team will hit a sweet spot . Continue using it.
Do not get disheartened if you do not see participation in the beginning. It is natural for people to feel their opinion doesn’t matter, feel scared to voice it, feel their feedback isn’t relevant. Let your team know it isn’t to find faults in what they did or how they did, but to collectively figure out what can we do better to make it easier for ourselves, what did we do that we should continue doing because it really aided the team, what should we completely stop doing because it is causing hindrances and blockers.
It is the operational counterpart of Retrospective. It is essentially that — a retrospective after an incident has occurred.
It is not root cause analysis and it should always be blameless. The idea is to reflect on what happened, how did we react — reactive — proactive, how did we handle it and what have we learned from it.
There are multiple ways that teams run a postmortem. I have tried a few different ways with teams as well. Few key criteria have stood out that needs to be addressed :
- Statistics: Numbers- the impact in numbers. Those numbers tell the picture of the end user impact, the duration and the blast radius.
- MTTD (Mean Time to Detect): From the above statistics and timeline, we determine when the impact started to occur, when did we respond to the event. The absolute crucial here is was the detection proactive or reactive.
- MTTR (Mean Time to Restore): From the detection of the event to bypassing the event is the time taken to restore.
- Residual fixes: This is linked to your blast radius. Yes, we bypassed the incident but were post incident issues that maybe affected other systems, data clean-ups.
Some questions that we can ask to understand gaps in MTTD and MTTR:
Irrespective of the format used for a PIR/Postmortem, if we use these 3 as the foundation we will be able to shed light on the gaps, improvements and strengths as a team.
No matter which feedback loop we are using, which format we are following : Consistency is key in feedback ceremonies. So is actions out of them. Consistency with action is how we build confidence in the ceremony.
Make sure we have captured actions and we track the status and the team is aware.
Do not get wound up in logistics, it can come later, it can evolve.
Be consistent | Take Actions.