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.
Putting aside the many ways I’ve seen velocity abused over the years I’d like to address a fundamental problem with the concept of monitoring and driving “productivity”.
In my opinion, outputting product is not the only value creating activity. Features usually make products worse (http://www.forbes.com/sites/stevedenning/2011/06/26/lean-startups-pt-3-most-changes-make-products-worse/) . We push teams to produce more velocity and inevitably get what we measure.
The scenario you describe about doubling estimates is certainly a possible outcome but I think the insidious result is that corners are cut. “We’re measured by how much we produce so let’s make sure and produce the most.” is the predictable result, quality is sacrificed and technical debt snowballs. Soon we’re making features to mitigate the consequences of other features we’ve released. As long as management continues to believe it’s their role to push individuals to crank out /more/ work people will respond by being less creative and more industrious. As a result innovation will suffer. Instead of producing awesomeness for users the team becomes a velocity factory. Soon engineers are not making software, or helping users, they’re “making points”.
In software more is rarely better. Less code, less technical debt, less inventory, and less waste are all likely to be better for the business and the customers. But there’s never any time to re-factor or to experiment due to the aggressive product development schedule.
Our customers have desires, needs and problems. They are not interested in our productivity hockey-stick. As an organization I believe we’d benefit from being focused on those desires, needs and problems and the more we obfuscate the work we do from the people we hope to impact the less likely we are to succeed.
Just my two cents on velocity. Don’t get me started on estimation. 😉
Another thing that customers want is more of what they want. What I mean is that the team should stop doing stuff that customers don’t want. And managers should help get that crap out of the system.
Managers tend to be good at adding more crap to the system, not removing it. The visualization tools we use in Agile / Scrum / Kanban help us see the stuff that gets in the way of delivering value – your examples of automation and technical debt are examples. The it is up to the team and management to figure out how to stop doing things that customers don’t want. And thus doing more of what they do want.
Unfortunately, stuff runs downhill. Office hierarchy being what it is, a manager can easily and safely say “well, project conditions are about as good as they can be, so get to work increasing your velocity”. A team can, at their peril, say to management “well, we’re working as hard, and smart, and conscientiously as we can, so please get to work improving the project conditions”.
The moment management takes responsibility for “[getting] more in a given time period” by improving project conditions, they’ve entered the politically risky world of accountability.