Giving feedback is one of the aspects I like most about agile methods. There’s this thing about it though — it’s not that easy to give effective feedback. Lately, I’ve heard agile team members start their feedback with the following statements:
- I don’t want to rain on your parade, but
- I don’t mean to be negative, but
- I don’t mean to criticize, but
- I don’t mean for you to take this the wrong way, but
Ricky Bobby phrases it best in Talladega Nights. The first time we hear Ricky Bobby say, “With all due respect,” is after Ricky has cost his racing team 100 points for flipping the bird on TV. If you haven’t seen it, watch it ASAP.
Clearly none of these prefaces are honest or effectively mask the intent of the person giving critical feedback, but often they provide a useless buffer.
Consider the outcome
I would encourage everyone in agile instances to be more thoughtful with their feedback. Remember, your job isn’t simply to “say it,” it’s to say it in such a way that it’s effectively received and drives the changes you are trying to influence.
What I’m trying to say is that effective feedback should be measured by the outcomes that it inspires and not by the simple fact of saying it.
Here are a few other key considerations to think about before you give someone feedback in your next sprint review/demo, retrospective, or other agile ceremonies.
- Have you prepared to give the feedback or are you just reacting? Often reacting in the heat of the moment is a bad idea. Give yourself some time to be thoughtful about what you’re going to say and how you’re going to say it. In other words, prepare!
- Timing is everything. We’ve all heard that giving feedback in the moment is always best – so not waiting too long. But as I mentioned above, you can deliver feedback too quickly as well. I often find that waiting a little bit helps me to be more thoughtful and effective in my delivery.
- Consider your context. Do you know the team or the person you’ll be giving feedback to? What is their history related to receiving harsh or constructive feedback? Do they do well or struggle with it? Have they received it in a while? And have the received similar feedback to what you’re about to give them?
- The environment is important – public, private, or something in between? Where you give the feedback is almost as important as when you give it. I like to lean towards more private situations – limiting the exposure to just those that need to receive the feedback.
- Ask permission first. I don’t know where I learned this but along my career, someone told me to always ask first. And, if the answer is no, now isn’t the time, then respect that. This connects to the timing is everything earlier point. The feedback should be timed conveniently for the giver AND the receiver.
- Face-to-face is best. I find many situations in agile teams where feedback is given by email, text, or some other documentation-based mechanism. Call me old-fashioned, but I’m a firm believer that feedback should be best-served face-to-face. So that you can see the body language of the receiver and adjust your message according to how it’s being received. That’s so much harder to do (impossible) via email.
I’d argue that this theme applies to all sorts of feedback. For example, have you ever received an email reply that was clearly sent too soon? One where you could tell the sender had reacted to something in the email and said things that (you imagine) they now regret?
I’ll bet you have. I have too. In fact, I’ve been on the sending side of many of those messages. But I’ve learned to “hold onto” my messages and not simply react too quickly. I often wait for a day to send them. And what a difference a day makes in the crafting of my feedback!
So, “with all due respect,” I want to encourage all of us to be careful and thoughtful in giving our feedback within our agile teams. But indeed, please GIVE it!