One of the basic skills of members of agile teams is the ability to give feedback to their colleagues. However, basic agile approach training usually does not provide any guidance on how to provide feedback. And so it happens that the transmission of feedback sometimes ends in the emotions of both participants or, in the worst case, in an unconstructive conflict. Sometimes you can give feedback right away, and other times you need to prepare thoroughly. So let’s go through at least a few basic recommendations on how to do it.
Recommendations for preparing and passing on feedback
- Give feedback in person, the written form is not suitable. You need to see and respond to the recipient’s reactions.
- Nothing is just black and white. Therefore, always highlight the strengths of the feedback recipient.
- Development feedback:
- Try to make it impersonal. Ideally, your wording makes it clear that you are giving feedback on a particular pattern of behavior, not on a person. If the evaluated person realizes this and at the same time perceives the positive feedback that you gave earlier, he leaves the discussion with honor. He knows you’re talking about a pattern of behavior to change, not one. He usually has no need to react irritably.
- Wrong: “You don’t know how to lead meetings at all.” (I primarily evaluate a person)
- Better option: “Facilitation of workshops is not optimal. You let the participants take their word and the meetings drag on.” (I primarily evaluate facilitation)
- When giving feedback, don’t exaggerate, but don’t downplay the lack you’re describing to the recipient. You are here to make the recipient aware of which pattern of behavior to change and it must be understandable to them from your output.
- For feedback, you must always have specific examples of when a specific situation that you are evaluating occurred. Sometimes it happens that he is not aware of the deficiency being evaluated and only a specific example opens his eyes. Feedback without concrete examples will often be incomprehensible to the recipient.
- Beware of putting your own assumptions or feelings into the feedback. Always stick to the facts so that the receiver knows exactly what to change and the assessment is constructive.
- At the end of the feedback session, you can ask the recipient which part of the feedback was useful to them and why, and which was not.
Feedback provider and recipient
- Do not invent corrective actions for your colleague. It is necessary that the proposal for redress comes from him and you only discuss with him whether the solution is adequate to the situation.
- If it happens that he is evaluated in emotions, it is better to interrupt the conversation for some time. In such a situation, the feedback recipient may no longer pay enough attention to what you are saying. Nothing is eaten as hot as it is cooked.
- Don’t let feedback be given to those who don’t know anything about the problem. The feedback forwarder doesn’t have enough information to answer questions that the recipient can ask. At the same time, prepare in advance for questions that may arise.
- Last but not least, it depends not only on the feedback provider, but also on the recipient, who must learn to accept the feedback.
Think about where you’ll give your feedback. For non-trivial things, it’s best between the eyes. For example, when you try to give more challenging feedback to a colleague in front of the whole team, the colleague may feel threatened and perceive the feedback as an attack. In a threat caused by feedback given in the wrong place, the result will only be a defensive reaction, not a proposal for a solution.
Keep in mind that not providing feedback usually has worse consequences than providing it on time and well. Well-presented feedback will clear the air in the team and help the team improve. Remember this, even if it’s a step outside your comfort zone.
The success of giving feedback also depends a lot on the quality of the relationship. Otherwise, the recipient will receive feedback from the person they see as an enemy and otherwise from the person they have verified is not profiting from the feedback. So his feedback is selfless.
What you said to yourself during the feedback process will remain confidential. The team can learn from the evaluator what solution they have come up with, but everything else should remain non-public. Feedback that the evaluator does not respect the confidentiality of information can bring him or her to the trust of both the evaluated person and the whole team.
I would like to thank Roman Slobodník for his help and addition to the inputs to the article.