In my current team we have been experiencing some turbulence around how we work together as a team. The team is newly formed, and people have been unable to figure out how we should best work together. In a team of 9 people we have no less than 7 different countries represented, which makes communication and collaboration… interesting… One of our biggest issues has been around how we speak to and with each other, we have some who are timid, and others who have a tendency to roll over others who are trying to speak. We have also have some issues around knowledge ownership, knowledge sharing, and generally being respectful to one another. It was time to create some team working agreements, and this is the story of how we went about doing so.
The first and most important step in addressing deep team issues is realising that pretending like it is not happening will not make it go away. We are all uncomfortable dealing with the really tough and personal stuff, but is what you are currently doing really all that comfortable?
The best thing you can do is put it on the table, and in this respect all credit goes to the team members here, they had the courage to say that it was not working and this provided me the opportunity to facilitate them doing something about it. I felt a retrospective was the right forum to do this.
A team that doesn’t work well together is a very serious issue and you need to treat it as such, which is why I spent several days bouncing ideas off other Scrum Masters and planning a retrospective with the sole purpose of getting these tough questions on the table and addressing them in a constructive manner. I decided to consider this the most important conversation my team was ever going to have.
I wanted everyone to have the chance to mentally prepare themselves for this retrospective, I sent a mail explaining what we would be discussing as well as a collection of links relating to communication patterns, and team working agreements.
No one read the links, but I still think it helped them to mentally prepare 😉
Setting the Stage: (15 Minutes)
Different types of communication
I opened with a small (simplified) introduction to different communication patterns. I explained that some people communicate best in a linear flow where one person waits for the other to finish before they start speaking and that others use a zig zag pattern, building off each other and interrupting when they feel they have something important to say. Neither of these patterns is right or wrong, they are simply different and we need to find a way to mix them in order for all to be at their best.
Why are we here?
- We will attempt to create some simple working agreements to help us work together as a team.
- Team members must be on board with them, they are a group commitment.
- If someone does not agree with an agreement or is not willing to try it out, we will not have this working agreement.
- Any team member can call for a review of working agreements at any time.
- The benefit in being specific and writing them down is that we as a team are able to enforce them without people feeling they are being singled out, as the whole group works according to the same rules.
- In order to make sure we had a constructive meeting, I not only set out an agenda, but some guidelines on how we would conduct the meeting.
- Blame process, not people
- If we are having trouble, it is because we have not found a way of addressing it. It is not any persons fault.
- Be honest, and be respectful.
- Listen carefully when others speak.
- This does not only mean not interrupting, but actively listening to what others are saying.
- Please do not use your mobiles unless you receive a call.
- No interruption without permission (raise your hand)
- If you are worried you wont get a chance to make your point, write it down.
Gather Data (20 minutes)
Around the room
We had a quick go around the table to where each person was asked to express in a few words how they felt about topics such as meetings, learning from each other, team spirit. This was not a dialogue, only one person speaking and no interruptions.
I find using this systems helps to open people up and make them more communicative going forward in the meeting.
We then switched to our old reliable post it notes to generate topics for further discussion. People were asked to write post it’s that related to our ability to work together under the categories: Works well, Could be better, and Doesn’t work.
We then grouped these together into similar themes.
Generate Insight (30 minutes)
We then started having discussions around the groupings that were created. The objective in this section is not to propose solutions, merely to understand the problems more deeply.
This part was excellent in my opinion, people were open and honest with one another, while at the same time being respectful. We managed to ”put a lot of things on the table” that we had been dancing around for a long time.
The ”don’t interrupt, and write it down”-rule was very effective.
Decide what to do (15 minutes)
The team proposed simple counter measures to attempt to address these issues.
We then used a thumbs up (”I think this is a good idea”), sideways (”I am not sure but I am willing to try it out”), or down (”I actively oppose this action”) system to decide which items we make part of our working agreements. The idea was to not implement anything that received a thumbs down, but nothing did. This was mostly do to establishing that any team member will have the right to call for a review of these items at any time.
The result was the following agreements and principles:
Be respectful of others.
Do not interrupt.
There are NO stupid questions.
Do not make people feel stupid.
We are one team, we succeed or fail as a team!
Being on time:
Be on time.
Inform if you will be late.
When leaving the room, remind others of the meeting.
Going off topic on discussion:
Use the communication pattern from our retrospectives.
Write down the question, summarise the conclusions, note the action points.
Discussions in general:
If reading is needed for a meeting, communicate that, and read it.
Raise hand to interrupt, if you are worried you will forget, write it down.
End meetings 5 minutes early.
Have a knowledge sharing Fika.
Create a backlog of knowledge to share.
The one who knows, creates a simple view reviewed by new team members.
Create a guide of must know on the wall.
Write down “how to’s” instead of code walkthroughs.
Anything considered “obvious” should be written down.
Allocate time when new team members are joining, with a specific mentor.
We managed to put a lot of important questions and issues on the table and discuss them in a open and honest manner. People were almost always respectful of each other, which is hard when dealing with such sensitive issues.
I think that the time I spent preparing was very well spent, as I don’t think the discussion would have been very focused otherwise.
One team member felt they were being targeted with the discussion about lateness. This was a real shame, especially since that was not the intention at all. This has been a problem since I have been with the team, and with all members. But he is new, and often late, so he felt we were talking about him.
Also, he made a very fair point, we spent too much time talking about lateness. It could have been a 5 minute discussion which took 30.