As more of my clients transition to agile, many of them have a fascinating question:
How do I assess who is doing what on my team?
When I ask why they want to know, they say it’s all related to reviews, rewards, and general compensation. They are still discussing individual compensation, not team compensation.
When I ask why they want to reward individuals instead of the team, they say, “I am sure some people do more work than others. I want to reward them, and not the other people.”
Interesting idea. And, wrong for agile teams. Also wrong for any innovation or learning that you want to happen as a team (regardless of whether you are agile or not).
Agile is a team-based approach to work. Why would you want to reward some people more than others? If the team is not sure that they are working well together, they need to learn to provide each other feedback. If the team doesn’t know how to manage team membership, a manager can facilitate that membership discussion and problem-solving. Then, the managers can transition team membership issues to the team, with manager as backup/facilitator.
What I see is that the managers want to control team membership. Instead, why not let the team control its membership?
I often see that the managers want to control feedback: who provides it and who receives it. Instead, why not train everyone in how to provide and receive feedback?
When managers want to reward some people more than others, they imply that some people are less capable than others—something agile is supposed to fix with teamwork. Or, they wonder if some people are wasting time.
If managers trust their teams, managers don’t need to worry about accountability. They don’t have to worry about people “wasting time.” Agile creates transparency, which helps people to learn to trust each other and know when they are working on relevant work or not. If you encourage the team to add pairing or swarming (or both), you have the recipe for whole-team work and team momentum.
I don’t know anyone who goes to work thinking, “How can I waste my time today?” Do you? (If you do, why is that person on your team?)
I know plenty of people who do waste their time, because of technical debt, or experts creating bottlenecks, or team members who don’t want to work as part of a team. I bet you know many of these people, too.
But I don’t know anyone who wants to go to work to waste time and collect a paycheck without doing anything. Sure, there might be some people like that. I don’t know any.
In an agile team, the team members know who works hard and who doesn’t. A manager could trust the team to handle their compensation.
And, that would mean the manager has to relinquish control of much of what managers have done recently.
- The manager would have to provide feedback and meta-feedback to people who want to learn how to provide and receive feedback.
- The manager might provide coaching as to how to work in a team effectively. (This can be tough if a manager has never been part of a team that worked well.)
- The manager would allow the team to control their compensation.
There’s more, and I’ll stop there.
What would managers do? They would stop interfering with the team’s progress. The manager might read “If Managers Don’t Give Performance Reviews, What Happens?”
Managers control much less in agile. Managers enable more. They have to trust the teams. This is a culture change.
If you can’t trust your agile team or its team members, there is something wrong. You can investigate and either fix (manage the project portfolio) or ask the team to fix it (maybe with retrospectives as a first step). If you need to know who is accountable for what, you are asking the wrong question. The answer might be you.
If you are managing an agile team and you want to know about individual work or accountability, ask yourself what you really need. Ask yourself if there is another way to obtain the results you want. Maybe you won’t waste quite as much time.
| Reference: | Trust, Accountability, and Where Does the Time Go? from our JCG partner Johanna Rothman at the Managing Product Development blog. |
