The idea for this post came to me when reading this article on Harvard Business Review.
This part made me reflect on how we do software development:
If we really embrace this rule as a team, there's no escaping, you'll have to give/receive feedback at some point.
As a Scrum Master it's my job to make people aware of the importance of feedback. I often see two things happening:
- Giving feedback: some people are hesitant of pointing something out if it involves a colleague. "What if I'm wrong or my colleague doesn't like what I'm saying?" Let me turn it around: What if you're right and you didn't point it out? This moment was a chance to improve and we didn't grab it.
- Receiving feedback: some people feel threatened because they see feedback as a bad thing. Once you see it as an opportunity to learn, you'll grow much faster as a person.
How to give feedback?
The following steps should make giving feedback an opportunity to learn for both parties:
- Name (not judge!) the behaviour you're seeing, the moment you see it. If you wait too long, the behaviour will be forgotten and the message is not as strong. Talking about the behaviour, not the person, is key in this step.
- Tell the person how you interpret this kind of behaviour and what effect it might have on the team.
- Propose a new way of behaving in this situation and see if you both can agree.
Don't let emotion get in the way of providing feedback. By keeping it factual, there's a bigger chance that the recipient will accept the feedback.