An Effective Retrospective With Team Trust and Without Management

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.

Scenario 1:

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.

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. 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.

Advertisements

Share this:

Like this:

Related

About dandouglasDan Douglas is based in Toronto, Ontario, Canada and 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 15 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.
|
For inquiries about Dan's software consulting practice, please see the contact page. Dan has also built up a network of highly successful and professional Software Developers and Architects who are highly respected and can be called upon and used in conjunction with his own consulting practice to handle the largest of consulting projects.

2 Responses to An Effective Retrospective With Team Trust and Without Management

Just reread your article again Dan. Good work, brought back to mind many meetings that I’ve been through that everyone thought was a waste of time. Even though they spent every break discussing problems and sometimes solutions, no one felt comfortable saying the same things at the meetings with a manager so not too much got resolved. I guess it at least gave them something to talk about on their next break :p

Follow Blog via Email

Dan Douglas is based in Toronto, Ontario, Canada and does consulting work for both small organizations and large global organizations through his consulting company, Douglas Information Systems Corporation. He is an experienced and proven subject matter expert, decision maker, and leader in the area of Software Development and Architecture.

With over 16 years of experience, Dan has been the Architect Lead on over 15 development projects and has successfully delivered large scale “best in class” end to end solutions. Dan has developed and architected solutions across a wide vertical, including, government, medical, automative, hr, manufacturing, technology, consulting, and software firms.
Dan writes a lot of code as a hands on developer and is passionate about delivering the right solutions to customers through better code, better architected solutions, better business alignment, and better process.

"My articles are inspired by what's possible. My experience in my software consulting practice has given me the inspiration to write about what I've seen and what I've done, and to write about 'What's possible in software'." - Dan Douglas