On Giving Useful Feedback

Successful agile teams do well, in part, because of the types and amount of communication they use. One place where communication is most important and comes with significant risk is giving "constructive criticism" or "corrective" feedback. I've noticed two patterns of feedback that don't work well: indirect or soft feedback, focused on not hurting the recipient's feelings and unnecessarily frank, or even blunt feedback given with little regard for the recipient's feelings. The first pattern tends to communicate insufficient information and the second pattern, while containing full information, is not presented in a manner that that is often met with defensiveness.

A friend told me about a pattern of giving feedback that I think does a good job of avoiding the pitfalls of the first two patterns. I didn't ask him where he learned it, and I could only find one reference to it: http://bit.ly/dEwGw4 The pattern is called "what-what-why" and it works like this:

• Tell what you didn't/don't like or what you think didn't/doesn't work well
• Tell what you would like instead
• Tell why you think your suggestion would be more effective

For example:

• I don't like how our team is spread out and in individual cubicles
• I'd like it if we moved into one room and sat at a cluster of tables
• We'd "overhear" important information and there would be fewer barriers to asking each other questions.

Or:

• One thing that didn't work for me in the retrospective was when you would say something before someone else was finished speaking
• I'd like it if you allow other people to finish their point and then add yours
• I think the meeting would flow more smoothly and everyone would that they would get their chance to be fully heard.

There are a couple things I really like about giving feedback this way. First, it makes it clear that this is what I don't like and what I want instead. If I were to instead say: "You know, it might be better if you let people finish their point..." or "Don't interrupt people...", I'm not really owning that this feedback is coming from me. Second, it focuses on the desired benefit instead of focusing on anything about the person, making it less likely that they will take what I am saying personally and become defensive. And finally, I don't have to spend a lot of time thinking about how I am going to give feedback or worry much about how the person might take it. As soon as I see something that I'd like to be different, I can give the what-what-why and address the issue right away. This is great because communication is most effective when it happens early.

I recognize, however, that not all feedback is intended to cause a different outcome. Sometimes someone is doing something that I like or that I think is working well and I want to let that person know. In that situation, I use a "what-why" pattern:

• Tell what you like/liked or what you think works/worked well
• Tell why you like it or think it works well

For instance:

• On the story wall, I like how you've given each team member a tag that they can put on the story that they are working on.
• Not only does it let everyone know what everyone else is working on, but it's a good way of reminding people to only work on one story at a time.

Like what-what-why, this pattern lets me own that this is my viewpoint, it focuses on the process and outcome rather than the person, and it's a template that lets me communicate as soon as I recognize that I want to.

If you try what-what-why or what-why, I'd be interested to hear your results. Do you have similar feedback patterns that you find useful?

What is agile communication?

In thinking about some things for the Agile Skills Project, I realized that agile teams communicate differently than non-agile teams.

It seems to me that agile communication aims to be:

• public (vs private or secret) [public within the entire team, not public as in news media]
  
• early (vs delayed)
• spoken, preferably in person (vs email)
• free from judgment (vs assigning blame)
• osmotic (vs selectively broadcast)
• flat (vs hierarchical)
  

A significant enabler of agile communication is the Supportive Environment Agile Pillar.

What characteristics of agile communications do you notice?