An Effective Retrospective With Team Trust and Without Management
April 11, 2012 2 Comments
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. In a quick summary for anyone who is new to a retrospective type meeting, it’s 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 many ways to hold these kinds of meetings and to get the input and output that you need.
Although this article is based on my personal experience of what has worked and what hasn’t worked with teams throughout my career, I learned a lot of the best techniques for agile and retrospectives while working with the Blue Sands team. The Blue Sands team, myself included, had months of professional agile coaching by Gil Broza – one of the top agile experts and coaches.
Some of the retrospective methods I’ve seen and have been involved with 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. All things equal, neither of these meetings are right or wrong on their own and can have their place.
There are many ways to do the retrospective, and I don’t want to discuss meeting style too much. 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, or when the team members are inhibited from freely discussing and resolving team problems.
The first two points are a given – actually they are a given for any type of meeting. The big point I want to discuss is inhibiting teams from properly resolving problems. This typically happens inadvertently due to a bad meeting style or the wrong people in the meeting.
Take the following two scenarios.
John, Sully, 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.
They enter into the retrospective meeting. John makes the point “Ugg, not this again”. Sully 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 the best of 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. Sully 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.
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. 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 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. Team members typically work with each other regularly and typically work less with management. In this environment, bringing management in to the meeting inhibited the team from having a productive retrospective.
Management 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.
I believe that a more important role for management 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. Management 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, management nor the team needs to care at this point about the details and conversations during the meeting that led to the results.
Dan Douglas is a professional independent Software Consultant and an experienced and proven subject matter expert, decision maker, and leader in the area of Software Development and Architecture. His professional experience represents over 12 years of architecting and developing highly successful large scale solutions. Dan also believes that properly empowering teams with trust and responsibility yields the greatest results.
The opinions expressed in this article are my own and are based what I have done, what I have seen, and what I have learned while working in many different team environments.