TL;DR

The second talk was about how to give and receive feedback. As software testers often bring bad news, mastering feedback is one of the essentials skills. Let’s learn about feedback.

Crystal Onyeari Mbanefo presented Exploring different ways of Giving and Receiving feedback. The day before, I was in the same group with her in Fiona’s workshop. Our group task was providing feedback :).

Crystal presented her role as emotional skills explorer. She started with basic feedback rule:

Feedback goal must never be changing another person’s behavior.

A student is learning on a train and is distracted by a child that is playing and makes noise. A student asks parents to quite their child.

Let’s redefine feedback:

• Perception of giver
• Understand receiver
• Communicate giver perception

There is no right and wrong party in feedback. Feedback must start with a common goal.

Regarding the hierarchy, we could have:

• top => bottom
• bottom => top
• teammate <=> teammate

In top to bottom feedback, receiving end could have the following feelings:

• shame
• blame
• fear of failure

Receiver end has the following emotional needs:

• heard
• accepted
• respected
• belong
• appreciated

After feedback, giving end must be careful not to put the receiver into the following states:

• hurt
• worse relation
• demotivation

Here are tips on how to provide feedback to an employee:

• employee empowerment – what would you do instead of ordering
• coaching using questioning – do not provide answers

In bottom-up feedback, we have a different situation. Management must empower fear-free zone to get feedback in the first place. The giver must not use anonymous feedback, which is someone else gossip. Also, without providing feedback, management could miss important information. And EGO must be turned off! We must be aware of our blind spots and vulnerabilities (for example, we do not understand some domain rules or technology used in the project).

In teammate feedback, Crystal used developer and QA as an example. The team must establish a common goal. Developers create and QA tries to “break” (my comment is that software is already broken, QA provides working examples). The team must communicate about common goals. These could be established quality criteria, finished user story, or feature deadline. If a common goal could not be reached, then it is ok to have our GRRRRRR! moment, let your emotions out!

We have a four-part Nonviolent communication model:

1. Observation
2. Feelings
3. Needs
4. Request

Here are Crystal tips. Observation is not judgment. When we state our feelings and needs, we do it in no request mode:

I need to get to the airport …

vs

Get me to the airport …

With received feedback we:

• achieve growth
• trigger relationship (mother/daughter)
• get truth
• get our identity (conference speaker)