Team Feedback?

A couple of years ago I started working at Mindera, which is a self-organised company.

Six months into it, I wrote a post describing why it was refreshingly different.

Well, a lot has passed since then. I’ve worked on five different projects, with different teams. Each has a slightly different MO (modus operandi) but all of them follow Mindera’s principles of feedback over evaluation. VERY simply, that means that we don’t have performance reviews, where someone defines objectives and, after some time, checks if you achieve it — I won’t detail this very much as this would be a post of its own.

Anyway, in practice, this means that we should give feedback spontaneously on a day-to-day basis. Besides that, as most teams use scrum, with all the ceremonies (grooming, planning, retrospective, etc… ) that means we also have a retrospective, where we can discuss a period of 15 days behind.

So, why did I write this article?

After some time I felt that the feedback wasn’t fully working. I felt that (at least on the teams where I was integrated) we lacked one thing: a common time for the entire team to really stop, relax, and talk about how we feel, what we like and dislike, and how to improve as a team and enjoy our work even more. Yes, most of us gave feedback to one another, but…

You must be asking yourself, “well, what the hell are retrospectives for”?

Well, as I said, we do work in scrum and have retrospectives. But retrospectives end up being more focused on the project at hand, not on the team itself — at least from my personal experience. I envision a session focused on the team. If we are enjoying working with each other, how we can improve and be even better at working with each other.

Do we need this?

Well, I found out that there were very simple questions that I could not answer:

• What’s the thing that the person on your left most dislikes that some/all team members do?
• What’s the thing that a person on your right most likes about the team?
  

Maybe you can also think about those quick questions (those are just a few examples).

But…

Do you know this? If you do great then maybe you don’t need this!

If you don’t, maybe you agree this is important. Maybe you disagree and find that this is too personal. Anyhow, give this article a chance and read the next couple of paragraphs.

I can only advocate that whenever I could answer those questions the teams where I was working were far more proficient and pleasant to work with. The experiences I had are not even just from IT teams or self-management ones. I used this method on different teams from very management traditional teams to volunteer teams that run summer camps during summer…

Still, this is just an opinion and it’s one I truly agree with…

“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” Jim Barksdale

So check this Google’s study on what matters to a team’s success.

You are probably coming here from an IT perspective so remember that, although we program, we are not machines.

Want to try it?

Sceptic or not, do you still want to try it? It’s simple…

This won’t be a very tidy nice manual. It uses the mindset of agile. When we code, we build, break, and fix things.

In feedback, we try, experience, share our experience, and retry.

Purpose

Remember, the purpose is to create more awareness of the state of each other. As a team,  that can a lot of times, improve both.

Facilitator role

You will need a facilitator. Probably it will be you, since you are reading this, but it can be anyone on the team. It is simply the person that will make sure the schedule runs smoothly and defines the time limit.

Also, it will need to explain the purpose and MO to the rest of the team and will help move the session forward if it becomes ‘stalled’.

During the first session, it can either be from the team or not (if you feel more comfortable in having someone guiding that has done this before), but if you make more sessions the idea is to make the team autonomous.

This role can obviously be done by a different person for each meeting (or always the same).

That person is also responsible for having all the materials needed ready before the session starts, which are:

Material

Timer: we use a real Time Timer 12’’ but even an app on a tablet works – it just needs to be big enough so that everyone can see it easily. 1 sheet of paper + pen/pencil per person.

Before

First of all, this kind of session only makes sense if the entire team wants it. It means that each person needs to be open to receiving and giving feedback. The facilitator, or the person that schedules it, needs to be sure this truly happens. Never force someone to go to one, it will only backfire.

During

IMPORTANT: This is a NO laptop, NO phone session.

It’s short (normally one hour). So, let’s stay focused.

A model that I suggest as a starting point

Put the timer somewhere that is visible to the entire team during the entire time. The time the facilitator defines is strict. When it ends, the session ends no matter where it is. Note: as a reference, we normally use one hour for four to five people. I’ll use that number as a reference for the times described below.

Having the timer visible for everyone is very important, as it reinforces the time left and avoids having a never-ending session. This forces people to be concise.

Remember, when the timer hits zero it ends. This will ensure people are focused and speak only what is core to their feedback. If a session ends without being finished, next time either the time needs to be increased, or people will need to be more disciplined.

Part one  — retrospective

This will take five minutes.

• Facilitator: describe the questions that people must answer.
  

We normally point to two questions about everybody else in the room and one about one's self

• Facilitator: after explaining, set the timer for five minutes.
  

People should use that time (in silence) to write on a piece of paper.

Some examples of questions from sessions we already had:

Example one: questions about others in the room:

• Three things I can probably help the person get better at.
• Three things I would like the person to help me get better.
  

Example one: questions about yourself:

• What would be the simple indulgence or gift they would really appreciate when tired or under stress?
  

Example two: questions about others in the room:

• Three things that the person does that really improves the team.
• Three things that the person does that has not a very good impact on the team.
  

Example two: questions about yourself:

• What you really like (something that really pleases you about your work).
  

Those are just two sessions, do you have more examples?

I’ve added (a lot) more examples here, to make it even easier, and I’ll keep on adding more as I test more during my own feedback sessions.

You get the point, now you have the ball, reuse questions or make your own.

Part two — feedback

When the timer (set to five minutes) hits zero it’s time to reset it. Set it to 55 minutes and start the feedback loop.

How does it go around?

Feedback loop

• The facilitator asks for a volunteer to be the first person to receive feedback. It can also be a random person (just avoid losing more than one minute with this).
• The person on the right of that volunteer starts. The idea is to give feedback (basically, the answer to those two questions defined above).
• When the first person finishes, it rotates to the right to give an opportunity for everyone to give feedback about that person (until it reaches the person receiving feedback).

Comments and feelings about the feedback loop

• The person receiving feedback now has the time to talk a little bit about the feedback received. This isn’t supposed to be a discussion, just share thoughts and feelings on the feedback received — if relevant.

This is not mandatory. This step can be skipped if they don’t have something to say.

Share personal question

• After that, it’s time to share the answer to the personal question.

We had a funny case where we were bumping our fists on the table when something wasn’t working and it turned out that this was really annoying to someone on the team. This person only spoke out during this session when answering the aforementioned question, even though he had been working with us for some months already.

Repeat

• Repeat until all people have received feedback.

Facilitator: remember to make the people be aware of the time available. Normally, a good way is when you reach half of the time make everyone aware of that, and also when there are 10–15 minutes left.

The feedback session has finished: should we repeat?

Facilitator: be aware, the last five minutes are reserved. They are meant to be used to speak about the session (anyone that wishes, without any order):

• Has it been useful or not? Why?
• Do you want to repeat it? Why?
  We have now reached a point where we dropped this part, as the team assumed that this was a good thing, and was added as a default meeting every month.

An iOS team during a feedback session with part of the team remote

That’s it?

In the end, if this helped the team (even if in a tiny way in your day-to-day life) then it worked.

If it didn’t, well, glad you tried it but you either don’t need it, or you may need a different thing.

Just a few more things…

• Did your team have one?
• Was it useful?
• Did you follow this exact process or did you tweak it somehow?
  

If you have a couple of minutes please drop me a message on Twitter to share some thoughts on this, so we can improve this post!