How to start building a functional team with a retrospective
This post is based on my personal experience and a little help from the model “the 5 dysfunctions of a team” by Patrick Lencioni. Both tend to help me quite a bit in my role as an improvement mentor (or agile coach when using a more popular term).
The reason for me to write this article is because a) I still come across quite a few pretty dysfunctional teams that b) have no idea how dysfunctional they are and c) tend to turn their retrospective into a boring meeting, resulting in d) the absence of any significant improvement cycle or learning loop.
Proper inspection isn’t just a skill, it is a friggin’ obligation for any team that aspires to be taken seriously. Perhaps I should be glad that the lack of it justifies the job I’m in 🙂
Let’s get on with it.
I believe proper inspection usually isn’t done when something is wrong within the team. The Lencioni model shows that absense of trust leads to fear of conflict which then leads to lack of commitment. And that’s the point where things fall apart.
Many a team’s members are quite capable of speaking up to the point where conflict arises. Please note that my point of reference here are the Dutch, who are quite known for speaking up, no matter what. From the discussions and even conflict emerge pretty clear ideas about what can be improved. And that’s where it ends due to two main reasons:
- The rat race that seduces us to always appear busy makes sure that any improvement action remains unwritten or is moved to the bottom of the backlog as fast as possible.
- The complexity of the issue at hand (or the lack of proper understanding of it) initiates a severe cause of amnesia, affecting everthing related to the problem at hand. Especially the desire for constructive action.
And then a team’s performance quickly grinds down to a boring state where busyness rules and results come in big chunks over large intervals.
Consider these 5 steps to upgrade your retrospectives to the next level and escape professional stagnation:
- Make sure the entire team attends the retrospective and everyone is encouraged to say something during the session. Try a perfection game where everybody speaks up about what he or she liked about the period under inspection and what could be improved. As soon as people start dominating the session, involve the less dominant people while still respecting everyone. Also encourage people to listen to each other instead of them just getting ready to speak their own mind again. A base for trust can be established by proper facilitation, which is what I am referring here to.
- Identify potential conflicts between what people say. Encourage the participants to bring data to the table to back their statements. The presence of data often softens the sharp emotional edges and provides new angles to look at the matter at hand. Find out if there’s a real conflict or just a misunderstanding. Stick with it until the conflict is resolved. Working explicity with a conflict makes a team more experienced with conflict management. It contributes to a sense of safety and helps surface real problems (or improvement opportunities if you like).
- For anyone to commit to something, especially an action, absolute belief in the validity, the urgency, and the importance of it needs to be present. Keep in mind that NOT everyone in the teams needs to agree on an improvement action or even the problem behind it. The point is that SOME people understand the need to change something and commit to take action. Instead of asking everyone to agree, try asking if anyone is really against a certain action or really doesn’t agree that something is a problem. That will either generate meaningful new insights or gives a number of people within the team permission to go ahead and experiment. An alternative is do discuss the consequences of not solving the problem to see if that changes opinions.
- Write. it. down. Especially those actions that are agreed upon during the retrospective. Also agree on a definition of done for the action and write that down too. Don’t force anyone to be the owner of the action. Also don’t force a deadline for a solution. Instead, put the action on the iteration backlog so it will come under the attention of the entire team every single day during the daily planning. That’s where team accountability starts. Obviously all this requires a seriously dedicated process coach if the team’s process IS the problem…
- Celebrate the results of the improvement action (change, lessons learned) at the iteration review or kick your butt for not even getting a lesson from it. Really: if any improvements were planned but none were delivered, make it visible by showing a big ZERO somewhere. For everyone to see. Remember that any iteration review is about deliverables, improvements, and planning for the next iteration. Don’t restrict yourself to just giving a demo. Put showing improvements and sharing lessons learned on the agenda. Also when zero.
There you have is: 5 steps that look pretty easy…but are not. Until you really try them. Then it becomes addictive.
As a bonus, consider these helpful ideas:
- Take the time to both identify problems and then find their root causes. People often underestimate the time it may take to only identify and agree on a problem. It may be very helpful to spend one full retrospective just on identifying and agreeing on a bunch of problems, then take a break for an hour and do another retrospective where your teams focuses on truly understanding just one of these problems and writing down some improvement opportunities.
- The mimimum time to be planned for the restrospective of any team lacking serious problem solving skills is 1.5 hours. And that’s still pretty conservative.
- Establish trust upfront within your team by agreeing on some professional ground rules. Consider agreeing on when and how to start team sessions, what to do when you don’t agree with someone, how to deal with disruptions duing a session, how to bring bad news, how to reind each other of promises that were made, and so on. Just don’t write a rule book. Agree on those few rules that require the team members to be a bit more conscious about their behaviour. Which rules apply is up to the team to decide.
- Reward the team for team outcome over individual contribution. Really. The opposite will make any attempt at creating a team fail. Don’t coach or facilitate such teams without deeply considering what you’re up against.
- Allow your team to be properly facilitated. A decent Scrum Master will do the trick (almost as often as it will not). Have someone from outside guide the team in having discussions, agreeing, defining actions, and helping remind each other. Only as long as needed of course.
- If, even with decent facilitation, the team keeps losing its energy over inspection, consider changing the team composition. When many teams within an organizaton suffer from chronic loss of energy, even after changing them a few times, then it’s about time to inspect that organization’s leadership 🙂
Try finding more practical aid in my other articles.