Feedback - Skills Relevant in the Torah and Today

There is a story in the Old Testament known as the Waters of Strife. It occurs when the Jews were wandering in the desert. They complain to Moses that there was no water and that they were going to die. Moses prays to G-d, the response is to talk to a rock and tell it to give water. Instead of talking to the rock, Moses hits the rock and water comes out. Aaron was punished after this incident. Reading the text in the original Hebrew, Aaron wasn't given any instructions other than to accompany Moses, which he did. What did Aaron do wrong? Why was he punished?

At this point if you are still with me, you are probably wondering what this has to do with agility or Scrum. It was Rabbi Yehuda Meyers that gave me the answer to both of those questions, both what Aaron did wrong and what does this have to do with Scrum. Aaron's mistake was a simple and a common one, unfortunately one made on many Scrum teams. 

First, a bit of background is needed. This event occurs right after Moses' and Aaron's sister, Miriam, died. They were grieving and the Israelites again come to Moses complaining about water. By this time, the Israelites had seen many miracles. Each time they needed water it was provided for them. It is understandable that Moses emotions were probably running a bit hot and a bit raw at the time.

Rabbi Yehuda Meyers pointed out that it is not what Aaron did, but more precisely, what he didn't do. He did not speak up and give Moses clear and honest feedback on what he was feeling and seeing. Genuinely honest feedback is invaluable, but too many people hold back and don't offer feedback. Others have never been taught the skills on how to receive back, and many lack both skills to give, and to receive, feedback.

Scrum, and agility for that matter, are all about feedback. Retrospectives are for feedback about the team, Sprint Reviews are about the product, Daily stand-ups about the current state of the work in-progress. Members of every high performing team that I have worked with understood how to give each other feedback, how to work to help each other grow and improve. A high performing team understands that feedback is about helping each other grow, not about making value statements about individuals. 

For years I was very bad at receiving feedback, I felt that I was being attacked and that the feedback was about the value of me as an individual. I would become defensive and instead of listening well and making sure I understood what was being said, I would already be getting ready to refute their statements before they finished. It took me a long time to realize that it was not an attack on me, but instead was someone giving me information that I could choose to make use of, could ignore, or could put on a shelf for later.

Brian Harry has two blog posts that I have found invaluable when discussing feedback. I have shared them with many people when talking about feedback. The two posts are about learning how to give feedback and how to receive it. 

These days when I want to give feedback, I start by asking if the person I want to give feedback to is willing and able to receive feedback. Perhaps they are deep in a problem and do not want to shift away from it, or they just may not be a good mental state to listen. Recently a co-worker said no, I respected that. Later they approached me when they were at a good stopping point and mental place to receive feedback and we chatted.

Next, I make sure that it is clear that my feedback is not a judgement about the individual, but is given as something for the person to think about, they can choose to ignore it, sit on it for later, or act on it. I make sure it is clear that it is their choice, not mine, and that any of those choices are perfectly acceptable. Whichever choice they make is not my business, because as Sean Connery said in Finding Forrester, that is not a "soup question".

I then deliver the feedback in as constructive a way I can. Sometimes it is kudos for a job well done, I try to give positive feedback in public, hopefully modelling the way that positive feedback should be given, but also because others may then also say good job, and hearing that for a job well done is always nice. 

Constructive feedback I always give in private, this is something that only the recipient needs to hear. At the end, I ask if the person has any questions about what I said. 

As the last step, I always thank the individual for listening. 

Giving, and receiving, feedback is hard. People on a rock-star team need to be able to do both well. It is worth taking the time to teach and practice both skills. Here is hoping that you help your team avoid Aaron's mistake.

Stay Agile.