Agile retrospectives: tips and tricks

When practicing any of the agile software development methodologies – despite an inherent flexibility of those – it is rather important at least to start with a “by the book” approach. This means that when you roll out your agile processes, you try to implement each and every aspect of it, even if that seems useless or not required in your particular situation. Only then you can see from experience that something needs to be tailored – and a retrospective is a powerful tool to facilitate that kind of team learning.

Although seemingly simple, the retrospective exercise can turn out to be tricky, especially if you intend to use it to its full potential. Of course, the way you hold a sprint, iteration, phase or project retrospective very much depends on the specifics of the project, team culture and a whole bunch of factors imposed by the surrounding organization, in the context of which you operate. However, there are some focal points that one would want to take into consideration when using a retrospective as a collective learning tool, and I’ll share some of these tips and tricks here:

• Make retrospective constant and periodic. It should become a team habit, an integral part of the routine; sometimes the situation in a project becomes tense, everyone is busy, there seems to be not enough time for a retrospective – still, it is important to end each logical iteration of a project with a pause and an opportunity to look back. If need be, make it shorter – but don’t drop it altogether!

• Ensure that the team is informed about what will happen. Even before the very first retrospective event, make sure that everyone involved clearly understands, what will happen. The key here is to communicate that a retrospective is the time and place to speak up and be unafraid. If this part isn’t done right, one would experience a bunch of very unproductive retrospectives, where only the most well-known issues are ever brought up and many of the team members being silent completely.

• Come prepared. Throughout the iteration, be sure to write down any idea that you would want to discuss on the retrospective later on; the point is that even with a two week sprint there’s plenty of opportunities to forget what has been going on – especially keeping in mind that our brains aren’t that perfect at remembering things. So if you keep a log of points to bring up during the upcoming retrospective, you increase the chances of it being time well spent.

• Set the mood. Regardless of whether you are leading a retrospective event or if you are just one of the more experienced participants – help others by showing an example, be the first one to share your thoughts and suggestions, reference other team members, thank them for their work well done – and pass the “talking stick” over. Having a good example and being recognized for their efforts team members will follow and thus you will end up with a valuable learning experience.

• Provide extra hints. During the retrospective, a visual aid may help get things going in the right direction. It can be a couple of slides summarizing team’s progress during the most recent iteration, or a slide that lists key events of the last sprint or two – perhaps, a simple list of areas to analyze can be sufficient, too. Either way, it is always easier to start with something – as opposed to starting from the scratch, even in the unlikely event that everyone came well prepared for the event.

• Follow up! The most discouraging thing about retrospectives is the lack of action. If team members see that issues are brought up over and over again, but not acknowledged and – most importantly – effectively acted upon, they would stop seeing the value in a retrospective, quite simply because there are no value in holding that kind of event. First of all, everything that is discussed during a retrospective should be acknowledged – just as with any communication; better yet if everything is written down and then communicated across the team. Second, actions improving the situation need to take place. And – last, but most certainly not least – these actions should be effective, eliminating obstacles and improving the overall situation in which the team performs. Seeing this kind of response encourages team to take retrospectives seriously, see those as a useful tool and not a useless burden in the process.

• Advertise your retrospectives outside of the team. It can be as simple as mentioning it, in relation to an issue or a decision; remember that you (or someone else in the team) have to follow up, which often means talking to senior management or other teams outside of the project team. One way is that you communicate only what’s needed from them; another is adding a short comment that the team came up with this during the retrospective last Friday. In the latter case, your counterpart will understand that there’s a team consensus behind your request, which will inevitably add weight to it. Besides, this kind of reference to retrospective as the source of a good initiative or change would also add credibility to the process within the team as well.

Obviously, the seven points listed above do not cover all the aspects of running an effective retrospective process, but at the very least this is something to think about; for deeper understanding of what a retrospective can do for the team and how to run them – check out “Project Retrospectives: A Handbook for Team Reviews” by Norman Kerth. The book might seem a bit too fundamental to some – but remember that the author is focusing on project retrospectives, so to use his advice on sprint or iteration level you will have to scale it down a bit. Regardless, you will find a bunch of interesting thoughts and practical recipes there, so give it a try! Besides, it has recently been translated to Russian.

Need assistance with your retrospective process? Don’t hesitate to contact us with any questions or comments!