Retrospectives are great!

Retrospectives is one of the Scrum events that allows the team to inspect how they worked, their processes, their tools, their environment in order to improve.

The Scrum Master, the PO, and the Developers must attend the Retrospective. In theory, it sounds great, but what happens if it doesn’t go as planned?

Very few people talk

Retrospectives work great when people express what’s on their mind but what if they don’t?

I was new to the team & project and the team members had recently changed. I had a retrospective where only one person really talked, the rest stayed quiet. 

I tried to formulate the questions differently during the retro, I even asked people directly what they thought. The answer would be: same thing Bob said or I don’t have anything else to add. I tried to joke around but apparently my sense of humor wasn’t reaching anyone. Needless to say, that was one of the shortest retrospective I’ve ever done.

So how did I fix this? Did I just quit? NO! Remember, you are there to help the team improve.

one-on-one

First thing I did was  one-on-one with each team member. This means taking at least 15-30min talking and listening to them. One of them I ended up spending an hour with, it turns out he got used to no one listening to him so he stopped talking but he noticed that I actually cared so he had a lot of things to say.

When I spoke to each person, I explained to them that I was really there for them, I am not the one who will be doing their yearly evaluation, I am not there to point fingers. I want to help them to succeed as a team. This is the short part of the meeting, me talking. The longer part is letting them talk and me listening without interrupting (yes it’s easier said than done).

I told them I wasn’t going to tell anyone that it was them specifically who would tell me things. I can find ways to communicate information without divulging who said it.  I find it important to tell them this because if the problem is with the manager, I need to inform the manager that , for example, he/she is micromanaging and show the negative impact on the team. The fact that they knew I wouldn’t report them helped. I gave examples of this in the past. I saw that some people were initially afraid to say bad things and that it will get back to them or they don’t want to be perceived as negative folks.

At this point, I am starting to gain more trust from them.

Trust is the foundation

That was one of the problems of the retrospective, they didn’t trust me and each other to be able to express themselves freely.  Trust is the foundation. 

I asked them how they think the team is doing, what’s bothering them, what would they like to change, what is the worst pain point, and just let them talk.

team building

In order to build trust with the team, you need to do team building activities. You can do a 5min check-in before the retro, ask questions like “what’s your favorite food” or “what pet would you like to have”? You can schedule a one hour long activity focused on Team Building.

The goal is to get them to see that they actually have stuff in common with other people. Allow them to relate to each other, start trusting each other. This will make them want to help each other and not be too upset if the other one makes a mistake. It’s called being forgiving.

The moment I get the team laughing, I know we’re on the right track. 

clear to-do actions

The other thing I noticed was the attitude “what’s that going to change anyways”. Clearly in the past, despite having retrospectives, they didn’t notice any improvements, the same issues kept coming back. 

For this, in the following retrospective I made it clear and differentiated between issues that we as a team can tackle versus issues that is out of our control. The out of our control part is something I would work with the managers or directors and would give them updates on.

I focused on what the team can tackle and prioritized that with them. I asked clearly: is this something you can all commit to in the following sprint? I then reminded them at the end of some of the Daily Scrums that we had this retrospective action to do. 

When they did the retrospective actions and they noticed an improvement, it could be small by the way, then they gradually start believing in Retrospectives again.

Hopefully, if you try out these steps: one-on-one, team building activities, clear to-do action list , you will have better retrospectives. 

The famous saying goes: when you assume, you make an ass out of u and me.

I have not encountered one person who did not make any assumptions. At school, kids assumed things about other kids. “I bet Rachel’s dad is like that”. Teachers, themselves, assumed things about kids. “That child has probably been spoiled his whole life”. Adults, well, we are pretty bad.

It doesn’t stop at the work place, people still continue to assume. But at what cost?

I remember having a team where the developer went off to write the code without asking any questions to anyone, completed it, and when QA tested it , it flat out failed. It didn’t meet the requirement. Why? Because the dev made an assumption. In this case, it costs us several days, the dev had to redo his work and QA had to retest. 
(Note that a backlog refinement session can help address this.)

Now what if the Product Owner defined a series of user stories based on a wrong assumption? It would cost more than just several days.

As a Scrum Master, help the team understand the impact of making an assumption, and encourage them to make it a habit to validate (as much as possible). Use the backlog refinement session to ask LOTS of questions. You can ask each team member (especially the quiet ones) if they have additional questions, if everything is clear. Encourage the team to speak. Remind them: it is OKAY to ask. 

Pay attention. Here are some cues when someone might be making an assumption:

• it’s probably like that
• I think that’s what it was
• maybe this is what they mean

And as a Scrum Master, don’t forget, you too shouldn’t make assumptions!

Actually, none of us should make assumptions.

One of the books that had an impact in my life and which I strongly recommend is :
“The Four Agreements: A Practical Guide to Personal Freedom” by Don Miguel Ruiz.

 and one of the agreements is :

DON’T MAKE ASSUMPTIONS

When you think about it , it does make sense. Look back at all the times you made the wrong assumptions, what did that cost you, what was the consequence, who did it hurt?

What good is there in making an assumption?

How difficult is it to validate the assumption?

How difficult is it to move ahead without making assumptions?

Thing of all the times when you had an assumption, validated it, and worked with the right facts? Didn’t that feel good? Weren’t you relieved that you had validated it first?

Practice this daily: notice when you are making an assumption and validate if it’s true. You’ll start seeing things in a whole new light.

Why work with fiction when you can work with facts?

what’s your purpose

Do you notice yourself talking to a wall despite being in  front of a group of people looking at you? Do you get upset when the team isn’t doing what you are telling them, because your idea is the best one ? (well, so you think) . Why is it so hard for them to put the hours in their tasks at the end of the day?  I mean, it makes so much sense… (maybe to you but not to them)…

Why don’t they get you? Why aren’t they doing what you are telling them? 

How do you talk to your team? What tone do you use? What words do you choose to speak?

When you speak to your team, what is your purpose?

Is it :

• to inform them
• to motivate them
• to challenge them
• to enlighten them
• to support them
• to unblock them …

Hopefully it’s not to show-off.

What you say has an impact , so choose your words wisely.

You want to inspire your team, then why would you gossip about others. Why would you bad mouth others, the process, the management? What value does that bring?

You want to inspire your team, then why are you focusing on the negative things? 

You don’t understand why they don’t just do what you tell them because if they just do it, it will make their life easier?  You want them to change simply because you told them to?

Will you change if a stranger tells you to? Let’s face it, you still are a stranger to them, you are not family.

Let’s challenge the initial reason of why do you want them to change? Do they see any issues? Are you seeing issues that don’t exist for the team? Maybe the first step is getting the team to see the issues … or you realizing there isn’t any.

Be creative in how you bring the topic and guide them to see what changes they can do and how will it improve their work life. They will eventually come up with your suggestion or an even better one. Your solution isn’t the only one that can work, you have to remember that. Keep an open mind.

Let us be realistic, yes… pessimistic, no…optimistic, YES!  Despite everything that looks bad (a change in scope, environment issues, internet problems, access issues, lack of licenses), do you see that your team is able to deliver a product increment? That in itself is amazing!

What we are lucky to have, is a team. We are not perfect, but we are not alone. We have a team,  and they are amazing in finding a workaround, to deliver a product increment. So let’s focus on delivering something great. Let’s focus on the things that we can change. How about our attitude to begin with?

Remember

• What is your intention (inform, motivate, inspire,…)?
• Why do you want the team to change
• We are lucky to have a team