Note To Self Retrospective

post-it-notesWe have recently gotten a few new team members, and we started to get to a size where we felt it was no longer practical to be one team. So, we decided to split into two teams.

Because of this split it felt kind of strange to conduct a traditional retrospective as we could not commit to actions as a team. So, I decided to try out a different format which turned out to be one of the best retrospectives I have ever had.

Note to Self Retrospective

I got the idea from this post: http://www.funretrospectives.com/note-to-self/ which I modified slightly to be more fit to our purpose.

The basic idea is to have people reflect personally, and come up with something they personally want to change in the future.

Preparation

On the whiteboard I wrote some simple introduction text so everyone would know what this was all about.

Purpose: To improve yourself

Goal: To create one actionable item for yourself and experiment with a new behaviour, practice, attitude, or method in the coming two weeks.

Output: A Post-It note for your screen or laptop to remind you about this change.

Agenda

Introduction (5 minutes)
I simply showed everyone the into text and agenda for the sessions, and made sure everyone understood.

Reflection (15 minutes)
During this time people think and create their notes.

Discussion (15 minutes)
I made it clear that passing was totally acceptable during this phase so people could feel free to be as personal as they wanted. No one did. We discussed as a group what everyone decided to do.

Feedback (5 minutes)
A quick go around the table to see what people thought about this activity.

Conclusions

The Good

This was a fantastic retrospective! Primarily because people ended up going much deeper than I expected they would, and shared very openly with one another. Results are at the end of this post.

One team member commented that sharing them aloud was very good, because then you felt more committed to achieving it.

It was also super quick, 5 minutes to setup and ended up 30 minutes to execute.

The Bad

Not everyone’s takeaways were actionable. Maybe that’s OK, but I like actionable.

The Output:

People were so open they even said I could post the result here! I had them as a picture but the quality was bad, so I typed them. Some probably require more context to make sense, but I will post them without that.

”Keep Back
Don’t code alone
Don’t offer solutions directly
Wait until asked for help”

”Proactively deal with upcoming issues”

”Spend more time reading up on items and be more thorough.”

”More structure for retro output
Book time for debrief/admin work after each retro.
Document output.
Follow up.”

”Stop worrying about everything”

”Improve knowledge about (component name)
Get to know team members and their roles.
Get to know my own role in the team.
Get to know everyone’s name, role, and skills.”

”Less sarcasm.
More listening.
Better at (component name).”

”Self confidence over all.
Believe in myself and my work.”

”Be focused.
Don’t waste time.
Be more motivated.”

”Listen More”

Annonser

Establishing Working Agreements

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.

Getting started

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.

Preparation

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.

Ground 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.

Content Generation

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 output

The result was the following agreements and principles:

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.

Knowledge Sharing:
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.

Conclusions

The Good:

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.

The Bad:

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.