Lessons learned after 8 years of giving feedback…

The best lesson I’ve had on giving feedback, was when I was just starting out as a coach. I was working with this Cobol team, almost all of them had been coding since before I was born.

I was doing my best to help them, however feedback sessions never seemed to go that well. Half of them would become missed opportunities. What I was doing back then, was trying to follow a framework for feedback, I had previously learned from a different Agile Coach.

Feedback framework which I’ve learned more than 8 years ago

On the bottom is the person that is receiving the feedback, on the top is the person giving the feedback. Normally, if both people know this framework, the conversation might go well.

However.. this is where reality sets in:

1.      The person you want to give feedback to, might not know the framework. (assume that in almost all the cases they don’t)

2.      The person you want to give feedback to, might not want to hear negative things about themselves. (no one wants actually)

3.      The person you want to give feedback to might have a very different perspective than yours and may also have additional information which you don’t have.

4.      You might be dead wrong and really making a mistake thinking that your suggested action is a great thing for the other person. It’s a bit arrogant, if you were to ask me now.

It’s not that the framework is not good per se, it is to some extent. Some good points which anyone can take from this framework:

1. Giving - Observed behavior: definite YES! The feedback conversation is lost the minute the person you are trying to give feedback to does not agree with what your are saying. Keep it as objective as you can.

   • Examples:

     • I’ve noticed that you were late in 3 of this week’s Daily Scrums.

     • I was looking at the git pull records and I’ve noticed you were not able to create a pull request for the story that is marked as done.

   • Don’ts:

     • Do not give general examples. The more specific the better.

     • Do not wait 112312093109 years before giving the feedback. The sooner the better. Ideally when things cool down (in case of a heated situation).

     • Do not use the following or similar words: always, never, often, likely, etc. Fun thing here: when someone approaches you using something like “You always do..”, they are trying to give you feedback, they just don’t know how to do it. Be patient and get to the very specific thing they are trying to communicate.

2. Giving – Pause: yes, yes and yes. Do not let the conversation escalate. Pause often and listen!

3. Receiving – Listen: yeah. Definitely. More on this in the Active Listening Section

4. Receiving - Ask for clarification: yep. Keep asking those questions until you reach the specific thing you can make better in the future.

5. Receiving - Thank the person: Seems appropriate. I’ve haven’t done it that much. But it’s a nice way to end the conversation.

Back to the story. I was really puzzled and struggling to figure out why this was not working. One day when walking back to the hotel with a colleague, I brought this issue to his attention. His response was one of the best I’ve had until then: “Why don’t you try, just having a conversation?”

So simple and yet so effective.

So the “framework” for feedback conversations why I use now when giving feedback.

1. Before you go in clarify the following:

   • What is your goal for the conversation?

   • What’s in it for you?

   • What’s in it for them? (More in the Creating a higher goal section)

2. Objective statement: I was looking at the stories we have prepared for the next sprint. Some only have the title. I’d like to go through them together with you, a tester and a dev and do a bit of refinement before our Pre-Planning session. (3 amigos technique)

3. Ask an open-ended question: What do you think about this?

4. Listen and don’t try to steer the conversation where you want it to go!

5. Repeat steps 1-4 until you reach consensus. Use the Creating the higher goal technique in the Handling Conflicts section.

When receiving feedback:

1. Listen (Check out the Active Listening section for quick tips on active listening)

2. Ask open ended questions

3. Find a suitable solution

   • Sometimes you need to tell people: Look, I do understand where you are coming from. All I can do right now is this:…. And I can do this so that it does not happen in the future.

Active Listening

This is the best skill a Leader needs to possess, next to Asking Open Ended Questions.

Quick tips:

There are 3 Levels of Active listening. There can be more but these have been useful so far:

1. Not listening. This is when you are talking on top of the other person, or listening with the sole intent of replying, or having your mind going on and on about something.

2. Attentive Listening. This is the first step in listening to a person. You are trying to understand exactly what they are saying and what they mean.

3. Active Listening. This is where you are not only listening to the content of the conversation, but also listening to their emotion, possible things that they might not be saying, etc. This is where your intuition really starts playing a big part. When I practice active listening, for example, questions just pop-up and they are very spot on.

The best way, I personally know, to practice Active Listening is: Don’t start to talk, until 3 seconds of silence have passed. If there have not been 3 seconds and the other person has started talking, let them. They will eventually finish. Personal record: listening to someone for 2 hours, almost straight.

Handling Conflicts

Conflict types

There are 3 conflict types. As before, there can be more, but these are the ones I’ve found useful.

1. Solution level conflict

   • This is there we agree on the goal, but we are at odds about how to do it. Example: Tabs vs Spaces.

   • One thing that helps here would be: What’s the simplest thing we could do, or Let’s ask the team, see what they think.

2. Goal Level Conflict

   • Here we don’t agree on what we want to achieve. Ex: Product Owner wants to deliver the feature on time, I want to protect my team from overtime.

   • Getting to a higher goal can help here. Ex: Let’s do a re-prioritization and see what we can fit in and what we can take out.

   • One of the concerns here is if the other person has a hidden agenda. This might not be something that you can solve, without other people being involved.

3. Emotional Conflict

   • I win only if you lose type of situations. If we both win I lose.

   • This is very tough to overcome, if not impossible. Here I usually recommend people switch teams.

As non-licensed therapists, we need to understand that we can only fix Level 1 and Level 2 type of conflicts. We are not therapists. Great therapists usually have sets of skills, we don’t and years of training, which we don’t. So my recommendation is: Don’t try to fix emotional conflicts.

Creating a higher Goal

This is my favorite technique for solving conflicts. It starts with the 3 questions which I’ve mentioned earlier:

1.      What is your goal for the conversation?

2.      What’s in it for you?

3.      What’s in it for them?

The “What’s in it for them?” is actually very tricky. Our egos may fool us into thinking we want the best for them when all we do it paint what we want as in “the other person’s best interest”.

Example: Our stories don’t have written test scenarios

BAD What’s in it for them: they will cover all scenarios

GOOD What’s in it for them: They will write great, reliable user stories. They will decrease the amount of back and forth with the developers. We will have lesser quality issues, less clarifications to give, etc.

Now that you’ve answered the 3 questions and have a clear idea of how we can move together as a unit in the future, you are ready to face the thunderstorm.

Asking Open Ended Questions

This is one of the most important skills of a leader. There are 3 types of questions:

1. Yes/No – Simple, direct. Create black & white scenarios

2. Fixed answer – School type questions: What did you forget to write down in this user story? – really annoying; don’t do this.

3. Open ended – Multiple answer questions. There can be many possibilities when answering these questions. They engage creativity and logic in the person that is answering.

• What are your thoughts on our user story writing technique?

• How can we improve the way we communicate with the team?

• What are your thoughts on..

The more you practice Open Ended questions the better you will get at it.