Every so often, managers want to compare teams. You’ve heard this in several ways:
- Managers want teams to “normalize” their story points, so they can better predict the cost or schedule for the rest of the backlog in large programs. This doesn’t work, but managers want to do it anyway.
- Managers want to compare teams to see which teams are more productive. This is even crazier. Who can tell which teams are more productive? You can’t tell which features are more difficult. You can’t tell which projects are more difficult. Why not? Just because something looks easy does not mean it is easy. The teams will start to game the measurements if you try.
- If you ask the teams to increase their points, they will. This is an agile schedule game, Double Your Velocity. “That team is doing twice your points. Why can’t you do twice as many points?” Have no fear. The team will at least double their velocity, just by doubling the points per story.
Comparing teams is not useful. There is no reason to do so. Each team is unique, composed of wonderfully unique individuals. What does matter is that the team is working well together, delivering product. That is the only thing that matters.
If the team delivers, without working well, the team is not sustainable over time. If the team does not deliver, even if they are harmonious, that is not sustainable over time. You need both. And, you cannot get both if teams are in competition with each other.
I was working as a manager in an organization several years ago, when one of my managers wanted to have a “friendly” competition, to see which team was “better” than another team.
“What outcome do you want from this competition?” I asked my boss.
“I want to know what team is better,” he said.
“Do you also want any shippable product?” I asked.
“Well, of course!” He looked at me as if I had three heads. “That’s the whole point of this exercise. I want shippable product and friendly competition.”
“But these people have to work together. And you are asking them to compete with each other instead of collaborating with each other. I am the program manager. How the heck is this supposed to work?” By this time, I’m standing up, leaning over his desk, in his face.
I’m angry. I’m not happy about this situation. I’ve just helped the teams understand how to do deliverable-based planning so that we have sync’d their deliverables. (This is before agile.) Now, my boss is about to undo everything I have done. Argh. (Read Manage It! Your Guide to Modern, Pragmatic Project Management to learn more about deliverable based planning.)
I sat down. I calmed down. I explained that I needed collaboration, not competition.
I still have all my hair.
This is why I wrote Management Myth 20: I Can Compare Teams (and It’s Valuable to Do So). Managers have good intentions. And, they don’t always realize the consequences of their intentions.
