- Context
- General Context
- Antipattern Solution
- Consequences
- Symptoms
- Refactored Solution
- Online Aspect
- Personal Anecdote
This chapter is from the book
This chapter is from the book
This chapter is from the book
Refactored Solution
Prepare for the retrospective in a number of ways. For example, make a shared document,1 and send an email at least 1 day before the retrospective with a link to the shared document and ask team members to make sure they can access it. If the team was warned at the last retrospective that they were expected to prepare for the next retrospective by populating the shared document with virtual Post-it Notes, you can remind them when you send the link. You can also ask them to start filling in the document before the retrospective. In that way, you can save some time in the retrospective, and it might be easier for some people to fill in the document about positive and negative events when they can sit quietly alone with their calendar. Then, when the retrospective starts, you can set aside some time for them to read all the inputs. With this approach, everybody is prepared. It works well and has been implemented by companies such as Amazon, where the first 10 minutes of every meeting are set aside for people to read the document in order to have everyone prepared and in the right mindset for the meeting contents.
Send an email again on the day of the retrospective 15 minutes before it begins, reminding the team that this is a good time to get coffee. Otherwise, people forget until the very last moment. Then they will want to get coffee, and then when they get up, they notice they need to go to the toilet. At this point, the first 5 to 7 minutes of your retrospective have already been wasted.
It is also important to prepare a detailed schedule for the retrospective. Be aware how much time you have for each phase in the retrospective, and do your best to stick to it. If you can see it is not enough time, ask the team what they would like to do about it. Extending an online retrospective is usually not an option, so the realistic options are to choose only one of the subjects on the board to discuss or to arrange a follow-up retrospective. Either option is a better alternative to just hurrying to the end of the retrospective and letting everybody log off without a wrap-up.
As always, have a backup plan for the retrospective, another agenda that allows for a change without demanding a lot from you. Retrospective facilitation, like most software development, should be agile, as described by Joseph Pelrine (2011), and plans should be followed by actions and feedback loops. This is described in more detail in the Cynefin framework (Kurtz & Snowden 2003), where complex systems should be dealt with in a probe-sense-respond fashion: you try something out, sense what happens, and respond to the reality instead of following a complicated plan.
Preferably, everyone should have his or her own camera and be in separate rooms. This can be hard to achieve, but it prevents in-real-life subgroups of people from having a parallel discussion on their own.
If you choose to have a physical board in one of the rooms, instead of a shared document online, you might want to give each person an avatar, also called a proxy, someone who acts on behalf of another person who is not physically present. Set up a phone call or a chat between two people and let the avatar write Post-it Notes for the person he or she represents.
In summary, you should do your best to make everybody equal at an online retrospective, even if you feel the odds are initially against it. One benefit of online retrospectives is that it seems more natural to make all discussions using the round robin technique, instead having free-flow discussions in the plenary.
Round robin is a pedagogical pattern, described by Bergin and Eckstein (2012), that I use extensively in my teaching.