I’ve been talking to people whose management cares about their velocity. “My management wants us to double our velocity.” Or, “My management wants us to do more in a sprint.” Or, “My management wants to know when we will be a hyper-performing team, so they want to know when we will get 12x velocity like Scrum promised.” But let’s understand what management really wants.
I’ve been talking to people whose management cares about their velocity. “My management wants us to double our velocity.” Or, “My management wants us to do more in a sprint.” Or, “My management wants to know when we will be a hyper-performing team, so they want to know when we will get 12x velocity like Scrum promised.”
“Double Your Velocity” is an agile schedule game. It’s easy to manage–you double the points you assign to your stories. Whee! You’ve just doubled your velocity. No muss, no fuss.
But let’s understand what management really wants.
What your management wants is for the team to do more in a given time period. That’s why they want more in a sprint, or for the team to become a hyper-performing team. So, let’s look at the project conditions for a hyper-performing team:
- No multitasking. Management must manage the project portfolio. You can ask your managers to do this. Really, you can.
- The customer or product owner must rank the features.
- The project team must already know how to work together. That means you can’t add or subtract people. The team must have already formed, stormed, and have normed. They have to know how to work together.
- They have the physical infrastructure: build servers, phone lines, computers, whatever that they need, and they know how to use them. Do not underestimate this part. If you don’t have this part, you can’t do continuous integration, for example.
- The team needs enough people who play enough cross-functional roles: developer, tester, and whatever else the team needs , so that the team can finish its work. I am being vague on purpose. I don’t know what your team needs. It might need a catalyst. It might need a UX person. It might need an almighty DBA. It might need a project manager to coordinate work from other teams. I have no clue, because it’s your team. All I know is that your team needs enough cross-functional roles to get all of its work done so that the stories don’t come back to bite you on the tush.
Those are just the project conditions. Take a look at the project pyramid I have in the estimation series I wrote last year. The project conditions are part of the work environment. If you have a distributed team, good luck moving to a hyper-performing team. Can you do it? Of course. Will it take longer? Yes. Why? Because you have to experiment with your project conditions. Management will have to stay out of the way while you run your experiments.
Now, I am not known for my tact and diplomacy. Here’s what I have said to management: “Velocity is personal to a team, just like weight is for a person. What you need to care about is our feature throughput. You need to care about our demos, not our points. How we manage our velocity is like making sausage. You don’t want to know that. You want to know the results. We want to show you our demos, not our act of creation, okay?”
I’ve had success with that, especially with overweight managers, and those who knew about sausage-making. I’ve had success with that as long as teams had iterations no longer than two weeks.
Why? Because as a team learns and experiments, it is more likely to create smaller stories. It is more likely to swarm around stories. It is more likely to automate more of its testing. It is more likely to pay down technical debt as it proceeds. It is not guaranteed to do any of this. In