In this post I summarise how my team does retrospectives using RetroBox, a Slack app for retrospectives (https://retroboxapp.com)
In agile software development, teams usually work in iterations in order to have a shorter feedback loop which helps teams clarify assumptions ASAP and respond to changes quickly.
What you don’t want to do as a team is keep going through iteration after iteration without allowing your team mates to vocalise how they are feeling or what they are thinking. There needs to be space and time for this: retrospectives.
Overall process
We have a rotation of people to facilitate sprint retrospectives. These are retro facilitators. We also sometimes prefer an external/outsider facilitator for their different perspective and we find that outsiders tend to be less biased.
The facilitator runs /retrofacilitate in our Slack channel at the beginning of our 2 week long iteration to start a retrospective session. This session remains open for the duration of our iteration, so that any team member can submit their feedback using /retrofeedback as thoughts/feelings come to them. Some questions we ask in a retro are:
- If you could change one thing about the last iteration, what would it be?
- What one word would describe how you feel about the last iteration and why?
- What did you learn?
- What puzzled you?
- What approach went well that others should also know about?
We have a scheduled recurring retro meeting on the last day of our iteration. In this meeting the facilitator runs /retroendfeedback to publish all the submitted anonymous feedback to the channel. In this meeting we don't spend time waiting for people to submit their retrospective feedback because i) they've had an iteration long time to submit their feedback already, ii) recency bias. This meeting is focused on discussions and actions.
We sometimes also do one-off retrospectives about a certain deliverable, process or anything. We just create a slack channel for it and use RetroBox there.
Voting
If there are too many feedback items to discuss, we consider using /retrostartvoting to start the voting phase to privately and anonymously vote on the feedback items, in order to decide which feedback items we want to discuss first and possibly dedicate more time for than others. If there aren't many feedback items, because we have already allocated a fixed amount of time for this meeting, we go through each feedback item one by one without worrying about time management.
A note on grouping feedback items
If you have a lot of feedback items to discuss, you will probably use the voting feature to decide which feedback items to spend more time on. Some teams create groups of feedback items before they start voting, in order to aggregate votes. We find that this is usually more cumbersome and time-consuming than it’s worth. It triggers discussions of what group should have which feedback, what groups we should create, what they mean and so on. It is hard. We consciously decided to not support “formal grouping” and take a more relaxed approach: we just let people vote on feedback items. The ones that don’t get any votes don’t get discussed anyway, so we have a clearer list of items before we waste time grouping them. With those items that have no votes out of the way, we find it easy to group voted feedback items just by looking at them. The facilitator does this roughly. Between “spending time on perfect grouping” and “spending less time by perfect grouping, and more time discussing the issues” we prefer the latter.
Facilitator’s responsibility
It is primarily the facilitator’s responsibility to facilitate time and the discussions. The facilitator seeks to pin down actions, makes suggestions, asks further questions and tries to engage with everyone in the room. After discussing a feedback item, the facilitator takes note of the action items we agree to take, and looks for volunteers to own those action items.
I personally observed that if there are people with power in the room, such as a director or some sort of manager, the team members can be more shy and afraid of discussing issues. I’d just like to point out, without trying to sound like a team culture expert, that your team culture needs to allow it before you can have effective retrospectives that help people rather than make them feel nervous and uncomfortable. If you don’t have such culture, retrospectives can make people feel frustrated, upset and uncomfortable. In my opinion those retrospectives can do more harm than good.
Tracking Action Items
We have a Kanban board for tracking our retro action items. We dedicate about 5–10 minutes at the end of our retro meeting to quickly go through the previous action items, to see if there are any blockers. We don’t strictly track these action items because usually the action item owners are people who feel they can make a real impact by taking their actions items. That tends to be enough motivation for people. If something is really a burning issue, then the action item for that becomes a formal task in our iteration/sprint.
Emre @ RetroBox
References:
