Effective retrospectives lead to a better team dynamic, process improvements, and better software. The retrospective process can be powerful and is part of a fundamental path to improving software. They should be done on a regular basis with or without fully practicing agile in your environment, but in an agile environment, the retrospective is done at the end of every iteration (or sprint). In a quick summary for anyone who is new to a retrospective meeting, a retrospective is a time for team members to meet, and discuss the things that have gone well and the things that need to be improved. There are good and bad approaches to holding retrospectives. Some of the approaches are worthwhile, and others are just show and tell to make it feel like the team is retrospecting regardless of if anything is actually learned and approved upon.
Along with the incredibly opportunity of being a team member in one capacity as well as a leader in another capacity involved in implementing retrospectives, this article is based on my personal experience of what has been effective and what has been a failure with teams throughout my consulting career. Fortunately, I have had the opportunity to work with some incredible Agile coaches, including Gil Broza, where I learned and evolved my understanding and techniques for retrospectives and other agile practices.
Some of the retrospective methods I’ve seen and have used include having each team member write points down on sticky notes anonymously and sticking them to a whiteboard and grouping them with similar team member’s sticky notes in order to draw discussion and create actionable items, round tables where individuals are each asked what went right and what went wrong, meetings where the scrum master is asking people to speak up about the good and the bad, and even situations where a senior executive is asking technical people what the faults are of the team in a round table discussion. In some environments, I’ve seen finger pointing and blame from not only team members, but from leaders and executives.
There are many ways to do the retrospective, and I don’t want to write too much detail about retrospective meeting style. The point I want to get at is that retrospectives are completely useless if they are not taken seriously, are done for the matter of process only, to make executives or business stakeholders “feel good” even though they are oblivious to the fact nothing is learned, or when the team members are inhibited from freely discussing and resolving team problems.
What I want to drive and hopefully influence readers about is that by inhibiting teams from properly identifying underlying problems, root causes, and ways to implement and correct those problems, you are doing a disservice to the entire project or organization. The way to greatness is by learning from mistakes, approving upon them, and executing; it’s not by having a “retrospective” meeting, jotting down points, and walking away. You need trusted team members in the meeting only, you need the key players responsible for performing the work, and managers and stakeholders should have as little involvement as possible. If you have a team member who acts as the psuedo-leader of the retrospectives too, it can be just as bad – you don’t need a supervisor. You need the right people, and only the right people in the retrospective.
Take the following two scenarios:
John, Mike, Jennifer, and Jack are all team members working on the project. They do different job functions, but they are all at the same level in the organization and they all work together nicely.
Scenario 1:
They enter into the retrospective meeting. John makes the point “Ugg, not this again”. Mike and Jack are equally unimpressed but stay quiet not to arouse suspicion with management about how much they hate these meetings and how the meetings haven’t accomplished anything in the last year since they’ve been in place. Jennifer shows up late. The scrum master enters the meeting along with a couple of the higher ups in the organization. They start the meeting off, with , what I think, are good intentions, by asking “What can we do differently to improve?”. Everyone has an idea of some problems that have occurred, but nobody is really speaking up or telling the full truth about how things can be improved and what they think the specific problems are. There is a fear of reprisal from management if they speak up. Mike feels that management may think he is inferior if he brings up an improvement idea for something he knows he could do better himself. No one wants to appear as blaming others for problems or inadvertently cause management to think inferior things about their colleagues. The meeting just goes on and some action items get written down and everyone seems ok about it at the end of the meeting. It looks great on paper, but there were never any real discussions that really dig away at the core problems to find the true solutions to increase the overall dynamic and productivity of the team.
Scenario 2:
The team members enter the meeting room excited with passion and energy. There is no scrum master, no management, and no superiors at this meeting. The team members are ready to meet for an hour to discuss productivity issues, what went well, what could be improved, etc. Although rare, in some environments, management may fear that the team members could just dick around for an hour and not accomplish anything, effectively making the meeting as useless as scenario 1. However, this team has a process they’ve been following for the retrospective for the last year. They are a self-managed team, and are prepared and disciplined to work together as a team to resolve problems and improve. At the meeting, team members write down items about what worked well, what could be improved, etc on to sticky notes. Once written, they are put on the board, similar items are grouped together, and then they are discussed. There is no management involved and no finger pointing either. Everyone freely discusses the challenges they are facing without worrying about what the higher-ups, managers, scrum master, or anybody outside of the room think. It’s a great environment to allow team members to challenge each other and challenge the way things are working without fear. It sparks a great debate and a great desire by the team to create actionable items to improve, and also, to individually make a mental note of things they can do better individually to improve. Because everyone on the team works daily with each other, the team builds a certain type of trust relationship which is a requirement if you want to have a truly effective retrospective. The retrospectives foster discussion and the ability for the team to improve. The team then documents what was learned and how the team will move forward based on what was learned. At this point, the learnings as a result of the meeting can be shared with senior management or executives.
You just read two examples of a retrospective in action. Both of these examples are real world examples that have had the scenario and names changed for anonymity. The second example, however, has less to do with the fact that management wasn’t there and more to do with trust within the meeting. Because management wasn’t working together with the team on a regular basis and building trust between all members where team members felt they could honestly talk about their team concerns and their own shortcomings and failures, the retrospectives became useless. Even though the manager/leader would write down key points on what was achieved, what didn’t work, and how we would improve, it was more sugar-coating to please his own manager or business team rather than anything that came close to driving the team to learn, execute, and move forward. The actual team members typically work with each other regularly and typically don’t work nor build trust with management – that’s also something that should be improved, but until you have that, it’s especially important to let teams run their own retrospectives. In this environment, bringing management into the meeting inhibited the team from having a productive retrospective.
So, what role should leaders play?
Leaders (or managers) can play a part in orchestrating the retrospective meetings, time boxing, and ensuring they flow properly, but more often than not, the actionable items become a facade and do nothing more than make it look like the team is having a valuable retrospective even though nothing is actually learned.
I believe that a more important role for leaders when it comes to retrospectives is to help the team come up with an effective process for the meeting, help the team understand the value of the retrospective, and to go through a few meetings with the team solely for the sake of nailing down the process. Leaders can also see the results of the retrospective and should drop in, albeit briefly, from time to time to see how the retrospectives are flowing. It may take some practice, but the team will become more and more effective at the retrospective as a result. It even makes sense to have management come in to the meeting in the final 10 minutes of the retrospective to discuss and challenge the results of the team in further detail. Being involved in the final ten minutes of the meeting allows management to be engaged as part of the retrospective and to challenge and discuss the results. The important distinction here is that management wasn’t there during the meeting to inadvertently inhibit the free and open discussion by team, however once the results of the meeting are written down, leadership nor the team needs to care at this point about the details and conversations during the meeting that led to the results, nor do any fingers need to be pointed.
(An older version of this article originally appeared on my ‘Articles on Software’ blog in 2013. It has been updated and revised here for my ‘Dan on Software’ site)