Agile Coach Toolkit #7: Straight Feedback

Allison, sorry for the late reply. Asking the feedback recipient her/ his opinion is important to make it a two-way conversation. Even the Scum Master may be mistaken, so this is a good opportunity for both the parties to have a meaningful conversation to clear the air provided feedback is very pointed to particular act and not vague.

After reading everything on the "Scrum Master Learning Path" up to this point, I wonder if that is really the recommended way, or maybe it is intended as an anti-pattern example? To me, it feels like superficially sweetened old command, control (and punish) approach, a high in vertical ranks ("may be a good idea to escalate to HR") Project Manager would like. It uses nasty actions like isolating from the team, eliciting fear ("making the heart pounding"), judgmental language ("I would like to give you feedback" - from the position of power), also they obviously will be scared by this behavior therefore "most likely agree". In my eyes all that works against the transparency pillar, values of openness (isolate the victim, so the team does not know what is happening, and is also afraid) and respect (I treat you like I train a dog - punish/reward when the incident is fresh - basic conditioning). So much for a servant-leader, self-organizing teams and psychological safety. My (courageous) improvement recommendation is to remove this article from the Scrum Master Learning Path altogether or make the contradictions explicitly addressed.

I read this post differently. I see this as a technique that team members would use with each other.

Giving feedback to peers is difficult, especially if there are emotions involved.

Going to HR does feel like a drastic step (but it may be called for). The more normal next step may be to involve the Scrum Master.

As a Scrum Master, I would want to teach this technique to members of my team.

To me PUSHing feedback does not feel like a soft skills mastery nor very agile. Actually, the person that can't resist the urge to rapidly express a strong subjective opinion about a teammate may be the trouble maker. I think, it is better to coach people to PULL feedback instead. In Scrum, Sprint Retrospective is the natural place to address team-players behavior in an open, respectful, transparent way. Simply raise the issue with the team, ask what everybody thinks about this moment, we are on a learning journey after all.

I agree that pushing feedback is not the best approach. I appreciate when feedback is 'offered'. I think that's how it's suggested in this article. "I would like to give you feedback." is an offer. It's not the exact language I would use, but it's still an invitation.

Yes, the Sprint Retrospective is a great place for this, but it's not the only place. The feedback may be sensitive and starting the discussion in a group setting may not be the best approach. Some people don't feel comfortable receiving potentially negative feedback in front of others. You may end up embarrassing a person in front of the entire team.

There are many valid approaches.

Why do you think that the person using this approach is a troublemaker?

The language does not really matter, it's just a (misleading) syntactic sugar to call it an "offer" or an "invitation" if there is no safe option to refuse.

It's a potentially dangerous pattern described as a generic one, also there is a risk that we are imagining quite a different case. I am just extrapolating the danger of flow described in the article, protecting the potential victims.

My understanding is: Person A owns potentially negative, embarrassing information about person B that gives A position of power. Actually, the power is big enough that A can decide (effectively threatens) to "escalate to HR" unless B agrees to take steps that A approves (effectively forces B to take). That makes A a power player and a troublemaker (quite popular pattern in command and control settings).

To me, scrum feels more like the team openly owns and resolves internal issues, serious or otherwise. The scrum guide reads:

"The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people."

During a sprint retrospective A obviously should not embarrass B with his perceived important feedback out of the blue, that would be another mark of a troublemaker. A should just gently put the empirical evidence under the team consideration. If A thinks B would like to know beforehand, sure have a casual chat, but no power plays! :-)

As you have noticed, I have not set any context on background of the situation. So I am assuming that the person giving feedback has done necessary due diligence and the situation required a conversation to happen. The aim of this article is to shed light on some ways to effectively handle giving 1:1 feedback.

Person giving feedback wants to help the recipient and needs to follow Scrum Values all the time. Article calls this out in the statements - "Give feedback with great humility, love and respect in mind when having such critical conversations. Remember your goal is to get the best of the person and make the individual excel in his / her role."

Getting HR involved is an extreme case when the presence of this person is threatening the self-organizing capabilities of Development Team and they don't feel they have a safe environment. In such situation, the HR intervention may be needed in consultation with rest of the team.

With the scenario you have described, I agree this may be a potential anti-pattern.

I understand what you describe as a feedback you mean at first critical feedback. For me is feedback not specific negativ or positiv. All is possible. Perhaps for American they say "great" and mean "ok". Germans normally mean what they say.
There is a sentence. Say critic face to face and tell compliments in the group.
Always if we give a feedback without invitation we create a hierarchy. Therefore it is always critical. So we need a learning atmosphere or frame for feedback. When we think it is a chance to get information for learning then all is fine. The reaction on a feedback can help the scrum master to see the member and his self-image for further feedbacks. On the other side transparency is one pillar of scrum. So to use honest feedback must be a goal for a team.

Feedback on the feedback video: Thought the concept of a product manger starting removing people of projects because someone receiving feedback did not agree on the feedback and did not take accountability on it, is something I would not expect to here in a source linked from this site.

Hm, I have seen some parts differently. I do think it is necessary to separate the person in question from his/her team, otherwise it would sound like scolding, and would elicit gossiping from people around. I feel it like a question of privacy.

As for HR involving, he is considering this step in case the person doesn't accept accountability, and well, the article doesn't mention, but from an AC/SM point of view, I guess everything would have been studied and evaluated before, and the coach is open for explanations. HR would come is the person is definitely responsible, but rejects to be accountable. There are people who are just not a good fit at the position, and even with scrum, some people will leave the team one way or another.

I enjoyed the article and find it useful, thanks! :)

My honest feedback is: It's really hard to come up with a blueprint of how to provide "agile" feedback. The reactions to this article themselves clearly show how sensitive a topic feedback and receiving feedback is. I appreciate Punit's attempt to make a suggestion and for sure there is some pretty valid food for thought. However, I strongly believe that there is no such thing as golden rule for providing feedback as you need to consider:
- character of the feedback receiver
- impact / consequences that come with the reason for this feedback
- impact for the whole team, incl. follow-up actions needed
- character of the feedback giver

Having this said, taking a walk in the park while talking can be a great idea in one case and a catastrophic decision in another.

I really believe that servant leadership is again key to success here. What serves the team best? What possibilities does the feedback giver have in order to lead here. And for those who think that servant leadership and direct feedback do not fit together, Socratic method may serve well here.

"HR!" - owner, owner proxy vs creator
I would look for a new job the first time I get approached in this way!

As someone new to scrum and carving my way through the Learning Path, I find this article utterly confusing. Who is giving and who is receiving the feedback in this scenario? Is it an ""Agile Coach"" talking to a developer? If yes, this feels extremely top-down and does not seems to fit with an Agile Mindset, as far as I understand it. Shouldn't a Scrum Master create an envrionment where the team members can give each other feedbacks in a safe and respectful way?