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 my experience, it is more likely to do so, because the team members learn that postponing automation hurts. And postponing technical debt hurts. And big stories cost more than little stories. And waiting to integrate costs more than integrating right away. And, informal pairing among anyone is better than no pairing, and and and… Every team learns their own lessons because every team is different.
But just because many of the lessons the teams I’ve worked with are applicable to many other teams does not make them “best practices.” Phht. They are practices that work in a context. They especially work in a business context. And, once management starts focusing on velocity, the business context has changed for a team.
Managers, look at the demo. If you want more out of a team, work on the project portfolio. Decide what is first. If you can’t decide, run the project portfolio as a kanban. I explain how in Manage Your Project Portfolio. Velocity is too-low-level a measure.
Teams, show your managers a product backlog burnup or burndown chart. I also explain that in Manage Your Project Portfolio. And, demo! I suggest a number of other measurements, such as cumulative flow diagrams.
I like velocity for telling us if the project is not going to end. I have those charts in Manage Your Project Portfolio.
Managers, you can ask a team to do more. But you don’t need to see an internal measure like velocity. That’s personal to a team and doesn’t help you make any judgements about what the team is doing.
Encourage the team to experiment. Use cumulative flow, product backlog burnup/burndown, feature throughput, and demos. That’s the way to see if a team is producing.
