Distributed teams pose their own challenges. One the challenges I want to discuss today is people in a distributed team giving feedback to each other. Early in our professional career, we learn not to use mail to provide feedback. Mail is not good at conveying emotions so you should always do it face-to-face. Only use mail if you are going to deal with facts. I still agree with this, but only when you are working as a co-located team so with people at the same location and with people that see each other regularly. I worked with teams in India, the US, Belgium and Romania and it is sometimes very difficult to find the time to provide instant face-to-face feedback. There are loads of reasons for this such as time-zone differences, public holidays or just busy agendas. Feedback is best served hot. It should always be given as quickly as possible. When giving feedback to someone about something that happened a week ago, the feedback has lost most of its value. So, if feedback by mail is seen as poor communication, and there is a big risk of misinterpretation of your message, how do you still do it?
What I found very useful is using the feedback wrap as described in #Workouts by Jurgen Appelo. It is a wrap, not a feedback hamburger: “You did a great job last week, oh by the way how you could write that piece of code, but still a big thanks for the great paper you delivered this morning.”
The feedback wrap will give you a structured approach to provide feedback. It will help you make your feedback more constructive and it will minimize the risk of miscommunication. The feedback wrap has five steps:
- Describe your context
- List your observations
- Express your emotions
- Sort by value
- End with suggestions
When I worked as an Agile Coach at a certain company, there was a VP Product Management that lived abroad with a time-zone difference of 9 hours. As you can imagine this person had a very busy agenda. It was extremely hard to get a Skype meeting with this person. The company was just getting started using Story Points and this particular VP had decided to use the number of story points delivered by the teams as an MBO for the Product Owner of that team. When I heard about this, I thought…, well let me not repeat what I thought… let’s just summarize it as “Jeezzzz…”. So, I decided to give him feedback about this. Note that I actually had no real involvement with this person: I was not coaching him, I was not hired by him, I had not met him in person (yet)… so how to give feedback and make sure he would not be upset, or worse? I was a bit afraid to give him the feedback.
I started my mail with providing some context first. I was in Eastern Europe at the time and it was hot, more than 34 degrees Celsius. Therefore, I had already slept badly for a few nights. I told him this for starters and I also told him that I was a bit annoyed about some discussions with some people, and what the impact was for me. So he knew I was not in my best mood.
I then shared my observation with him. I kept it as clean as possible, and presented it just as a fact. I said, I learnt that story points are being used as MBOs. The real description of the observation was a bit longer of course :).
After sharing this, I described what it did to me, in an emotional way. An observation is an observation, when you describe it correctly, there is no discussion possible about it. Your emotions are your emotions. No one can say your emotions are wrong or not allowed. They are your nonnegotiable feelings. I simply stated the observation that story points are used for MBOs which made me feel sad and also a bit upset. In the description of the feedback wrap, you will find that the next step in making the wrap is too sort your observations by value. However, I often also find it valuable to take some extra time to give some more information about the situation. In my case, I explained my feeling upset by stating why it is a bad idea (IMO) to use story points in combination with MBOs. In short, I was providing my reasons for feeling sad and upset about the observation at hand. When you provide feedback, you also need to try come up with suggestions. The VP was trying to motivate the product owner to increase the output of the team. I made the suggestion that we could introduce a Definition of Ready to improve the efficiency of the Scrum Team and therefore also the output. Finally I offered my assistance to implement the Definition of Ready approach.
So I sent the mail and waited… Would he be upset, disagree, escalate to higher management? Within a few days I got an answer from him. He agreed with me and he thanked me for my feedback. He changed the MBO directly and wanted to think about how to implement the Definition of Ready.
I am not saying using the feedback wrap will always give you good results. However, it will help you to provided feedback in a structured way.
I realized that using some kind of template makes it easier to provide feedback. But as with every template, it is just template. Use it as a starting point and change it when you need to change it.
One other important lesson is: take your time. Do you know any people who tell you to just write a quick mail? Trust me, writing a good email, and definitely a feedback wrap, is not done in five minutes. Make sure you take your time, writing a good email can easily take up to 30/45 minutes.