In this post I will continue to challenge the 12th principle of the agile manifesto to explain other ways to spice up your retrospectives.

The 12th principle says: “At regular intervals [when?], the team [who?] reflects on how to become more effective [what?], then tunes and adjusts its behaviour accordingly [for what?]”.

This time we look at how the team can adjust its behaviour…

One of the assumptions of a retrospective is that the team should come out with concrete action items they will work on to become better. While this is the preferred way, it is not the only one. Consider the following example:

I was coaching a team and I noticed during their demonstration that the software had many faulty situations that were reported with a popup dialogue. The team members demonstrating the stories just merrily clicked “Ok” and ignored the issues.

In fact, it was like they did not even see them and nobody in the audience seemed to care. During the retrospective, done with a “Mad-Sad-Glad” I wrote the problem on a red post it. When voting, my post did not receive any vote – so the team ignored my issue. Curiously, though, the amount of errors popping up in the next demonstrations decreased visibly, becoming zero after 2-3 sprints. Months later, in an occasional chat with a developer, we discussed about this and he said the very fact I reported the problem and made it “official” to them was enough for them to individually take corrective actions, even though the retrospective did not “produce” anything concrete in that respect.

In each retrospective there are various effects that work on the team even when they are not captured on todos: sensemaking, showing the elephant in the room, clarifications among members, better understanding of your colleague’s mental models. All these items are implicit knowledge gathered during the retrospective and they might work “behind the curtain”, though, unfortunately, we cannot control what is really being learned and acted upon.

Of course when you are facilitating a retrospective you should try and have the team committing on action items, but in my experience there is an important learning even when the action items are not as neatly described and committed as we usually hope.

In the next post I will discuss a few tips to improve your retrospectives: stay tuned!