4 things to NEVER DO in your* Retrospective meetings
Retrospective meetings are the heart of an agile team. It is a clear indicator of what the team stands for. The key principles of ‘transparency’, ‘We over I’ and ‘self-organized team’ are put to test in this little meeting that happens at the end of every sprint. I have seen the best and worst of these meetings, and this prompts me to think about what retrospective meetings should not be about.
*by your I mean the ‘Scrum Master’s’
Do not make it:
a ‘Blame Game Arena’
“Everyone loves a witch hunt as long as it’s someone else’s witch being hunted.”
― Walter Kirn
Yes I can never over-emphasize how much of an energy sapper this is! In most teams this starts as normal issue reporting. And then comes the day when one team member takes it too personally. Slowly the team gets divided into two or more camps. And that is it. There will be no end to the drama of the camps in trying to defend their point or let the hell loose on the opposition camps. Trust me once this starts it rages like forest-fire. Within a matter of 1–2 sprints your retrospective meetings will no longer be fruitful. Nip the vice in the bud. The very first instance the negativity is introduced, talk to the people involved. If required call for a 3–way meeting and polish your conflict resolving capabilities before you enter into this one. Open communication is the mantra. Reason with both the sides and come to a consensus on ‘What Next?’ The emphasis here is not on ‘Who’ went wrong, but ‘What’ went wrong and how do we fix it?
The team should agree to the Retrospective Prime Directive, before participating in it:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Too generic with no action items
“I think there needs to be a meeting to set an agenda for more meetings about meetings.”
― Jonah Goldberg
A meeting without an agenda is worse than a bull in a china shop. It can get into topics of little or no relevance, move into an elongated discussion on one of the many issues or may end up not being a Retrospective itself. Make sure that every participant is well aware of the objective. If there have been a few points that can serve as appetizers to start the conversation, you may include them in your Meeting agenda already. This could be a good start point for the conversations to start, and then you as the moderator of the meeting would definitely have the steering in your control. Make the most of it. Turn in the exact direction you need. Get into the root cause of issues and do no let the good work go unnoticed.
Another point equally important is to make a note of the action items. Detail it into tangible tasks and assign them to members from the team. This helps in having a collective accountability towards betterment. Also make sure that the next Retrospective Meeting starts with a look on these action items first. There is no point in having a detailed discussion, action items and assignee unless there is actual work done on it. Repeated offenders (issues not people) need a re-look. There would definitely be something wrong in the problem solving approach if the issue continues to exist. Do not hesitate to put forward the issue to the team and seek help in finding better ways to solve it. Remember it is a self-organized team, the issues are not just yours to solve.
Make it dull-drab & boring :|
No one wants their meeting to be boring, do they? But invariably when you want to get people to talk, it is not as easy as it seems. There are plenty of ideas available online to get the team to open up and to spruce up the Retro meeting. The Retrospective Handbook is one such excellent resource. You can invest the first 10 minutes in a small game, if that is what it takes to warm up. This investment of 10 minutes has a great return in terms of the conversations that it leads to. A few that I have tried include the “Activity Box” — my version of the one suggested in the book. I made a note of all the activities that the team usually takes up during the course of the Sprint eg: Coding, testing, KT, handover, interaction with other teams, customer issues, consultation etc. These were put into a box, and each team member had to randomly pick an issue. They might not have worked on it, but this was a good prompt for the team to think if all was well about that activity and if there is anything that would make it any better. Our meeting went on for a good 1.5 hours with every activity coming under the scanner. We all walked out of the meeting room convinced that things were fine, and we have an immense scope to make it better.
Allow laptops into this meeting
I may sound like your college professor who insisted on ‘Lowering your laptop screens’ as she spoke. But yes, one laptop into the room , and then there is a whole flock of them. We need to talk face to face. An hour away from the laptop will not steal into the productivity of the team. Make it very clear that the only person presenting is allowed to bring laptops into the room. Each participant needs to be completely involved in the conversations. But they were talking about the database issue, that I had nothing to do. Fair enough, but may be you have a point that they might have missed being in the center of the issue. And there could be other learning for you to take away for your own area of responsibility.
Well all said and done, once you get the first few retro’s right the spirit would get embedded into the team for sure. Unless you see them drift away you may not even need additional games or ideas to get them to participate wholeheartedly.
How does you Retrospective Meeting look like? Have you faced similar challenges? Have you tried newer ways of making it engaging? Would love to learn from your experience.