Blame it!
No Public Blame
In the basic retrospective formats like "What went well? What didn’t?", everyone has the option to state things about the last sprint. Things that worked out well - the plus side - just as things that didn’t work well - the negative side. Now there’s usually only a single rule for almost any retrospective format: Public blame is not allowed.
In this blame-free environment it can be pretty hard to associate negative messages to the source. How would you be able to deliver a negative message without the option of blaming?
The following article will give some tips on better message transportation and why there are retrospective games that seem pointless at first.
A Simple Example
Imagine a wide spread source of misunderstandings: Peer code reviews. The more experienced team members will give input to the less experienced ones. At times this input may be just too much to handle. The less experienced colleague will try to absorb every bit of information but still fail to get it all. To the senior colleague this might look like the junior was not listening.
Sure, this example requires that the senior doesn’t realize that the junior is already overstrained by the amount of information and the junior is not saying stop at the right time. And still this happens a lot.
Now imagine that this issue accounts for some of the team - you won’t approach every single one of the colleagues and tell them that they "forget things" throughout the review. What the senior will do instead is to write down and go with this note to the retrospective.
A Basic Retrospective
No matter if your retrospective is made up of two (+/-, …), three (PMI, …), four (KALM, …) or five options (starfish, …), blame messages must be undirectional. In such a format, there’s almost no way of stating "Max missed a lot of information from the peer code reviews" in a way that it’s still "blame free" but directional.
The correct statement on your canvas would rather be something like
"Peer code reviews were mostly working well but are sometimes not friction free"
Ok, nice. But not directly helpful. The message may find its way to the correct peer, yet chances are high that it ends up in something like
"That’s not meant for me because I was always eager for input" "That guy pushes too much and I will ignore for me" "There was some noise? I don’t care."
Four Sides of the Message
The four sides of the message model is a common way of describing the different ways a message is transported and therefore also consumed between sender and receiver.
Nuances in the formulation can already change the recipient’s understanding a lot - without the sender actually realizing what happend.
This is especially hard to handle with critisism. In order to avoid bad message reception it is important to change the format of the message to be transported. In the next chapter, I will try to formulate messages in a more recipient friendly way - without loosing context.
Now blame it! - but without blaming
The Scrum Guide states "The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.". There’s actually no restriction within the the format to gain the improvements.
As a Scrum Master, it is my objective to read between lines, hear what is not said and create an environment, in which my team is able to identify any problems on their own - including the solutions.
I for myself take a restrospective as a good one if I do not have to take any actions to the next sprint, that are just team internal. Because those are the topics that shall already be discussed and closed throughout the retrospective.
Examples of problems and solutions:
-
Communication doesn’t work well. Maybe one of the team members is not co-located with the rest (different office, different room)
-
Perform an exercise/theatre, where that one person not co-located is now co-located and someone else, maybe one that you know doesn’t see the problem, becomes co-located. Ideally with glass walls, such that the one person can see but not hear the rest of the team. This exercise may build a lot of awareness and gain solutions quite easily.
-
-
The team misses creativity.
-
Create nonsense. Maybe via an energizer like "What are you doing?". This exercise from Hyper Island has two messages: Have some fun ideas. Wrong expectations can lead to unexpected outcomes.
-
-
Expectations of each other do not match.
-
Has your team ever talked about expectations? In a focused way?
-
You could try "Gifts and Hooks", which is a great exercise to tell each other what one brings and what one needs from the team. Such exercises can create a common understanding in the team - immediately.
-
This is an especially good exercise to work on the "Peer Code Review" example. Try it - it works.
-
-
The team is settled to old behaviour.
-
There’s another energizer that I took home from #ALI2019: "clap on go"
-
We have all learned to clap on 1, 2, 3 - this is common. This simple exercise has the great message, that you need to unlearn from time to time in order to succeed.
-
Tell people to clap on the word 'go'. Say '1, 2, 3' - some will already clap. Say '1, go' - some may miss the signal. And so on - until everyone learns to clap on go.
-
-
And never forget about the simplest way of producing a better feeling: Appreciation.
Conclusion
There are a lot more exercises that can improve your retrospectives and your work. Most of them are simple and don’t take more time than the simple good/bad format - but their outcome may be a lot more. Think about it, just like I did.
