One of the benefits of working in our Bangalore office the unique concentration of people in one location on a daily basis, resulting with some very interesting conversations. On Tuesday I hosted a retrospective facilitators meetup with a pretty open agenda. We had people from all parts of the organisation. I was asked by one person who couldn’t attend to write up the things we covered and some of the topics.
I felt we had some nice discussions, and thankfully not all of it coming from one direction (i.e. me). Here’s a quick recap of some of the topics and things we covered. I’m sure I’ve missed plenty of other side conversations (it was only an hour too!), so if you were there and you’re reading this, remind me via email or a comment here. Next time I’ll try to write the topics down so we capture some of the discussions. Here’s at least what my (terrible) memory holds:
Is it okay to give feedback to individuals during a retrospective?
Asked from the context of trying to give people feedback that strengthens confidence, I think many people in the room felt it would be appropriate. Others gave examples of these comments coming in from things that went well as well as describing the Offer Appreciations exercise (see the Project Retrospectives or Agile Retrospectives book). I’ve also seen these work quiet well.
What goes into a retrospective
We covered this pretty quickly since the room was a mix of experienced and inexperienced participants/facilitators. I quickly ran through a format that is most used:
1. Set the scene – Make it clear to participants why they’re there and what you’re trying to do.
2. Create safety – Ensure that all participants are going to participate
3. Gather feedback – Use some activity to generate some data and insights.
4. Actions – As a group, decide upon results or things to action upon
What happens if the same things keep coming up?
Part of it indicates to me a process smell that I’ve written about before. Some useful techniques to address this include Bas’ Plan of Action pattern. I encourage everyone to also focus on creating actions that fit the SMART (Specific, Measurable, Achievable, Relevant, Time boxed) criteria and ensure that you celebrate small successes so everyone feels like progress is occurring. I also tried emphasising that at least retrospectives are still bringing visibility to the issues, and that it sounds like the actions or things happening around it need to be addressed, not to stop running tools that give you feedback.
A common exercise people in Thoughtworks use is What Went Well/What Went Less Well/Puzzles. I’ve had conversations with some people (not in this particular meeting) who believe that unless you’re doing this one, then you’re not doing Retrospectives. I showed a couple of alternative exercise ones including the Retrospective Starfish, the Art Gallery one, the Forcefield one (with its speedboat/air balloon variations).
What’s the perfect size of a retrospective
I honestly didn’t have an answer for this one other than “it depends”. The group talked about as you increase the number of people, the more time you need and individuals end up participating. We also side lined for a while on what happens if you keep Prioritising with Dots and not really getting the smaller issues out. Others came up with sometimes not running Prioritising with Dots and getting everyone to brainstorm action items that the team simply just took on automatically. Quick wins become reality in a flash this way.
Retrospectives are a process smell
I can’t remember who, but someone talked about having retrospectives themselves are a smell, in that an “ideal” team should be self healing and fixing problems continuously without needing them. In one way, I agreed with him as did several other people. On the other hand, in my experience sometimes even a well performing team needs that separate time to reflect on things independently of the other things they’re focused on doing day-to-day. One person chimed in saying that in a way, the issues coming out the retrospectives gave them confidence that they were already dealing with the issues (as in, there wasn’t any surprises). I also tried to explain several other side benefits such as a common place to share a story that might be missed, a place where people are safer giving some feedback, and a place where everyone has input into agreeing to a solution.