Johanna Rothman explains that you cannot measure what people do and expect that measure to be useful. Why? Because software is a team sport, and everything we do depends on other people.
Barry bustled into Sam’s office. “Hey Sam, I need to see how these teams are doing— compared to each other. How do you compare teams?”
“I don’t compare teams,” said Sam. “Why are you trying to compare teams?”
“So I can tell who’s being more productive and who’s slacking off,” Barry replied. “But I thought for sure you did this. You always seem to have really productive teams. How do you measure them?”
“I don’t measure them.”
“What do you mean you don’t measure them? You must do something. How else will you know if the teams are any good? How about the people on the teams? You must measure them. Come on, what’s your secret?”
“Barry, I don’t measure a thing about the people. I don’t measure what the teams have as output. I ask them to measure their throughput and to ask me for help if they are unhappy with it.
“My job is to help create the environment that will allow our team members to work in a reasonable way. I make sure they know which project is number one. I arrange for training for people when my managers tell me people need training. I make sure everyone knows our mission. But I don’t bother with that comparison nonsense. Is someone asking you to compare teams?”
“Well, no, but I have no idea how to know who is doing great work and who’s not doing so well,” said Barry. “I have engineering teams here in California and some in Colorado. I have some teams in France and some in Israel and Bangalore. How do I compare them? They are cross-functional teams. They are working on the same product. You would think I would be able to compare them. But I can’t figure out how.”
“Okay, let’s deconstruct this,” Sam said. “First, why do you want to? What’s the value you obtain from comparing teams? What would change if you suddenly know one team is better—which I’m not saying you will discover. But if you did discover that, what would you do?”
Barry thought for a few minutes. He said, “Well, I’d reward that team.”
Sam shook his head. “No, you wouldn’t. Not if you wanted that team to work with the other teams on the program ever again. The teams have to collaborate. Why would you pit the teams against each other?”
“Because I want to get the best out of my people,” replied Barry.
“Okay, that’s a great goal,” said Sam. “I also want to get the best out of my people. I tell them what the best is. The best is often a specific release date for the product, or some release criterion since we’re in engineering. When I ran support, it was something else. When I ran IT, it was performance for the organization. But it was never a measurement for the team. Never.
“If you want to measure something, you might start with yourself. You’re at the top of the organization. But that doesn’t make sense either, does it?”
Barry shook his head.
Sam continued, “You can’t measure the performance of a team. However, you can measure the team members’ output. In engineering, you can measure features-per-unit-time, although you can easily game that measure. Instead of doing so, tell people what you want. Do you want them to release the product by a certain date? Tell them. Do you want them to take care of customers in a certain way? Tell them.
“People come to work every day to do a good job. No one comes to work to do a bad job. If you think they want to do a good job, treat them that way. They will live up to your expectations. But you have to do your part. You have to tell them what you want, provide any necessary resources, provide training, have one-on-ones with your managers so you can provide meta-coaching and feedback, remove the impediments, and make sure the program’s goals are clear. Then you have to not get in the way of the program.
“But you don’t have to measure the teams. There’s no value in that. If you think there is, measure yourself first. See what you discover. Then apply your measurement to your teams.”
Measuring People Doesn’t Buy You Anything
For years, managers have tried to measure individual people’s productivity. That hasn’t worked. Now, especially with agile teams, they try to measure and compare team’s productivity. That doesn’t work either.
You cannot measure what people do and expect that measure to be useful. Why? Because software is a team sport. Everything we do depends on other people.
Even if we could measure an individual’s productivity, that measure would be meaningless, because everything we do in software is interconnected.
Measuring a Team’s Productivity is Meaningless, Too
Measuring a team’s productivity in terms of features per unit time might be a step in the right direction, but you can’t compare projects. And, trying to compare teams on the same program has the same problems as comparing people on the same project—every team is interconnected. Why would you pit teams against one another?
There is no value in measuring teams against each other.
What Does Management Want?
From what I see, management wants to know that people are working hard and making progress. Those are two different problems.
If you want to know that people are working hard, you can ask them in a one-on-one for a list of their impediments to their ability to making progress. Note that my assumption is that they are working hard, and that only impediments prevent them from making progress faster.
If you tell people or teams what the goal is—the results you want—and you ask them if they have the tools to achieve those results, all you need to ask on a periodic basis is what their impediments are to achieving those results. That’s why you need a weekly or biweekly one-on-one for people—so you can tell if you, as a manager need to remove impediments. In a program, the program manager can assume there are impediments and that the program manager needs to expose those impediments more frequently than once every two weeks. The program manager needs to facilitate the impediment removal or remove them him or herself.
You don’t need to measure how people or teams are doing to see if they are working hard.
Is a Team Making Progress?
The best way I know to answer the last question “Is a team making progress?” is to use an agile lifecycle so you can see demos. Other iterative or incremental lifecycles will do because you can use deliverable milestones, but the progress will be slower. Agile lifecycles provide an answer faster.
If you use an iteration of two weeks, you can see a demo at the end of two weeks. If you use flow, you can see a minimum marketable feature (MMF) even earlier than that, depending on the size of your features. You don’t have to compare teams to see if they are productive. You can see if they are productive.
Don't use surrogate measures when you can see the product in the form of a demo. Measuring teams is a poor form of measurement. Ask people for what you want. Explain the goal, provide the tools the people need, create a reasonable environment and continue to remove impediments, and you don’t have to attempt to measure a team’s productivity. You can’t and you don’t need to. The team will respond magnificently.
Read more of Johanna's management myth columns here:
- The Myth of 100% Utilization
- Only the 'Expert' Can Perform This Work
- We Must Treat Everyone the Same Way
- I Don't Need One-on-ones
- We Must Have an Objective Ranking System
- I Can Save Everyone
- I Am Too Valuable to Take a Vacation
- I Can Still Do Significant Technical Work
- We Have No Time for Training
- I Can Measure the Work by the Time People Spend at Work
- The Team Needs a Cheerleader!
- I Must Promote the Best Technical Person to Be a Manager
- I Must Never Admit My Mistakes
- I Must Always Have a Solution to the Problem
- I Know How Long the Work Should Take
- I Must Solve the Team’s Problem for Them
- I Can Move People Like Chess Pieces
- Management Doesn’t Look Difficult From the Outside, So It Must Be Easy
- I Can Compare Teams (and It’s Valuable to Do So)
- It’s Always Cheaper to Hire People Where the Wages Are Less Expensive
- If You’re Not Typing, You’re Not Working
- You Can Manage Any Number of People as a Manager
- People Don’t Need External Credit
- Performance Reviews Are Usefult
- It's Fine to Micromanage
- We Can Take Hiring Shortcuts
- I Can Standardize How Other People Work
- I Can Concentrate on the Run
- I Am More Valuable than Other People
- I Don’t Have to Make the Difficult Choices
- I Can Treat People as Interchangeable Resources
- We Need a Quick Fix or a Silver Bullet
- You're Empowered Because I Say You Are
- Friendly Competition Is Constructive
- You Have an Indispensable Employee
