Category: Learning (Page 13 of 15)

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.

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.

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.

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.

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.