Categories
Agile

Common Retrospective Challenges

I often hear about poorly run retrospectives. Below, I’ll describe a few different common problems and some ways I have addressed them. Beyond what I list below, you may want to learn more abut how good facilitation can help any team.

Common Challenge #1: Skipping The Retrospective

The most common challenge for the practice of retrospectives is pretty simple: many agile teams just don’t do them. It can be tempting to skip the retrospective, or allow teams to cancel because “there are no issues to discuss.”

I’m no longer surprised when teams I start working with aren’t holding this ceremony. It takes time, is challenging, and good facilitation of any meeting takes skill. So the retrospective is frequently the first thing to be dropped.

However, in agile, continuous improvement is really important. The difference between a good team and a high performing one lies in retros. You won’t see the kinds of amazing things high performing teams can deliver if you don’t take the time as a team to evaluate what’s working, and what you might try differently.

Teams not seeing much benefit in agile practices need the retrospective to find out why. Good teams need it to become great. Great teams need the retro to stay great.

Hold regular retrospectives for the same reason you take your car to the mechanic. You don’t just take your car to be looked at when it isn’t running at all; you also take it when you realize something might not be working as well as you’d like, and for regular maintenance to keep it running well.

I’ve been asked many times by people new to agile, “When can the team stop having retros?” The answer is when you are perfect. (In other words, from my perspective, never.)

On rare occasions I have worked with teams that proactively address issues throughout the sprint and therefore rely on retros less. However, even mature teams need time set aside to respond to change and improve process together.

To avoid skipping this valuable ceremony, whenever possible, schedule it ahead during a time slot when all team members can be present and emphasize the importance of attending.

Common Challenge #2: Too Short

It’s almost worse than skipping the retro if you aren’t setting aside enough time for discussion. One scrum master I had the pleasure of listening speak on this topic called these PDQ retros: Pretty Damn Quick.

Through the hundreds of retrospectives I’ve facilitated, I’ve found anything shorter than 1.5 hours doesn’t allow the group to dig deep enough. Your experience may be different – and certainly the length needed varies by the team.

Too short of a retro gives you the illusion that you are tackling all team issues while allowing some issues to remain unaired. It takes time for some challenges to be discovered and fully understood, and sometimes the most impactful topics are the most difficult to raise, or aren’t surfaced until the easier and more visible challenges are out of the way.

There’s a few recommended ways to determine the length of time needed for retros that you’ll find if you Google it: from 2 hours per week in the sprint, to 20% of the sprint length. This is never a palatable amount of time for teams or businesses to spend when first adopting agile. Underestimating the value of retrospective practice costs teams much more than the time required for this meeting, but some people and some organizations may need convincing.

One thing you can do if you have pressure outside, or even inside the team to keep this meeting short is ask to try it for the duration you believe best for a few sprints and re-evaluate after. Remember the goal isn’t perfect, it’s just better, so after a few sprints, ask if the parties pressuring for shorter retros still have concerns and work together to find a way forward that everyone feels good about.

Another approach is to schedule them for shorter time slots and limit discussion to a few topics. Set a timer so you leave enough time to wrap the meeting with action items. Work your way into longer retrospectives by proving their value through action item follow up and resulting measurable improvements.

Common Challenge #3: Lack of Constructive Discussion

Another common scenario is lack of constructive discussion.

I see this most when running the retrospective without setting guidelines for appropriate discussion. It’s so important to set the expectation of constructive discourse and ban blaming, shaming, and naming.

The Lean practices of Kaizen and Hansei are one way to approach this. Kaizen is the idea of change for the better – often referred to in the concept of continuous improvement. Big results come from many small changes accumulated over time. This means everyone making small changes and improvements, and involves introspection to discover what you yourself could do better (or are good at and can build on).

This goes hand and hand with Hansei- the idea of acknowledging your mistakes or weaknesses and offering ideas of ways you can improve. Encourage individuals calling out their own faults or issues and things they could do better next time. Other participants must listen objectively and keep feedback positive.

It’s much less threatening for a team member to acknowledge their own shortcomings than it is for other team members to call it out. If your retro takes a turn in the direction of personal attacks redirect. Remind participants, that we’re all in this together. If you can reword comments in a constructive manner and remind participants of the expectations for discussion.

I try to start retros with the Retrospective Prime Directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. In other words, we did the best we could. It can help to note that if we could do better we would like to, and that’s what this meeting is about, improving.

Emphasize that we, as a team, through action or inaction, are all responsible for the outcome of a significant event, a sprint, release or project. It is an art to guide discussion to protect individuals but allow the sort of introspection that helps to improve teams. Once you allow one blamer, shamer or namer, the rest come out of the woodwork, often in a defensive posture to scapegoating.

Discussing things from a team responsibility perspective allows the team as a whole to discover ways to address problems and opportunities. It is a powerful feeling to see an opportunity to improve and identify how you might contribute to that, by choice, by building on your strengths, or by trying something new.

Common Challenge #4: Participants Don’t Feel Safe

Lack of trust sets up retrospectives to fail. Missing trust can happen in the beginning stages of a team, when action items are not followed up on, when management or leadership uses feedback discovered in the retro against the team or as a result of numerous poor retrospectives involving lack of constructive feedback that have made discussion feel unsafe.

You can help with trust issues by telling the team the retrospective discussion is private, feedback is anonymous and asking what teams are comfortable sharing outside of the meeting and then following through, every time.

You can gauge the trust in a group by running a Safety Check and addressing the issues preventing safe discussion through a Creating Safety retrospective.

It is essential to address issues of safety before holding a true retrospective as the team will not discuss openly when they do not feel safe to do so.

Common Challenge #5: No Action Items or Action Items Are Agreed Upon and Forgotten

One of the goals of the retro is to agree upon action items and then act on them. Strive for 1-3 action items that the team has agreed to try. If you find your teams ending retros without action items consistently, or agreeing on action items that go no where, that’s a problem!

Ensure action items result from the retro by reserving time for action item discussion in the agenda. Set a timer or have a time keeper help.

After gathering data and generating insights, use filtering techniques to decide what to do.

Ensure action items are acted upon by creating cards, estimating them and tracking them on the agile board, just as you would any other work your team does. Set aside a percentage of every sprint for team improvement work.

You can use a checkout activity like Who What When (found in the Fun Retrospectives by Paulo Caroli and Taina Caetano) to garner ownership of these action items within the team.

Just as important is following up at the next retro on what you did and asking the team, did it make a difference? You could set aside the first 5-10 minutes of retro discussion to review your action items and gather feedback from the team.

Common Challenge #6: Repeating Themes

Repeating themes are a call to action. Issues that come up again and again could mean you haven’t tackled the issue fully, the issue a bigger problem than the team and requires escalation or that the team doesn’t have the tools it needs to address it.

In the case of repeating themes, consider a retro focused entirely on this persistent issue. Preface the session with a description of the problem and what you have tried and ask the team to brainstorm for ideas they haven’t tried yet.

The repeating issue may be one that the team doesn’t think they have influence over. Try using the Circles and Soup technique to reveal what the team does have influence over.

One team I worked with had the same issues come up every retrospective that were organizational issues needing a manager to escalate them in order to solve them. Sometimes the things you can’t change are the easiest to want to change.

You can use Madhavi Ledalla’s Fly High retrospective method to get the organizational blockers out of the way (and compile a list to escalate) and then focus on items within the team’s control.

Common Problem #7: Rigid, Unchanging Approach

You want your team showing up for retrospectives ready to discuss whatever issues, concerns and opportunities that may come out of open exchange. You want your participants engaged.

If you are using the same retrospective method every time (what did we do well, what could improve is one common example), your attendees know what you are going to ask of them each time and you may not be getting the chance to spark creative solutions. Sometimes participants have pre-rehearsed answers, even pre-written post-its that can disrupt the flow of natural discussion and discovery.

It is important to keep the discussion alive and interesting. This can be done by varying check-in and check-out activities as well as the main retrospective itself. Asking the question of how we can improve in a different way can help the team think about it’s challenges differently.

I recommend researching what techniques may help the team better discuss challenges and successes. Carefully consider a retro design for your participants that will be most effective. Make your retros engaging and fun.

Some team members may feel uncomfortable with varying technique, so you can give participants an idea of what’s to come with an agenda prior to the meeting as well as labeled sections on the white board (or large stickies) in the meeting room so they know the general areas we you cover.

Spend time planning activities and have everything set up in the meeting room ahead of time.

Consider the team’s disposition (generally, and at the time of the retro). Some teams love to do something creative like a quick drawing as a check in / set the stage portion of the retro. Some teams don’t like this kind of activity at all.

I track of everything I have tried in retrospectives I’ve facilitated and which things are good for different desired outcomes. When planning a good retro, my focus remains on what success, challenge, or conflict I am seeing in the team, and what issues remain unsolved to help decide on a retro technique to try.

For yourself, create a library of techniques that you can pull from. Good sources include Derby and Larsen’s book Agile Retrospectives: Making Good Teams Great, the Retro-Mat website (Corinna Baldauf) and Fun Retrospectives (book or website) by Paulo Caroli and Taina Caetano among many. One Scrum Master I know uses Pinterest as a source of inspiration. You can also alter techniques to get different effects, and or try something brand new.

Consider a 5 stage or 7 stage agenda to surface team challenges and find your way to action items.

There are different methods to spark discussion on different topics, to build the team, and to discuss team goals. It’s a good idea with a new team to try techniques that encourage the discussion of working agreements, role expectations, the behaviors or attributes of a model team member versus the behaviors or attributes of team members that are not easy to work with. Discussing future desired state is a great idea as well.

There’s More: Resources to Read More

This is just a starting list. Others have written about common ailments and ways to tackle them. If you think you’re retros could go better, you’re probably right.

Categories
Agile

Retrospectives for Everyone – CodeMash 2016 – Resources

Materials

Slides: Retrospectives for Everyone

Photos from Session

The Path to Nirvana 1: Now

Where your team is now

The Path to Nirvana 2: Next Step

What’s the very next step you can take towards the ideal state

The Path to Nirvana 3: Ideal State

The perfect team environment

The Flying High Technique

Identifying challenges within the team’s control and challenges at the organizational level

Resources

Online

Books

  • Agile Retrospectives: Making Good Teams Great by Esther Derby and Diane Larson
  • Fifty Quick Ideas to Improve Your Retrospectives by Ben Williams and Tom Roden
  • Fun Retrospectives by Taina Caetano and Paulo Caroli
  • Gamestorming: A Playbook for Innovators, Rule Breakers and Change Makers by Dave Gray
  • Getting Value out of Retrospectives by Luis Goncalves and Ben Linders
  • The Retrospective Handbook by Patrick Kua
  • Retrospectives for Organizational Change by Jutta Eckstein
Categories
Agile

Don’t Be a Jerk

From 2008 to 2010, I had the unique experience of working overseas in Sweden. It was a fantastic opportunity, and I learned a lot about how cultural norms can differ. Workplace norms are not the same everywhere in the world – and this was surprising to me.

I had assumed that working in IT would be nearly the same. Programming in Sweden was very similar to programming in USA- all of the programs were in a language I knew (English), and the technologies I used were familiar. My keyboard had some extra keys on it, and surprisingly, this threw me off for the first month or so. I kept accidentally pressing the wrong keys, and that led to slower coding.

The cultures in the various offices I worked in were vastly different. From the moment I entered my first interview, this was clear. Instead of focusing on my career highlights and my strengths and weaknesses, hiring managers wanted to know was I fully rounded individual? What did I like to do in my spare time?

The norm in USA of talking up your experience and skills was not acceptable in the humble company of Swedes either. This might have been the hardest adjustment for me. To me, finding a job and standing out against other candidates meant aggressively selling what I could do. To the Swedes, this seemed like the boasts of someone who liked themselves a little too much. I had never looked at myself as being someone who was full of themselves, but to survive in Sweden’s job market, I needed to tone it down.

Another thing that struck me, again and again, was the power of shared expectations. In Sweden you were expected to follow certain cultural norms, and everyone I met did things to help you know what was expected of you. On the bus, someone would helpfully remind a gentleman to give up his seat for the elderly, or else every occupant would turn an angry eye to the man who did not give up his seat for an elderly woman. That peer pressure was powerful.

People said what they meant. If a friend said let’s get coffee, they actually meant it. We better be getting coffee!

In one office, we had coffee break or fika, every day in the mid afternoon. I can verge on workaholism, so my teammates would subtly stop by my desk just before to encourage my attendance.

Even living in Sweden, the government encourages you to understand the country and fit in. I am a Swedish citizen, but I was not fluent enough in Swedish and was encouraged to attend a free class to learn the language and culture better. For this small nation, gentle cultural guidance helped those not used to the expectations to fit in.

In the same way, Agile teams can use their defined cultural norms to help new members onboard, and to encourage each other to be better team members. This can be done in many ways, but the retrospective is one of my go-tos.

I may not have posted about this here yet, but in my daily life, I say all the time that one should vary retrospective methods. It is truly the most powerful tool in the scrum master’s toolbox, and using the same method every time is like using a hammer for every job around the house. You might get some things nailed in, but you’re likely to get some dented walls and fixtures too.

One method I like using in retrospectives with new teams, or with teams in which it seems like discord appears to be growing, is to define our team’s working relationships with “That Guy, This Guy.

With this method, after reminding the team about the Retrospective Prime Directive, the team works to define the kind of team member that is difficult to work with (Don’t Be That Guy) and the kind of team member they love to work with (This Guy Rocks!).

I did this retro with a team I worked with in the last year. The That Guy, This Guy artifact became their playbook for their team. Take a look at some of the qualities that That Guy has versus This Guy.

ThatGuy

“That Guy” passes the buck, isn’t accountable and closes new ideas down. The phrase, Don’t Be That Guy takes on special meaning when we define the behaviors that make it hard to work with someone.

ThisGuy

On the other hand, look at the qualities this team defined for the sort of person everyone enjoys working with – proactive, helpful, and willing to pitch in. Everyone wants to work with “This Guy.”

Agile is all about raising accountability for all team members and pushing the team, and the individuals in it, to be their best selves. As human beings we like examples of what that means. For each team, this may look a little different. It depends on your business, the products you work with, and your processes.

A similar retrospective method I’ve used is called Ground Rules, which is especially appropriate to use in the formation of a new team. The premise is similar – how do we work together best – what rules do we agree on and what new ones should we consider? These rules then can be passed on to any new team member to give an example of how the team expects members to behave.

In summary, these retrospective methods really boil down to the team defining how not to be a jerk. They arm the team with a way of calling out what their preferred behaviors are, and a playful way of saying, hey- This Guy Rocks!

This is super important in agile teams where the team dynamic has more potential than ever to slow down productivity if people don’t play by the rules, or conversely, produce more than ever as the team gets better at working together.