This is the second article in a mini-retrospectives series. In the previous one I talked about how retrospectives should be done at regular intervals, but also in other occasions. 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 the team: usually the retrospective is done within the team, but in some cases there might be somebody more or somebody less…
Retrospectives can be done at different levels in the organisation. Sure, the team’s one is the most popular, but there are also other ways to run retrospectives:
- Inter-team (they are actually a common characteristic when scaling agile to a bigger organisation)
- Management team
Done in this way, the retrospectives are a way of making sense in the whole organisation and there is a grey area between what is then a retrospective and what are other techniques for fostering communication in a company like open spaces, project kick-off and so on. The definition I propose here is that we should call retrospective a meeting that “looks back” at the past in some ways in order to define how to do things better. I found this definition good enough for the typical practical situations.
Retrospectives involving a more composite audience require usually the organisers to bridge some gaps as not all groups in a company perceive the need of a reflection in the same way and at the same time. Sometimes it takes a significant effort just to convince the relevant actors to sit around a table, even in the case where they all run regular retrospectives in their departments.
An interesting case of retrospective with more than the team is when meeting a client or suppliers the team works with: these are often great opportunities for methodological clarification as well as way to lower the communication barriers. While some of these results can be achieved in other ways – notably team building events, common social events, … – doing it as part of a retrospective is a way to achieve the same effect on the interworking between the two groups while, at the same time, solving some more petty issues that would have anyway to be solved, like getting a proper speakerphone, define some core communication times, … Furthermore, doing it as part of a retrospective means it will happen when the team feels the need to, not imposed by an external authority, i.e. it is also a useful team learning.
Sometimes retrospectives can be done in a smaller group, like with a subset of the team, in order to discuss a certain topic.
While in general we should anyway try and extend the discussion at least to the whole team, there are situations where a smaller circle is needed. Typically in case of conflicts, where we should initially try and solve the issue with the people involved rather than with the whole team. Though you might use some kind of retrospective format, you do not necessarily have to call it like that.
Another case is when only a part of the team has the necessary competencies to address the situation. In general we should try and avoid it also in this case, as the discussion will provide a good learning also for the rest of the team, but when the topic to be discussed is so obscure that it would cause a big part of the team to fall asleep, well, better in a small group then.
Here are some typical situations:
- Conflict among a small group of team members
- Local situations in a distributed team
- Process issues relevant only for a subteam
Let’s state it again clearly: while this might be an option, the goal is still to try and keep the discussion open to the whole team in order to favour transparency!
In the next post I will discuss one more way to spice up the retrospectives: stay tuned!