Last week’s post on Building Trust within Teams got me thinking about the Retrospective. I wanted to share a little more about how I envision a Retrospective in Scrum with some really good information I edited from last week’s post and link it to my discussion on commitment. Here are some basic guidelines that I consider essential for a Retrospective in Scrum.
- The Retrospective is for the Team and the Team alone. The participants to a Retrospective are the Team members, the Product Owner and the ScrumMaster. Apart from those roles, no one else in the organization has a right to attend. If a Stakeholder wants to attend, it is by invitation only from the Team.
- Anything that is discussed in the Retrospective is a private conversation for the meeting participants and should be considered “classified”. The ScrumMaster does not have the authority to “declassify” anything that was discussed.
- If anything is to be shared, then it is the Team who decides what is shared and in what format. No one may request a summary of what was discussed or ask that meeting minutes or facilitation notes be shared.
- The Team must commit to at least one action item that will improve the Team, the product or the organization. The action item must be something they will implement in the following Sprint.
Now all of this is not to say the Retrospective is secret or we are trying to violate the Scrum value of visibility. As someone who takes Scrum very seriously, anything that diminishes visibility is serious problem because without visibility you cannot inspect-and-adapt in Scrum. Inspect-and-adpat is a fundamental precept in Scrum and Scrum does not work without it. The key question to ask around the issue of visibility and the Retrospective is who needs to inspect-and-adapt as a result of topics discussed during the Retrospective and the answer is the Team.
The Retrospective is all about the Team taking responsibility to make a commitment to improve. I feel in order for people to accept the commitment to improve we must have a sense trust within the Team and the Retrospective must be a safe place for frank conversations. If Team members feel what say to one another about their own performance, the product, the customer and their management (what is essentially their own internal conversation) is monitored by outside forces, then the trust is diminished. We certainly do not want people to feel what they say is taken out of context and used against themselves or the Team. Hence, there is a lot in my guidelines about preserving safety.
The other thing that is really important is the Team must commitment to improve – I do not care how small, it just has to be something that makes things just a little bit better for the Team, the product or the organization. Scrum is focused on action and has special focus on doing something right now. In addition, the action items identified in the Retrospective must be something that the Team (or part of the Team) will commit to doing in the next Sprint. If the Team is not willing to commit to making things better even for themselves – even something really tiny – then this is a sign of serious dysfunction within the Team and needs to be explored.
Assigning action items to the ScrumMaster is not going to cut it since the ScrumMaster is not a main participant within the Team. A sure sign that the Team is not taking their commitment to improve seriously is when all the action items involve what other people have to do to change. Yes – organizations have lots of challenges and often times the impediments Teams encounter originate from outside the Team. However, there are a lot of things Teams can do to mitigate the impact of these impediments or work with the originating parties to eliminate the impediments.
If there is no commitment to improve, the Retrospective is a bunch of people sitting around and complaining. I am all for complaining and I can complain with the best of them, however complaining without action really just leads to more cynicism and oblivion. I won’t support action that lead to more cynicism since there life is too short to live in oblivion. What people do in their own time – like at lunch and coffee breaks – is their own concern. What they certainly do not need is a ScrumMaster to help them complain and add to the dysfunction.