The intersection of technology and leadership

Category: When Retrospectives Go Wrong

When Retrospectives Go Wrong: Too Many Goals

signpostsTeams run retrospectives for many different reasons. I’ve found that trying to meet too many goals in a heartbeat retrospective severely limits their effectiveness. When I prepare for retrospectives, I normally ask the sponsor (the person who asked me to facilitate) what they want to achieve. Sometimes they don’t know themselves, so it’s a useful exercise, by itself, to clarify their intended goals.

When I’ve sat in teams new to retrospectives and the goal is not made clear, people start to bring up too many different issues, and it’s difficult to resolve anything. One hour seems to be the maximum that teams are willing to set aside, and when you’re dealing with team issues, technical issues, process issues and more, all that time literally flies by. The result… nothing is improved and people get frustrated with the vehicle that brings some visibility (the retrospective).

What you can do about it
I use a rule of thumb, “One Goal Per Heartbeat Retrospective”, and make it clear at the start of the retrospective. It helps, if you’re the facilitator, to agree on what that goal is before you start, and do whatever you can beforehand to make sure everyone agrees. It helps if you’re working with a team that is already is formed (see the Tuckman Model) and you confirm this before hand.

Place the goal in front of everyone where they can see it, both as a subtle hint, and as an aid if you feel the retrospective veering off. Run retrospectives with a different goal in mind to address those that you don’t get around to talking about.

Photo of the cross signs taken from Gregkendallball’s Flickr stream under the Creative Commons licence.

When Retrospectives Go Wrong: Poorly Formed Action Items

How you facilitate a retrospective impacts the success for a retrospective. Inexperienced facilitators often don’t know how best to achieve the Decide What to Do part of a retrospective, often resulting in action items too broad, or too difficult to actually achieve. Revisiting them next time results in frustration as the team hasn’t made any progress on them.

Failed Pottery

Photo taken from Opheliates Flickr stream under the Creative Commons Licence

What you can do about it?
Sumeet writes about using SMART (Specific, Measureable, Achievable, Relevant and Timeboxed) to help focus forming better action items. He also writes about giving them an owner and a time frame. I will often use this to guide the discussion – “Is this achievable in two weeks time? How can we break this down to ensure we make some progress? Does everyone understand what you need to do to call this item complete?”

I also like Bas’ Plan of Action approach, linking short term actions with long term goals – allowing people to break down large changes into more achievable ones, or to help align short term tasks with longer, more strategic goals.

As a facilitator, be aware that how you deal with the last part of the retrospective will influence the result, for better or worse. Learn how to facilitate the group towards something more likely to result in an observable change.

When Retrospectives Go Wrong: The Faciliator Did Not Prepare

Ever been in a meeting where the organiser doesn’t really know why they brought everyone together, or even have an agenda to start with? It devalues your time and you feel pretty frustrated. I’ve seen the same happen when facilitators don’t prepare for their retrospective. Preparing well demonstrates to participants respect for their time. Conversely a clear lack of preparation shows disrespect. Even though it doesn’t guarantee it, proper preparation ensures a better chance participants will be more willing to engage.

Surprise

Image taken from Meredith Farmer’s Flickr photo stream under the Creative Commons licence.

What to do about it?
In preparing for the retrospective, I like to go through this list of questions:

  • Who is the sponsor for the retrospective? – Sponsors may have extremely different agenda. Some of it may be about spreading lessons learned, others just want to understand the root cause of some major problem. You want to be clear about who the sponsor is and why you’re even running a retrospective. Is there just one person, or are there more of them?
  • What are their goals, and what are you going to end up by the end of it? – Looking for ways to improve client relationships will have a completely different focus than understanding what new technical innovations came out of the project. The goals will heavily influence what exercises you plan for.
  • Do you know how long the retrospective will be looking back? – Planning to look back over 1 week will be different from 3 months and different again from 1 year.
  • Do you have an idea about what topics might come up? – A retrospective for a project where significant negative events dragged the team at certain stages will be different from a retrospective for a project that had less troublesome issues.
  • Have you planned for enough time to cover everything? – You want to have enough time for people to tell their stories, unload any emotional baggage and get to understand what lessons are worth sharing.
  • Do you have a good representation from team members? – Just having development members in a retrospective will skew what you talk about, perhaps missing important elements all the way from the sale, client relations, etc.

Just before starting the retrospective, also ensure that you have all the materials prepared – this may includes markers, pens, paper, sticky notes, handouts. Also ensure you have the room prepared with any posters or whiteboards you plan on using.

When Retrospectives Go Wrong: Controlling the conversation

One of the most important points that Kerth, Larsen and Derby emphasise in their books is that the facilitator should not have an interest in the conversation. As I heard someone once say most succinctly, “If you have a point of view to share, you should not be facilitating”. This particular bad smell typically happens when this rule is violated. I’ve first hand seen this the most when a person in a naturally authoritative position (think project manager, technical or team lead) facilitates.

I remember sitting in one retrospective where the facilitator (a project manager) ran the retrospective pointing at people asking them for a single item (what went well/less well). They would often literally drill the person, asking for more details, and often commenting on their input, saying things like “that’s a pretty stupid idea”, or “you really should’ve done … instead of …” before turning around and writing it up on a flip chart. When they had finished, they decided which topics they wanted to talk about further, then returning to the group without even involving them in the decision making process. I sat, aghast, silently observing as people uncomfortably shifted in their seats wanting to get their stories out in the open yet afraid it wouldn’t go anywhere productive, and worse, be judged for it.

The result… an empty ritual, empowering a single individual, and the only outcome of no beneficial change.

Crowd Control

The above image comes from Misschelle’s Flickr stream under the Creative Common’s licence

What to do about it?
The first step is to get an independent Retrospective Facilitator. Try really hard to get one. I know that finding facilitators are easy, and finding a retrospective facilitator may be more difficult though I’m sure you’ll find the results will be much better.

If you can’t find one and you’re the one facilitating, focus on the process, and less about the content. Your goal should be to ensure everyone has an opportunity to build the shared story, everyone has an opportunity to add their insights and everyone has input into the final solution. Do not push for the solution you think is best, and do not ignore people when they have something to say. Make it clear when you are expressing an opinion as a person-with-a-stake. Empower the group with a mechanism that gives you feedback when they feel you are directing the conversation too much. Believe me, it’s hard but it’s definitely worth it.

And what about the previous situation? Continue reading

When Retrospectives Go Wrong: Conflict of Interests

I heard one story recently from a colleague where a technical lead facilitated the retrospective. They’d collected sticky notes from everyone, placed them around an exercise at the front and began reading them out. The strange thing is that they read only the ones they wanted to read out, blatantly skipping many of the others.

Why the lead would only read out the ones they did, I don’t know. Perhaps they thought they were the most important (based on their point of view), perhaps they were a random selection. I’m not sure. It’s clear what impact it had on the participants. People became frustrated that they weren’t being listened to, didn’t feel appreciated for their input, and I’m sure many of them felt the activity a waste of time. Apparently it broke down to the point where they started shouting out for the lead to read out the notes.

Tug of War

Image taken from TimmyGUNZ’s Flickr photo stream under the Creative Commons licence.

What to do about it?
Kerth emphasises getting an independent facilitator (though versed in the industry) to run your retrospective. From experience I know this to be difficult for heartbeat retrospectives. If so, people who have direct significant influence (i.e. typically project managers, technical or team leads) either shouldn’t facilitate, or be extremely aware of this conflict of interests and do something about it.

I’ve learned it’s important to be clear which, of your roles, you represent when you say something. Something like, “With my technical lead hat on, I’m wary of this suggestion because of …” Another technique is to accept you will be biased and ask the group to raise a flag you when they don’t feel you’re being neutral. If you see the flag, you must do something about it.

Concluding Thoughts
Facilitation is not for everyone. Participants and facilitators should understand where conflicts of interest lie and how it may affect some of the conversations. Mitigate for this by planning to have an independent facilitator or by putting another system in place to prevent these biases creeping in.

When Retrospectives Go Wrong: The Format Becomes Too Repetitive

As a facilitator and a participant of teams leveraging agile practices, regular, heartbeat retrospectives become an essential part of the team’s toolkit. Doing retrospectives so continuously inevitably leads to some repetition, and on some occasions team members seem to find it boring. I’m sure there’s plenty of reasons why someone might find it boring. I believe one of those reasons is that perhaps no important issues are being brought up, to which I would respond by scaling back the frequency of the retrospective – so say, holding one every two weeks instead of every one.

On the other hand, some people find the standard format of What Went Well, What Didn’t Go So Well (and sometimes Puzzles) too monotonous for their tastes. Even as a facilitator, I admittedly find repeating the same exercise slightly boring.

Luckily the Agile Retrospectives book offers a plenty of options you can implement and still achieve the same outcomes. I think it’s important to ask different questions, and also use different formats. Sometimes asking a different question exposes a set of very different answers from what you’d expect. Using different formats, especially those that are highly visual (symbols, graphics, colours, charts, etc) is enough of a subtle change to keep people interested and excited.

When Retrospectives Go Wrong: All Action and No Talk

This is the corollary to the previous “All Talk and No Action” post.

I remember talking to two different facilitators about the way they run retrospectives. Facilitator A said “I don’t care too much about getting to action items”, implying that they wanted the people to discuss their problems. In contrast, Facilitator B said, “Why would you run a retrospective without any actions?”. I saw both sides of the argument, but also saw danger in both extremes. In the last post, I wrote about what happens if you only ever run retrospectives without ever changing it.

What would happen if you ran retrospectives only focused on action items?

Context is never shared
Running a retrospective gives some people a forum to be heard. Sometimes people need to get things off their chest, and need to be fully heard by all parties (keeping in mind it’s under the Retrospective Prime Directive). Regardless of whether an action item is created or not, some people may feel resentful if they don’t get a chance to tell their side of the story. By sharing a story, the team is also more likely to relate to the other person’s problem.

The wrong problem is solved
Often I hear people propose solutions in retrospectives without explaining what it’s trying to solve. Only by drilling into the issue further, do you sometimes uncover a very different problem. To this root problem, others may propose a better solution that is more effective, or works better for the entire team. Jumping to actions without discussing what you’re trying to fix often results in a poor solution, and often one to the wrong problem.

Teams lose a shared understanding
I’ve been in one retrospective where a team member only saw the result of the action items and never heard the discussions around it. They felt very resentful over a number of the action items, both because they felt left out and couldn’t see why they were needed. After the retrospective, we revisited the items and the reasons they came about to give them a better context but I don’t think it had the same impact if they had been there during the discussions.

What you can do about it.

Understand the the retrospective is simply a tool, so truly understand what you’re trying to achieve with it and facilitate it accordingly. Use a different set of activities to achieve your specific goals, and ensure you balance the needs of the group to make progress and the needs of the group to talk about the issues at hand.

When Retrospectives Go Wrong: All Talk and No Action

I’ve talked with a number of people who dislike retrospectives, and I feel a common reason they dislike them is that they feel that things don’t change. It’s all very well talking about problems, like what occurred and why, however when they come up with solutions, they still keep finding the same things coming up over and over again.

I, and several facilitators I’ve talked to, have many good reasons for holding retrospectives without being excessively focused on action items as it can be a useful place for different members of the team to better relate to each other’s problems and understand each other’s situations. On the other hand, you want to avoid creating situations where they feel they can’t work on their problems or they are not making progress.

Regardless of whether or not problems persist, I feel retrospectives still serve as a useful tool for highlighting these problems. Like Information Radiators, they are simply showing you where pain points lie. They don’t automatically make them go away.

The question I ask people about these situations is “What did the team do to make the problems go away?”, and “How did they approach fixing their own problems?”. I’ve seen a few retrospectives where the actions involve people outside of the retrospective, and committing them to changing external environments.

Some useful techniques for dealing with this include Bas’s Planning for Action, or by creating and ensuring that better action items are created. Perhaps they’re too big and they never get done, or perhaps action items are too general for them to be really executable. Creating action items that the team have no control over, and involve people not present in the retrospective are generally never realised. Focusing on smaller, more specific action items that the team actually has an ability to influence ensures that at least incremental progress is made and sometimes that’s enough.

When Retrospectives Go Wrong: The Facilitator Controls the Retrospective

I participated in one retrospective run by a contract Project Manager whose style was to stand in front of the group, and ask individuals one by one for a single idea for a “What Went Well”, “What Went Less Well” wall. I felt horrified as I saw each person uncomfortably offer a very brief statement, or in general, skip their turn and all with little discussion around it.

I look back at that situation and guess that it wouldn’t have been so bad if the team already had trust and confidence in the facilitator, but it was obvious from my perspective, based on the lack of interaction and productive conversations, this retrospective offered little value.

Strategies that I would employ (and some that I did) to improve the situation include using an independent facilitator (with no vested interest) to run the retrospective, collate input using sticky-notes to improve anonymity and efficiency, and to spend more time, drawing out the story behind the items to identify any common root causes.

When Retrospectives Go Wrong

Some people think that I’m a little bit crazy about how passionate I can be when it comes to retrospectives. I feel it’s an important event for organisations, teams, and individuals to reflect and adapt the things that they’re doing. I find it really strange, if not slightly contradictory when people, who enjoy practising agile, don’t necessarily believe in the value of retrospectives (but I don’t want to detail that thought just yet).

This week I’ve been fortunate enough to share, with my class, my passion for retrospectives and only had enough time to skim through all the ways that you can use them. What I unfortunately didn’t have enough time to cover was the ways that retrospectives may go wrong and, therefore, not be particularly useful for people.

When people misuse or misapply a particular tool, the people involved can, understandably, jump to the conclusion that the tool itself is terrible and a great waste of time. More often than not, I feel those people have shut their mind far too early, and don’t have enough of a chance to understand the contexts in which that tool may bring the greatest value. Sure, I’ve been through, and probably even hosted, quite a few ineffective retrospectives myself, but it doesn’t mean that the retrospective tool doesn’t offer any value.

To fill the gap that I missed with my students, I’m at least hoping to share with them (and everyone else on the web), my understanding about when retrospectives can go wrong.

© 2024 patkua@work

Theme by Anders NorenUp ↑