What worked?

So you've made it to the next release, it wasn't pretty but you got the job done. But the work never ends and there is always another feature, another use case, another impatient stakeholder who thought their 'thing' would be done by now. So, off we go again... but wait a sec! Wouldn't it be a good idea to take a moment to review how well we did? "Pah! No time for that". "Let's just keep going - we are behind already". "Please let's not rake all that up again, it'll only cause trouble". "We understand it now, what's the point?"

Product professionals know it's a good idea to pause and review how well things have gone. In projects these look-backs are often called 'lessons learned reports' but in agile terminology the term retrospective is used. Personally I prefer the latter, as its a neutral term, focusing on objectively reviewing what happened (both what went well and what could have gone better) and not implying blame or fault. Yet these reviews are often overlooked. In my experience this is another example of the important, but not urgent, trade-off. Looking back is usually an investment for the long term - it's a discipline that builds long term capability and resilience. Like any practice it needs to embed as a habit; so it becomes just 'the way things are done around here'.

Yet running a retrospective isn't easy. Particularly with a new team, or one operating in a non-collaborative environment, it can easily turn into a pass-the-buck session and do more harm than good. It's important to remember to focus on what went well and to publicly acknowledge when a particular individual or team excelled (and why they excelled). An open display of vulnerability from the person running the process can often get things started with the right tone.

Retrospectives can be a great opportunity to explore the root cause behind any issues you have encountered. The iterative '5 whys' technique (https://en.wikipedia.org/wiki/Five_whys) can be helpful in moving beyond the symptoms to the root cause(s), but be careful not to turn it into an interrogation of a single individual. Very often the same underlying challenges emerge: time pressure, incorrect assumptions, missing dependencies and good old-fashioned miscommunication. Taking the time to jot these down builds a powerful body of evidence to support longer-term investment in the team, for example additional training, better collaboration facilities and more informed, facts-based, estimating. It can also accelerate a new team member getting up to speed by explaining the past challenges and shared experiences that mould the culture and shape the sensitivities of colleagues.

Having senior individuals involved in an open session may discourage individuals from being open about where things could have been better, and may engender a defensive atmosphere; yet it's important to get their perspective (perhaps in private) and encourage them to consider what they could have done differently to support the team and create the right conditions for success.

As with all review initiatives, it's easier to propose extra things to do: more controls; more testing; more review. Individually these can be warranted but over time this can become a one-way rachet of bureaucracy - a rule-book of 'must do' overheads designed to mitigate risks that are no longer present. Be careful you aren't fighting yesterday's war. For every new repetitive practice the team agree to do encourage them to identify tasks of roughly equal magnitude that are no longer needed. If a new practice needs up-front investment to get going make sure to acknowledge this as a formal task in the backlog - a retrospective isn't a means to covertly squeeze more work in.

Lastly, of course, following through on commitments and holding each other accountable is what makes these practices stick. So at the next session take time to review the take-aways from your last retrospective - did we do what we said? did it make things better? Real change in ways of working takes time so apply the same incremental principles to your own practices as you do to the product you are building. Then both will succeed together.

(All views in this article are my own)