At last we come to what some experts say is the most important scrum ceremony of all: the team retrospective. This is the team’s moment for self-reflection. You might also hold retrospectives that include stakeholders and others. Those have a different purpose from the team’s retrospective on their internal workings.
The Team Retrospective
One of the hallmarks of a successful scrum implementation is continuous improvement. Teams that do not conduct regular self-inspection, and that do not find ways to do what they do better, are destined to go the other direction.
After every sprint, it is critical that each scrum team take a few minutes to review. They should use this time to recognize success as well as identify weaknesses. While the sprint reviews and the demo offer the opportunity to recognize their work product, the retrospective is when they recognize how they work.
The retrospective must be a peer review – rank or management relationships are irrelevant. Every team member must be empowered to speak their mind. If the team’s culture doesn’t allow frank discussion, then it’s not a viable scrum team. You need to fix that before the team can achieve truly great agility.
The retrospective is the litmus test for a team’s maturity.
There are many ways of running a peer review or post implementation review. In all of them, the goal is to gather input from everyone without judgment, document it, and identify the most critical concerns – the areas that it’s most important to improve on.
The agenda we use at Streamline Health is the “round the room” technique:
Go around the room, asking each person to offer one thing that went well during the sprint. Write each contribution down as stated. Keep going around the room until nobody has anything else to add. But enforce the “one item at a time” rule. This prevents any one person from dominating.
Then go around the room asking each person for one thing that needs to be done better. Language here matters to people – don’t ask for “what went wrong” or “what failed.” This allows team members to suggest improvement to their peers without actually saying “you failed at …” As with the positives, keep going around the room until nobody has anything else to add.
Typically, the “things to improve list” is longer than the “we did great” list. That’s good. It’s a sign of a team that recognizes its weaknesses and wants to improve.
The final step is voting. Each team member gets to vote on her top three (or four, or two — whatever seems doable) items that need improvement. The three that get the most votes are the ones that the team will work on during the next sprint. Sometimes these require external help, and when that’s the case the team needs to assign a member to seek it out.
Bad Retrospective Smells
A subset of “bad scrum smells” is that whiff of an ineffective ceremony at the end of each sprint. Here’s what we mean:
- The team raises the same “what went wrong” items sprint after sprint. This team is going through the motions of the retrospective, but not actually focused on continuous improvement. They’re not trying to fix the top problems. They should include tasks in their planning that touch on the items to improve. For example, if they’re failing to comply with some part of their definition of done, put a “confirm DoD” task on every item in every sprint until it becomes habit.
- Many of the “needs improvement” items are external. A team that blames others for their problems is not taking ownership of their work and their process. Items like “The requirements were bad,” “system engineering didn’t keep our build machines up,” “the SME wasn’t available enough,” are all legitimate issues that a team might face, but in their retrospective they should be stating them as challenges that they need to solve. They could be stated as “We need to focus more on pre-sprint backlog refinement,” “we need to check the build machines every evening and get a ticket in to system engineering the moment we see a problem,” “we need to make some standing appointments with the SME rather than calling her ad hoc and not reaching her.”
- Some team members “pass” on every round. If one or more members aren’t offering observations about problems, something – or someone — is suppressing them. It can be difficult to identify the root cause of non-participation in the retrospective. Whatever it is, this team is destined to never achieve high performance, so intervention is critical.
- Is the moderator neutral? Does the moderator (or scribe if it’s a separate role) edit the team members’ contributions, or write them down as stated? It’s okay for the moderator to ask “do you mean the same as what Joe said a minute ago?” and if the answer is “oh yeah, he did say it,” then no need to duplicate. But if the answer is “no, I meant…” and the team member provides differentiation, write it down. It is never okay for the moderator or scribe to say “I don’t agree with you” and not write down the team member’s contribution.
- Is a manager in the room? This is a peer review. Reduce attendance to just team members. Some agilests consider the product owner part of the team. The product owner passes judgment on the team’s work, so he’s not a member of the team. If the team has concerns about their relationship with the product owner, they need space in the retrospective to expose and discuss them. Leave it to them to invite the PO in, or not.
- Is someone a bully? Is there a team member with strong opinions who manages to dominate even though the moderator tries to run a balanced meeting? If this happens repeatedly, other team members will give up and stop participating. If you see this, it may be necessary to address the behavioral problem through the person’s manager.
The results of the retrospective including all items raised (good and bad), and the top three items to improve, need to be documented where the team can see them. At Streamline our developers live in TFS, so that’s where we capture them. Each retrospective is documented in a work item assigned to the sprint. All team retrospectives are visible to everyone, and they’re immediately accessible without having to leave the development tool.
We don’t package them into the next sprint so that the team can plan tasks for the items to improve. But that might be an effective way of helping teams remember to act on them. We’ll report back here if we take that step.