Team Members Practice Continual Feedback
Too many people receive feedback once a year from their manager in the form of a performance evaluation. Too often, the data—if there is any—is too vague or late to be useful. And rarely do people on teams have a chance to practice feedback with each other or with their managers. Feedback seems to flow downhill, just as mud does.
Infrequent muddy feedback from people outside the team is useless. Frequent, data-based feedback from peers is helpful.
Learning How to Use Feedback Helped Us Release Faster
by Gwen, Agile Project Manager
Gwen
We had a team who was accustomed to waterfall, a sequenced approach to projects with one delivery at the end of the project. I knew we had to get good at releasing small deliveries to get feedback on our work, both on the product and how we worked together.
I explained to the team that I wanted us to know we could deliver useful chunks at least as often as every week. Were they willing to do that? Yes, they each said. I explained we would probably make mistakes along the way. Were they willing to provide feedback to each other? Not blaming, just the facts.
I explained how to provide feedback, especially how to agree on the data. One of the team members asked what happened if they didn’t agree on the data.
I explained about “going meta”—starting at a higher level of abstraction—if they couldn’t agree on the data. That seemed to help.
They practiced with each other in the meeting, to make sure they knew how to provide and receive feedback. They went back to working on the product.
It took them about a week of practicing every day, multiple times a day, to get comfortable with feedback. Once they did, though, wow. They were able to release value as often as we wanted. They took the idea of feedback and applied it to everything. Best thing I ever did.
Peer-based feedback helps team members collaborate, learn, and adapt to what the team needs to finish work now.
As defined in What Did You Say? The Art of Giving and Receiving Feedback [Wei15], feedback is
“Information about past behavior, delivered in the present, which may influence future behavior.”
Consider using the peer-to-peer model of feedback, as explained in Behind Closed Doors: Secrets of Great Management [RD05]:
- Create an opening to deliver feedback.
- Describe the behavior or result in a way that the person can hear.
- State the impact using “I” language.
- Make a request for continued or changed behavior.
It doesn’t matter if you want to ask someone to continue to do something great (reinforcing feedback) or to ask someone to change (change-focused feedback). This approach works.
Here’s how feedback works in practice. Imagine you have a product that requires internationalization and localization to support multiple languages. A new tester, Dave, joins the team and discovers a problem in the English version. He checks the French and Spanish languages—and yes, the problem is there, too. He opens three defect reports, one for each language. Judy, the developer, has this conversation with him:
Judy: Hey, Dave, got a sec? I want to talk to you about these defects.
Dave: Oh, okay.
Judy: Okay, let’s take this conference room. I’m not sure if you know about how we have reported internationalization problems in the past, but we report one problem against all the languages. You reported three problems that are the same. Did you realize that?
Dave: Uh, no. Is that a problem?
Judy: Well, it’s not earth-shattering, but it’s not how we work here. Can you make all these defects link to each other, and then only report one in the future?
Dave: Well, I can. But what about when I find three real problems?
Judy: Oh, report them! Don’t worry. You know, if you’re not sure, just ask me. I’ll tell you if I think it’s three problems. Actually, you can ask anyone on the team. You don’t have to ask me, in particular.
Dave: That’s okay? I thought I was responsible for quality.
Judy: Aha! Nope, we’re all responsible for making sure the entire product works. Your job is to expose problems for us. You did. You just reported three instead of one. That’s the only issue here. Okay?
Dave: Oh, okay. Thanks.
Dave had made a mistake. Judy explained with feedback and offered coaching on the tester’s role. That’s all.
Feedback is even more important when you have personal issues. Dirk had terrible body odor. Selma was supposed to pair with him and just couldn’t take it. Here’s how Selma handled the conversation.
Dirk: You ready to pair again, Selma?
Selma: Maybe. We have something more important to discuss. Please sit and let’s talk.
Dirk: Now you’re making me nervous.
Selma: Well, I’m kind of nervous bringing this up. Dirk, I have to tell you this. You have terrible body odor. I didn’t want to tell you, but I’m having trouble working with you, sitting next to you.
Dirk: Oh, that’s terrible. How long have you noticed this?
Selma: Since last month.
Dirk: You’re only telling me now? Well, at least you’re telling me now. Well, I did several things last month. I changed what I ate, I changed my deodorant, and I changed my laundry detergent. I don’t think my clothes are that clean, and I can change back. Should I go home and fix this now or do you think we can pair?
Selma: I think you should take a couple of hours to get your old deodorant and take a shower and wash your clothes.
Dirk: Okay, I’ll tell the boss.
You might think this is an extreme example. However, I have had to tell people their breath stank or that their body odor interfered with our ability to work together.
People on agile teams need the ability to provide and receive feedback about the work and the work environment. That includes us as humans. (For more information on the importance of feedback, also see “Building a Team Through Feedback.”)
Whatever you do, separate change-focused feedback from reinforcing feedback. Often, team members need both kinds of feedback and they don’t need the Trap: The Feedback Sandwich.
