Retrospectives for Management Teams

Engaging top management in a recurring retrospective approach can result in long-term value in organizations. Retrospectives can help management teams to explore how they collaborate and cooperate. They can find out whether they should change something and decide on action points that propel the team forward and make them more productive.

Kamil Puk, agile practice lead at Netguru, gave a micro workshop about retrospectives among top management at the Agile Management Congress 2019.

In his management team, Puk started a series of meetings to address how they work. He knew that they did not have that level of openness and transparency to kick off full-blown retrospectives just yet:

It was also a time of a few tensions in our team, and I felt that starting too fast could impede our chances. Asking “What can we improve?” can sometimes be a bomb if you ask it too soon.

He wanted people to feel giving, to receive support and help from the team, and to build a feeling of safety and openness. Instead of suggesting a retrospective, he organized a “tips and tricks” meeting for the team. As they work remotely, he used the online collaboration tool Miro.com:

Using such a virtual whiteboard, I asked: “What makes you productive?” I encouraged everyone to share their recipe for being successful by adding post-it notes. It was exciting to see people pick it up - some of us came out empowered to boost our efficiency with an experiment borrowed from others, and some were just happy to have a useful tip to share. 

As it went well, he added a second column in the same meeting: “What makes me unproductive?” Not everyone was enthusiastic initially, but sharing some minor personal weaknesses allowed people to open up a bit, and assured them that they were in a safe environment:

In a few minutes, we were nodding with compassion about how insufficient sleep, noise, or too many meetings in a row lower our performance.

The following week, they followed up with another low-interaction topic about how they like to share and receive feedback, Puk said. They slowly worked their way into more collaborative issues over time. In just a month or so, the meeting was called a retrospective in their calendars and team members took turns as facilitators regularly.

Puk mentioned that he finds it extremely useful to open up with topics that are not interaction-focused, but instead allow them to form a connection, trust, and set a stage. This allows for more crazy, fun, and bold formats in meetings later on, and those are the ones bearing fruit, he said.

InfoQ interviewed Kamil Puk about his experience doing retrospectives with the management team.

InfoQ: What made you decide to start doing retrospectives with management teams?

Kamil Puk: I never intended to convince my team to retrospect regularly in the first place. Instead, I was curious about visualizing our shared teamwork on a Kanban, so I started such an experiment one day. When we inspected the board together, it struck us how few tasks we share, and even though we considered ourselves a team, we were a group of people each focused on their own swimlane. We had only a handful of topics where more than one person was involved in. I suggested we have a short discussion on how we cooperate, the risks and gains of such an approach, and whether we should change something.

InfoQ: What’s the “recipe for a successful simple retrospective”?

Puk: Usually, my recipe is: observe, define the purpose, choose tools, execute. Each stage has its challenges to work through. 

I start by following the team: their behavior, communication, and the outcomes of their work. This gives me a rough idea of the purpose of the retrospective and what subject we want to zoom in on. Usually, I discuss some ideas with the team, and we settle on a topic together. 

With a specific purpose, I can look in my toolbox and try to figure out the best mix of tools that can help us achieve our goals. I advise not to rush into this step sooner; starting by choosing our favorite or most common tool is tempting, but rarely fits the purpose well.

The fourth step is execution, the meeting itself. I always start with a review of the last action items, and then just make sure that everyone feels safe, and can communicate openly and according to their temperament. Working asynchronously, using silence well, and allowing everyone some time to think and speak up is crucial. 

Lastly, it’s essential that we manage time well, and have space to plan our action items for the next period.

InfoQ: How do your managers ensure they have time to do the actions that come out of the retrospective?

Puk: I don’t think it’s a matter of time, but rather of visibility, prioritization and habits. We start by making the actions list visible and transparent. Most of the time, we use Confluence to note the outcome of our retrospectives, and it has an embedded function for action points which makes it easy. We make sure that the addressee and deadline are clearly marked to be able to follow up on, and to utilise some more advanced Confluence macros later on.

On an execution level, I think it’s a matter of building proper habits. In my closest team, we review the list in our weekly status meeting, and in some standups, too. We share a belief that whatever makes it to the list is important and relevant. The action owner needs to prioritise and share this work accordingly to make it happen.

Actually, I would be very surprised to see managers not acting on their list. The very purpose of the retrospective is to visualise the needed change and make it transparent, and a key duty of the manager is to lead change in the organisation. It fits like a glove!

InfoQ: What kind of exercises do you carry out in retrospectives with management teams and how do they work out?

Puk: I was surprised by the results of the “us, through the eyes of our team” meeting that we had one day. In short - I asked a few of our direct reports to doodle the management team as if they were a machine. Some people drew an umbrella, some drew a radio or a robot, and one person drew an ATM. In a retrospective I asked my management team the same question, and so appeared a tank, a coffee machine, a ladder, and a microchip. It was a great foundation for a discussion on what our team’s purpose is, and what characteristics we are associated with. It gave us great insight into our top-down communication and how we build our management brand.

There is great inspiration for retrospective exercises around. I highly recommend the Liberating Structures menu or the tools from Design Thinking playbooks. Usually, they need a little tweak but are a great starting point. I really enjoy having a shared pool of exercises among facilitators working together in the same organization. It helps facilitators grow their versatility and at the same time makes it easier for the teams to have a set of familiar methods.

InfoQ: How can we prepare for a retrospective?

Puk: I believe there are two main components of a decent preparation: setting the stage and preparing the content. 

Setting the stage means everything around the logistics of the retrospective: making sure you invite everyone interested, securing a spacious room and all the equipment you might need, preparing the printouts, post-it notes, etc. 

When it comes to the content, I believe that at least some research on the team is necessary, to allow you to choose the right purpose and tools. It helps to review the notes of the last retrospectives before the meeting, to remind yourself of the past discussions, and to make sure you follow up on the recent action points. 

InfoQ: What can be done to get good action points out of a retrospective?

Puk: Good action points are the ones that propel the team forward and make them productive; I focus on quantity, quality, and the process itself.

When it comes to quantity, it’s always wise to limit our commitments in order to maximize our chance of delivering them on time. Sometimes it aches the team to let go of some great ideas and not turn them into action points after a meeting. I believe it’s our duty as facilitators to increase the likelihood of a positive impact, even if it means cutting the number of initiatives we start simultaneously.

When it comes to quality, in Radical Candor Kim Scott gives an easy-to-remember recipe for action points. You need to have a one-line answer to who will do what by when? If you do not have an answer on all three aspects, you don’t have an action point after all. If you follow her lead, you get a statement that is easy to act upon, easy to check if it’s being done, and easy to communicate with your stakeholders.

Regarding the process, I like to encourage people to write their action items themselves - it helps to frame them in a way they understand and find easy to act upon. It helps to remember them, too. I strongly discourage the approach of writing them down in short form and expanding them after the meeting; I believe they should be clear and transparent to the whole team from the very start.

About the Interviewee

Kamil Puk is an agile practice lead in Netguru, responsible for growing the agile mindset and practices across this fast-growing digital consultancy company. With experience as a project manager and a team leader, he has seen plenty of interesting ideas turn into great products – or into dust. Puk has a background in finance, technology and service design, which allows him to see various perspectives and apply a broad range of tools to get things done. After hours, he's a passionate amateur cook, aspiring sailor and incorporeal dreamer trying to make his dog just a little more obedient.