At last week's
Agile conference, I spoke with a number of managers who weren't sure what their jobs were, now that their teams had moved to agile. They knew they weren't supposed to reassign people in the middle of a sprint, or even break up a team that's working together well, but they weren't sure what they were supposed to do.
Giving effective feedback, and coaching other people in how to give effective feedback is a great thing to do. Chances are quite good that few people in your organization know how to do so. In
Behind Closed Doors: Secrets of Great Management, Esther and I suggest this model of feedback:
- Create an opening to deliver feedback.
- Describe the behavior or result in a way the person can hear.
- State the impact using "I" language.
- Make a request for changed behavior.
You need to create an opening so you know that the other person has time and is in the right frame of mind to hear you. A one-on-one is a great opportunity to give and receive feedback.
When you describe the behavior, avoid using labels. "You always break the build" just begs for one exception. "I noticed that you broke the build Monday, and twice on Tuesday." People can argue with data, but it's much harder to argue with data you can measure.
When you state the impact using "I" language, you can explain the result personally. "When the build is broken, I hear about it from everyone. I suspect you do too. It's an obstacle I can't remove without you. I feel helpless, which is not a feeling I like."
When you make a request for changed behavior, you can ask to problem solve. "What would it take for you to avoid breaking the build?" Sometimes, the person you are giving feedback to doesn't realize they have an impediment that you need to resolve. One developer said, "I don't have virtual machine with the environment and I have no other machines." He went on to explain what he did have and what he needed. I hadn't realized that
his build problem was really
my problem to solve. Oops.
Giving effective feedback, not beating around the bush, being clear and firm, not labeling people, is the mark of a congruent team member and team manager. Learn how and you'll have a much happier team.
The way I see it "Build terrorists" should be handled by the team itself, and the Scrum master (or respective) in particular. If there is a real physical impediment involved, like missing hardware, it's the Scrum master's responsibility to remove that impediment (probably by requesting new hardware from the manager).
In agile methodologies, the manager should be managing her Scrum masters, not individual team members (unless as helping the Scrum master removing impediments). The management techniques you describe are the same though, but shared with the Scrum master as well (who is a kind of manager too).
Your book is really great by the way, a real eye-opener when I first read it several years ago.