Agile Retrospectives help teams to continuously improve to become better in what they do. As they are a learning experience for the team the atmosphere in a retrospective meeting is usually positive. But when there have been major problems in an iteration, maybe even conflicts between team members, then team morale can be low and negativism can occur in the retrospective meeting. This is the story of how a reader of our book on Valuable Agile Retrospectives dealt with negative issues in his retrospective.
Matt DuFeu described in Scrum Retrospective Experience – ESVP, Sailboat and Constellation how he combined several exercises from our book to design a valuable retrospective. I reacted on his blog post and we had a fruitful discussion on how he did the retrospective and the benefits that he got out of it.
Please feel free to ask your agile retrospective question, happy to answer them and help you to get benefits from doing them 🙂
Combining exercises in an Agile Retrospective
Matt started the retrospective with an explorer-shopper-vacationer-prisoner (ESVP) exercise. The results of this exercise told him that there might be some serious issues in the team. He decided to continue the retrospective doing a Sailboat (an exercise from our book Getting Value out of Agile Retrospectives) to find out what is slowing the team down and what helps them to reach their objectives:
To gather data from the team, I used the Sailboat Retrospective technique. I’m pleased to say it resulted in a lot of post-it notes, so the team were clearly engaged, but I’m worried/disappointed about the number of negative things that were noted.
If a sailboat exercise (or any other retrospective exercise) reveals negative things, that is actually a good thing. The intention of retrospectives is to reflect and learn. A retrospective is neutral practice which helps a team to take some distance and see what is happening. They may see positive or negative things. Usually both kinds will come up, iterations are never 100% negative or positive.
It is important how the team deals with the issues that come up in the retrospective.
The team talked through each post-it on the sailboat, discussing in-depth the reason for it being there. I used this time to try and see how strongly the team felt about the issue, if they all agreed and how big an issue it was.
Matt did a Constellation exercise (also described in our book) to visualize how team members felt on some of the important issues. This exercise got things moving, literally:
Not only did this get everyone back on their feet and engaged (there was a definite increase in discussion afterwards) but is a really clear indicator of the teams feeling.
A constellation is a great exercise to get people engaged. They have to stand up and move. By posing questions and asking people to change their position, the system reveals itself.
They finished the retrospective by defining improvement actions which the team would do in the next iteration:
We then took each one from most important to least important and came up with some actions to hopefully resolve the issues before the next retrospective in 2 weeks.
I asked Matt how the constellation exercise helped the team to get insight into the issue and explore their feelings. His answer was:
I probably shouldn’t share the technical issues, but I feel safe in revealing “knowledge silos” was one of the things we used constellation on. It instantly showed a “marmite” mentality in the team, some thought it was really important and others barely considered it an issue. That lead to some great conversations and I think we’re all now in agreement about how important it is that we do something about it.
Evaluating the Retrospective
Was the retrospective that Matt did valuable? The team got actions out of it that they will do in the next iteration. Time will tell if it are good actions, but the fact that the team came to a decision to act is good.
I like it how Matt did a personal retrospectives and shared his learnings on his blog. He questioned his facilitation by asking if he hadn’t been leading the team too much during insight generation? Finding out how much or how little to lead can be difficult. The best way to learn it is to do many retrospectives, and be open on anything that happens during the meeting with the team. Ask them if they are ok with the way that you are doing or did the retrospective? Check with them how the exercises are doing, and if that works for them? Reflecting on the way the retrospective is going helps to adopt agile retrospectives in the organization.
Reflect early and often
If there are problems, when would you like to know about them? Preferably as soon as possible so that you can deal with them before they do much damage. If there are already signals during a stand-up, then you can discuss them and decide to take action, or plan a retrospective to explore them and deal with them. By doing a retrospective every iteration, or every week as teams that use Kanban often do, you assure that problems can be made visible and dealt with sooner, before they become bigger and cause more damage.
Matt: I want to thank you for choosing exercises from our book Getting Value out of Agile Retrospectives for designing and facilitating your retrospectives, and a big thanks for sharing your experiences. We love to hear from our readers on how our book helps them to do better retrospectives!