The Unspoken Hazards of the Retrospective

“Danger Hard Hat Area signage” by Kevin Jarrett on Unsplash

Disclaimer: This article touches upon sensitive subjects, but is not meant to criticise any individual or company. Far from it, the intention of the article is to point out how wonderfully diverse we are as a human race and how we can better grow together by recognising that. It draws on over a decade of experience from the writer, working with dozens of teams and hundreds of team members. It goes without saying that these are the personal findings of the author and not of any associated companies.

Ah yes, the retrospective! When I was first trained as a scrum master, some 7+ years ago, it was impressed upon me that the retrospective was the most critical meeting of the scrum framework. This concept was odd to me at the time, as very little attention was ever dedicated to it in the previous 4+ years I had been a team member. Indeed, I know of many teams and team members today who will often try to skip or rush it whenever possible.

Scrum is a ‘continuous improvement process’, and by that definition, it means that there is no such thing as the ‘perfect process’. There is always room to improve and that improvement is managed, by the team, within the retrospective. No retrospective; generally speaking, no significant improvements.

But there are severe and problematic consequences of having a retrospective if the wider organisation does not play its part in the process and if we do not recognise the psychological impacts of the human condition. To give away the ending to this article, the retrospective is fundamentally flawed. It assumes that people within a retrospective environment want to improve the process, their velocity, their tools or the company in general. This assumption is almost always certainly not the case or at least in the way a manager might hope.

To put it simply, if you don’t have the right culture in place, retrospectives can become a hazard to the companies health, rather than its saving grace.

What do People Want (Personal Values and Motives)

Generally speaking, I think it is fair to say that people want to do ‘good’ in the world. Let’s start with that, because its important to recognise. This good and what people value, however, is not the same for everyone. When people come into a retrospective, these values and possibly other not so benign motives will also come through the door and influence decisions. The question to be asked is, will a team member prioritise their personal values on that day over the team or the company? Or an even better one, will they even realise they are doing it at a subconscious level? I think it is fair to say that the person who sacrifices the things that matter to them (indeed, their very individuality) for the greater good of the team are going to be few and far between. There is also, nothing ‘wrong’ with that.

Just some of the random ideas going around in people’s heads might be:

• Personal relationships with team members (supporting them, even if they disagree with their idea).
• Keeping their job by hiding inability or low skill.
• Want that promotion and so value looking good over doing a good job.
• Introverted and feel uncomfortable speaking up (fear of rejection).
• Disturbances within family life and so want to keep change to a minimum in work.
• Want to master a new technology or tool (making them worth more within the job market).
• Projecting the importance of their values on others (usually, because they are good at them and to give them more self-worth).
• Wanting to be a master of their craft with little care for business or money.
• A contractor who doesn’t want to rock the boat and keep people happy, to secure that next contract.

The list is virtually endless, as we are all different and it takes an incredibly good scrum master or team member to navigate around these influences. I would say, it would take a superhuman to understand what everyone is thinking within a team dynamic entirely. We should never forget, however, that these values are significant to people and recognise that they might not align themselves with the direction of the team, department or company.

Once again, however, this assumes people know what they actually want. To ‘know thyself’ has been a goal since the ancient times, that few have mastered, let alone us mere mortals within the tech world.

So what counts as improvement and who defines it?

Company Direction & Culture

To be able to move the team or company forward, we are also assuming that this organisational unit itself, knows what it wants. It often doesn’t, and even at the top level, there are going to be conflicting opinions. It essentially needs to define the culture and values it prides itself in so that the team knows what to follow; otherwise, how do we determine ‘better’. There is, of course, no right answer and two companies may have two very different and contradicting sets of values. What is fundamentally essential though is that the company is honest with themselves (most importantly) and their employees about what those values are. For example, if you are making software for hospitals, priding innovation over quality (because it sounds good) is going to cause someone to have a ‘bad time’ when something fails!

It is doubtful, however, that a companies values are going to match up with those of every single team member. This idea is, obviously, normal but can become dangerous when you empower a scrum team with full autonomy. It often leads to bad decisions being made, which does not improve anything. Generally speaking though, people will play the game; they will tick the boxes against the culture slide deck or objectives that have been presented, while at the same time try and sneak in their own values. This is no doubt one of the drives behind ‘gorilla coding’. It is a delicate balance between allowing people individual creativity so that they care more and that of making sure people stick to the direction that the company wants to go down.

Can the Team Change?

There is no point having a retrospective if a team cannot change how it works. This sounds obvious, but it is all too common the case that people with good intentions will try to create the perfect scrum template and roll it out to everyone (remember what we said about perfect). Although this provides good stability it goes against the fundamental principles of agile; that is to say, it starts to choose processes over people. The team will no longer begin to evolve naturally and react quickly to change. Instead, they will place reliance and responsibility on an individual. If something goes wrong; well they were “just doing what they were told”.

In such scenarios, the retrospective becomes very limited, and people feel as if they can’t change anything. This doesn’t just stop at the scrum process, but all parts of their work that they interact with outside the team. Ask yourself this, does your team really have control over the following things:

• The product.
• The technical direction of the product.
• The tools they can use.
• DevOps tools and processes (this is a big one).
• How work (stories) are created.
• The core parts of scrum (sprint length, etc.).

If the answer is none or few of the above, then you could end up in trouble. Once a team feels they can’t change anything, they will turn inwards upon themselves. This is when the fabled ‘moan fest’ appears and rather than improving the process we end up with ideas, that are essentially meaningless:

• Try harder.
• Be more careful.
• Better communication.
• Better estimates.
• Care about quality more.
• Make sure to update items more.

You could say this in every retrospective ever, even if you were the best team in the world!

“If You Can’t Measure It, You Can’t Manage It”

Get to the Root Cause!

So what do you do if any of the items above come up in the retrospective? How do you as a scrum master or team member try to get to the root cause of the problem, even if you are powerless to change it. Ask, “how do we try harder?”, “what can we change to our process to make this possible?” or “What changes to our tools can we make sure this doesn’t happen?”. Humans are consistently prone to making mistakes, no matter how good you are.

If the same mistake keeps coming up, there are well-known methods within the tech world to help with many of them. You probably already have experts on your team! For example, if there is a complaint in the retrospective that bugs keep getting into the code, there are two things we can do. First, we could name and shame people, or we could start writing unit tests or automated UI tests. If estimates are so bad, then perhaps that says something about the complexity of our code base that needs to be addressed, instead of telling everyone their estimates need to be better. Perhaps we even need to send a team member on a training course.

More often than not, a problem that first comes to mind is not really the problem. With a little bit of thought and discussion, we can find out, and most importantly fix the root cause; stopping it from ever happening again. But keep in mind those influences of other team members, which might get in the way.

Chaos vs Order and Burnout

There is a delicate balance between the stagnation of total order and the insecurity of total chaos. The leaps of innovation, which propel teams forward tend to sit between the two. It can be likened to the makeup of our arms, which is made of rigid bone and flexible flesh. If our arms were made entirely of bone, then we would not be able to bend it or use it for any higher purpose. Equally, if it were made just of flesh, it would flop around, and we would have no control over this. A team needs to find out what balance works best for them.

Each person, however, will have different levels of comfort with change. If we push too hard, then they will push back (and not be happy). There will also be people on the team who constantly want to move forward and will become frustrated with people who do not want the same. There will even be people who have gone through so much recent change or are burnt out, that they crave stability.

So how can we deal with this? As always, there is no right answer. But I am sure people have experienced those retrospectives where we come out with 10–20 actions or changes to the process. No doubt, not even half of these changes were implemented before the next retrospective. On that note, we have to remember that scrum is an empirical process, with experiments happening every two weeks. The more variables we change in our process, the harder it is to work out the results at the end.

Sometimes the not so perfect approach is the best approach for the team, at that time. We can remember to take the same iterative approach to how we work as the product we are building.

Summary

In summary, we as scrum practitioners need to stop thinking that ourselves (most importantly) and our teammates solely want to improve how we work in the retrospective. Even at a subconscious level, there are other forces at work. We have to remember the human element in the equation of our process experiments. The organisation also has its part to play in guiding culture and direction, as well as managers who have their role to encourage the best out of people.

Perhaps one of the reasons why start-ups are so hyper-performant is that they are small groups of people, who have chosen to come together. This group is small enough to have a singular ‘group mind’, which they direct with full force towards a common goal with amazing results.

Let me finish with this. I by no means have all the answers to the points I have raised and no doubt my perspective will change over time. But next time you are in a retrospective, maybe you can take a moment to pause and remember:

• What do People Want (Personal Values and Motives)
• Company Direction & Culture
• Can the Team Change?
• Get to the Root Cause!
• Chaos vs Order & Burnout

Please share with all your friends on social media and hit that clap button below to spread the word. Leave a response with your favourite retro technique. 👏

If you liked this post, then please follow me and check out some of my other articles.

About

Matthew Bill is a passionate technical leader and agile enthusiast from the UK. He enjoys disrupting the status quo to bring about transformational change and technical excellence. With a strong technical background (Node.js/.NET), he solves complex problems by using innovative solutions and excels in implementing strong DevOps cultures.

He is an active member of the tech community, writing articles, presenting talks, contributing to open source and co-founding the Norwich Node User Group. If you would like him to speak at one of your conferences or write a piece for your publication, then please get in touch.

Find out more about Matthew and his projects at matthewbill.gihthub.io

Thanks for reading!