First of all, I would always advise to send information on the upcoming Retrospective ahead of time, so that culturally and linguistically diverse Teams can mentally prepare themselves. In your message, please provide information on the date, duration, location, equipment (webcams, telephone conference, paper etc.) and a rough agenda (not spoiling any surprises, of course). Furthermore, please inform the Team on the specific topic of the Retrospective (unless you would like the same issues to come up every single time). Such a topic could be “To understand the reasons behind …. why we’re not getting the committed Stories done / why we are finding so many bugs / why we never get a green build at first attempt etc.“. I have found that using online spreadsheets, such as Google Docs or EditGrid, can be a lot of fun and keeps the Retrospective very simple. If you chose to use such websites, please do not forget to send the link together with the above information.
I would like to now present to you one of the best agendas I have followed so far. This Retrospective had been part of a Sprint where the Team had worked very hard, but still had not managed to finish any of its committed Stories. I had set the duration at 1.5 hours and did not invite the Product Owner. I had the telephone conference on for the entire Retrospective, so that we could talk as well as work on the computers at the same time.
1) Check-In: At the beginning, I performed a little check-in exercise in order to set the stage. I asked every single one of the eleven developers to check in via one of these five emotional words: frustrated, confused, happy, sad, hopeful. This really helped, as it allowed every Team member to express his or her feelings about the failed Sprint and it meant that everyone‘s voice was heard at least once during the Retro.
2) Working Agreement: I asked the Team to come up with a Working Agreement that everyone would want to commit to. Such a Working Agreement should include rules of how the Team would like to work together, including rules like: all mobile phones are turned off during meetings, only one person speaks at a time etc. The short amount of ten minutes kept the Team focused and we came out with a Working Agreement consisting of 10 important points.
3) Hard Data: I then kindly asked the Team to use the online spreadsheet (in this case: EditGrid) and enter any hard data from the past Sprint that sprang to their minds. This provided the Team with a shared picture of the past two weeks. It could include events (meetings, decision points, milestones, celebrations etc.), metrics (Burn-Down Chart, velocity, defect counts, bugs etc.), Stories etc. Here, I gave the Team five minutes to enter the information and another five minutes to read through the data of one‘s colleagues and to place a plus next to all of those that one considered to have been high points and a minus next to the low points during the Sprint.
4) Strengths: Here, I had prepared a new, separate spreadsheet where the Team members could each enter the strengths of the Team. The Team had five minutes to write down 1-5 strengths in the appropriate columns, followed by another five minutes spent reading through the strengths identified by one‘s Team members. At the end of the ten minutes, I as ScrumMaster verbally summarised the Team‘s strengths.
5) Break: In order to psychologically divide the positive elements of the Retro from the negative ones, we took a short break at this point (especially good if there are Team members using headphones).
6) Topic: After the break, we immediately started with the topic of the Retro – in this case “Why are we not getting the committed Stories done“? On a separate spreadsheet, the Team members each had five minutes to enter up to three reasons that they thought were the cause for failing this Sprint. They then had five minutes to vote on the top three issues. As ScrumMaster, I noted down these prioritised three reasons on a separate sheet and read them out to the Team.
7) Discussion: The final 45 minutes of the Retrospective were spent in the telephone conference with shared desktop view, addressing each of the selected top three issues with the specific question of “What is one thing we could do differently?“. By focusing the Team in this way, we actually managed to get SMART (Specific, Measurable, Attainable, Relevant and Timely) measures out of the Retro and I was able to ask for the Team‘s commitment.
8) Check-Out: Similar to the initial exercise, I asked everyone to check out via one of the same five feelings: frustrated, confused, happy, sad, hopeful. This way, the Team and I were able to see the direct effect of the Retrospective on everyone.
9) End: I then closed the Retrospective by thanking the Team for their valuable input, repeating the committed measures and asking them whether and how the information of the Retro may be used (perhaps a “lessons learned“ document for the next audit) or not.
The Team has given me wonderful feedback on this way of performing the Retrospective. I believe that the specific topic as well as the placing of the focus on the medium of EditGrid helped in getting the Team members put their efforts into the same elements at the same time for a period of 1.5 hours. This joint effort was immediately noticeable in the quality of the measures, which the Team actually adhered to in a self-organized manner over the upcoming weeks. This may have also been influenced by the fact that all Team members had participated on an equal level and thus felt equally responsible for the input as well as the output (measures) of the Retrospective.
Go ahead, have a try & let me know how it went. I am looking forward to your feedback!
Book recommendation: Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen