Retro Is Broken

🗓️ 2020-08-01

⏲️ Reading time: 5 minutes and 47 seconds.

Delivery teams are focusing on the Wrong Things

I have participated in more Retrospectives than I can count. Years and years of working with dev teams has given me an insight into some antipatterns which are causing the failure of not just continuous improvement, but are causing teams to actually diminish their effectiveness and productivity.

Antipattern #1 : It’s all about US

So many times I have seen super-awesome change-agents, transformation coaches, Agile leaders, practice leads (and more) who are playing the “popularity contest”.

This is disguised as “a people-centric approach” or “it’s the teams who are the most important” etc. It is a beautiful sentiment, and makes the participants feel special, important - valued. This is great, it’s good for morale, and as they say, “happy workers work harder”.

Yet - focusing on the people has a significant negative impact on the outcome of any transformation effort. This negative impact is brought about by re-orienting the focus of the delivery teams at themselves rather than the customer.

By focusing on themselves, retrospectives tend to be filled with these kinds of lean-coffee-tickets:

  • Team lunch was great :)
  • Sorry to see John leaving this week :(
  • Only 5 broken builds this sprint! :)
  • Well done team! We smashed 10 bugs! :)
  • Why are we using Jenkins not CodeBuild ?

Etc…

Not one of these tickets will result in an action that enables greater throughput or reduces wait times, more on this later.

Antipattern #2 : The Three Wrong Columns

Almost all the retrospectives I have witnessed have some variant on this:

1. What went well
2. What didn't go well
3. What could be better

Some creative facilitators use a sailing ship analogy:

1. What put wind in the sails
2. What dragged us like an anchor
3. What could scrape barnacles off the hull

It’s all the same. And none of it has anything to do with continuous improvement, transformation, or VALUE. More on this later.

Antipattern #3 : Five to Ten minutes to write up your tickets

Lean coffee format. How many times have you heard this question:

Are you familiar with the Lean Coffee format?

Followed by a sequence of furrowed brows, academic-sounding recitals of such-and-such a blog post, possibly dropping the name of x, y, or z consultancy and capital-A Agile methodologies of course. Lean Coffee is, after all, what ALL the Agilists are using.

The Lean Coffee approach is fundamentally flawed if applied to retrospective. Putting participants on the spot basically forces them to come up with anything they can think of. This is what leads to the “team lunch :)” tickets everywhere.

The team is working really hard every day, when it comes to retrospective they are relaxing for the first time in probably two weeks. It is unrealistic to expect that all the members of the team will remember things that happened 8+ days ago that had an impact on their productivity, especially if the areas of focus are vaguely, or not at all (like most places I have worked) defined.

Countermeasures

#1 - Understanding what Continuous Improvement is actually FOR

Defining a target for improvement sounds obvious doesn’t it? If the target was, “make sure the team is really friendly with one another” then yes, putting the participants on the spot with 5 minutes of Lean Coffee ticket-writing at the start of the retrospective is fine.

When the REASON for a transformation is actually (sensible) to realise value sooner, unblock the value stream, minimise waste and deliver value TO THE CUSTOMER more efficiently then suddenly “team lunch :)” type tickets have very little reason to appear.

By working with the team(s) to develop a deep understanding of their professional and commercial objectives within the wider transformative (or continued) improvement effort will have an impact on the team’s self-image as highly-skilled, important and VALUED participants.

Declaring these objectives and framing them as PROFESSIONAL conduct, part of any team member’s role and responsibilities will elevate that team member’s idea of their place in the business. Not just “we all love you, you are ‘valued’” (which is warm and fuzzy, but it’s vague, and … well, fluff) - but providing tangible, definitive explanations of these words at a professional level.

#2 - Collecting Improvement Items Continuously

This is another obvious-seeming activity, but I have witnessed delivery team members actually push back on this suggestion claiming that it is “not worth it”.

By placing a post-it stack at every team member’s workstation (I have seen the digital equivalent of this tried a lot, and fails every time) and reminding the team members to write down something that just happened that ought to be improved the items that are presented at retro are real-life events, VALUABLE to the team.

This requires some coaching at the outset, where the team is still learning the meaning of “the 7 types of waste” (for example) and needs some encouragement to take ownership of their team’s destiny, so to speak.

When something happens that causes problems, such as:

* too many forms to fill in
* too many clicks, pages and noise to release something
* a person's "doing" column filling up too fast
* too many bugs causing work items to go back to dev
* the system architecture and organisation layout causes one team to wait for another
* too many meetings!
* etc

These events can be written onto post-its at the time so they are not forgotten. Writing these up as they happen also improves the quality of the information around these moments, such as knowing “how many minutes/hours I had to wait” for example.

Where it is simply too much hassle to convince people to keep notes on their desk, something I have seen working is for the coach / scrum master / etc to nominate themselves as the official recipient of retro items.

“Send me an email when you encounter a problem”

This enables team members to write a detailed account of their issue, and know that it will be actioned and possibly even investigated for retro. This will improve even further their sense of being valued, listened to, taken seriously.

#3 - Positive Reinforcement Is Still Important

Earlier I noted that the format of retrospective is broken, however for a process of continuous improvement to succeed improvement actions should be monitored.

This is what the “what went well” column might have originally been used for?

To repurpose this column for the checking of improvement actions will enable the team to gain insight into the effectiveness of their improvement initiatives. If an action meant to improve productivity (see countermeasure #1) is not improving productivity, or has an unforeseen impact on another person or process then it is up to the team to re-visit this improvement and re-work it, try try again.

Yes People Do Matter

Of course people matter, their wellbeing ought to be at the forefront of everyone’s mind! Each member of the team ought to be considering the health and wellbeing of all of their team mates, and everyone the interact with in the world.

In terms of Agile ceremonies, while coaching has placed a special emphasis on things like “respect”, this emphasis has become the focus.

Health, happiness and wellbeing ought to be woven into the fabric of the social side of “when we are at work together”.

Happy workers work harder, sure. But even the happiest workers in the galaxy will still produce less when their delivery is hampered by irregular work items, overburdened process, unnecessary waiting, and those people who are frustrated by these things will in fact, become less happy as a result.