12 Days of Agile Principles! #AgilePrinciple 12
Welcome to the final post in the 12 Days of Agile Principles series. I hope you’ve enjoyed following along to arrive at our finale and it’s a fantastic principle to wrap on.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
Did I hear someone say Retrospective? Our friend The Retro is the practice of looking back in order to move forward. If you take nothing else from Agile practices, a Retrospective will help any team improve how they are working. You don’t need to have user stories, iteration planning or continuous delivery completely nailed in order to run a Retro for a team.
Retros are a way of enabling a team to improve themselves, at a sustainable pace, I recommend you don’t try and fix the whole organisation in the first iteration! Retros provide opportunities to connect with each other whilst maintaining a respectable distance from the content your team is working on, we all get rather caught up in the content of our day to day work, and this precludes us from constructive analysis of how we could process work more effectively.
How are Retros different from a project PIR (post implementation review)? Not so wildly different, but my experience of PIRs hasn’t always been a positive one. I’ve found PIRs tend to get pushed back a long time after project conclusion, sometimes the team members have dispersed as everyone has needed a good long break after a project, so the immediacy of analysing what happened can be watered down, let alone the practicality of getting everyone back together. If key people are no longer around is it really an accurate picture of events that you are looking at?
I’ve also been in PIRs where the project has gone badly, the team members may have suffered stress and have an axe to grind, they may choose the PIR as an opportunity to do so. This can be cathartic but since the project is over, the opportunity for learning from that is diminished.
So to contrast, in Retros we try and do process improvement continuously, rather than after a large implementation at the end of a project, that’s why the principle states “At regular intervals..” in this way we have many more opportunities to fix things along the way. It’s fairly easy to slot one in at the end of every iteration, the logical time to reflect on how things are going.
Retros can get repetitive, as they occur so regularly, and it’s easy to fall into the same style of retro again and again. The best facilitators of team activities I know change up the Retros and try different approaches and techniques, you can also invite someone external to the team to run your Retro to get a different flavour and objective opinion on how to improve.
I could summarise this topic by saying ‘Retros are powerful, you should try them’ but it wouldn’t convey how fundamental I believe this one aspect of Agile work is to high team performance. I was once polled with the question ‘If you could do only one Agile thing with a team or project, which would you do?’ Some people answered ‘Daily Stand Up - a great way to get everyone on the same page right now’. I agree the Stand Up is highly useful, but the Retrospective has one other endearing side effect that means it cannot be beaten in any Agilista's toolkit. It is the occasion where you can drive change. Think about it, at Retro we can make the suggestion: "How about we do a Daily Stand Up each day?” By using the Retro, slowly but surely you can start to introduce more of the tools and techniques we know work in Agile teams, even if you change one or two things per iteration you are on the right path. The Retro is the crucial key that can unlock agility in any team, department or organisation. The bravest Agilists can spark a whole Agile transformation off the back of the Retro.
Well we are now at the end of our 12 Days of Agile Principles series, we hope you have enjoyed following along daily, and please feel free to continue the conversation with us at @TheReBootCo.