Improving your team with Retrospective
We’ve all had ideas on how to improve the way our team functions. But how often do we share these ideas? Or follow through with the execution after sharing? In Agile software development, the Retrospective is a routine meeting in which the team consciously pursues to improve on how the team functions with the goal being to raise the team’s productivity and make the team members’ lives easier. The retrospective meeting may be heavily associated with software teams, but its principles can be adapted to help improve any team!
The basic idea is that the team should have a recurring meeting where they discuss what went well and what did not go well since the last retrospective meeting, and then discuss what can be done to improve moving forward. I will explain each of the main principles and requirements of the retrospective meeting and then draw out how our EpiAnalyst team runs their retrospective meetings.
Basic Principles
Schedule a recurring meeting. The retrospective meeting should be a scheduled habit. If you don’t make a habit of consciously improving your team and keep treating it as a stretch goal, then you will just keep digging your team into a deeper hole. Even if you are only making small incremental improvements, that is better than making the same mistakes week after week. So plan to meet every other week or every month for about an hour. In agile software development, we call the time between meetings Sprints (a short, time-boxed period when a scrum team works to complete a set amount of work [1]). I will be using the term sprint from here on out.
Have a hub for posting ideas for the retrospective. During each sprint, the team members need to be able to post ideas/comments for the meeting. Back in the day, this meant having a wall with sticky notes under each of the categories but today there are several software tools teams can leverage to have as a hub for their retrospective ideas. There should be time to post ideas at the beginning of the retrospective meeting as well but it is much easier to share an epiphany when it comes to you than have to remember it later.
Allow anonymity. A lot of teams allow for their members to post comments anonymously to quell any fears of being judged. Everyone on the team has a different perspective and getting everyone involved is very important. You may be worried about people taking advantage of anonymity to contribute some particularly nasty comments in the retrospective, but if for some unfortunate reason this does occur then it is just as important to discuss and address why that happened.
Acknowledge what the team is doing well. It is just as important to continue doing the good things as it is to stop doing the bad things. Acknowledging what the team is doing well may help the team realize there are some processes that should remain or could be extended/recycled to help in other areas.
Acknowledge where the team is struggling. The idea here is to mention a process or a project the team struggled to complete. Then the team as a whole can reflect on why it happened and what are some alternatives or ideas to ensure that it doesn’t happen again, or for it run smoother next time. But…
Do not play the blame game. When discussing what the team can improve on, it is imperative that the team takes responsibility as a whole. There could have been one team member that struggled in particular for the sprint but it could be possible that it wasn’t even their fault. They may not have had the tools or support to get the job done. Another team member could try picking up the project from them next sprint and find that they run into the same difficulties. So the idea is to reflect on problems as a team because the team as a whole needs to confront these problems.
Vote on what to discuss. If the team really gets into it, there could very well be way too many things on the board to discuss during the meeting’s allotted time. It is important to prioritize what gets discussed during the meeting. Online tools make this a lot easier. Members should be able to vote (anonymously if possible) on which posts should be discussed over others. You then discuss the posts/comments in that order
Discuss and plan action items. So you’ve discussed where you can improve and how. Now you should record these possible improvements, plan for someone to address and implement these improvements. The team may not have time to get these action items immediately, but at least now you have a list of improvements for when the team does have the bandwidth.
Do not discuss what went well or did not go well from previous sprints. This is more of a tip from me to you (because I’ve been there), than a well accepted principle of retrospective meetings. If the team spends time going over previous sprints’ action items, the retrospective meetings will become extremely repetitive and unproductive. Now if something happened last sprint and affected the team again this sprint, then by all means include it into this sprint as well. Recurring issues/successes are important to discuss because it might mean giving priority to action items you created for previous retrospectives that haven’t been addressed. But if something was brought up 4 sprints ago and hasn’t affected the team since, then it is probably safe to just leave that action item in the backlog.
How does Episource’s EpiAnalyst team conduct their Retrospective?
We have 2 week sprints and we hold our retrospective meeting on the last day of each sprint. We use an online tool called FunRetro, which allows us to create boards for each sprint. Team members post anonymously to the board throughout the sprint and at the beginning of the meeting. Once the meeting starts we always follow (but not strictly) the same schedule:
Our team currently rotates software developers every month as our Scrum Master (this has been great for learning more about Scrum). Our Scrum Master is in charge of the meeting.
- Wait a few minutes for everyone to join the meeting, which we do online through screen share. Reach out to any stragglers but don’t wait forever.
- 5 minutes to allow team members to post anything they may have not gotten to yet.
- Reveal the posts.
- Scrum Master will go over and read Kudos. This is something our team added and isn’t necessary but if the aim is to improve productivity and make our lives easier, then a little morale boost could go a long way. Our team likes to take a few minutes to give props where it’s due. NOTE: We do not vote on, discuss, or create action items on Kudos posts. We just read them and move on.
- Scrum Master will go over and read What Went Well, then ask to see if anyone needs any clarification or wants to make any additional comments (before voting).
- Scrum Master will go over and read What We Can Improve, then ask to see if anyone needs any clarification or wants to make any additional comments (before voting).
- 2.5 minutes for voting. Each team member gets 6 votes and votes anonymously (through FunRetro) on What Went Well and What We Can Improve.
- Reveal the votes, and order the posts by the amount of votes.
- Go through the items/posts one by one. Each time an item is discussed, the goal is to come up with an action item to address it. If there is an action item, we record that in the FunRetro board as well. Get through as many items as possible. If times run out, the remaining items either were not important enough, or they will reappear in a future retrospective.
- Scrum Master then has to make user stories on JIRA with the “retro” tag for the action items we came up with during the retrospective meeting.
- After that it is up to the team lead to prioritize the items. If the team lead fails to prioritize enough retro items, the rest of the team makes sure he hears about it during the next retrospective meeting!
Feel free to take our formula and modify it as you need to fit your team!
