“Hey, Jim, guess what? I incented my agile team to work faster and harder. I told them if they doubled their velocity, I would give them a team bonus. And it worked! In just one iteration, they went from 23 points to 46 points. Is that team a great team, or what?” – a not-so-agile project manager to another project manager
If there is a way to misunderstand the progress of a team, or if there is a way to game the system when it comes to estimates, someone will do it. That’s because there’s plenty of pressure to try to finish projects faster. Sometimes that pressure comes from outside the team, from our managers. When it does, the team can succumb to two common agile schedule games: “Double Your Velocity” and “Everyone Start Your Own Story.”
If you face these schedule games, you do have options and can manage them before they destroy your project.
Double Your Velocity
In “Double Your Velocity,” someone such as the not-so-agile project manager above misunderstands the velocity measurement that agile projects use. Let’s discuss what velocity is: Velocity is a way for teams to use historic information of this particular group of individuals who have worked together before, on this domain of work before, and to use that data to predict what they can do for this next iteration. Velocity is an estimation measurement, so you don’t have to do a total SWAG (Scientific Wild Tush Guess).
Velocity is not a productivity metric for the team–or worse–for the individual. When anyone, especially a manager, starts assigning a productivity meaning to the velocity measurement, the smart team has options to push back on the craziness and retain its velocity as an estimation tool.
If you want to increase your velocity, the fastest and easiest way is to double the number of points you assign to your stories; that will double your velocity. It doesn’t change how many stories you actually finish in an iteration, but it will look like you’re doubling your velocity.
Do you want to play this game, too? The cynical part of me says you also have the option of dividing the stories into two parts: Story Part 1 and Story Part 2. With any luck, you are dividing your stories along reasonable lines so that you see business value from each part. If not, well, the stories are still small enough that you finish them quickly. You can also double the points for each part. You can recurse on these tricks almost indefinitely.
Of course, when you randomly split stories like this you’re not splitting your stories so that they help you deliver business value more often, which is what you really want to do when you split stories. But you are playing schedule games.
Break Double Your Velocity
To break out of the game playing, ask your manager this question: “What result do you want? Is there something you are looking for aside from completing the project as quickly as possible?”
Explain that in agile approaches, you ask the team to work at a sustainable pace, providing business value frequently to stakeholders and asking for feedback. The team works at the best pace for the team. The team doesn’t take its time–the team works hard. What is the manager looking for?
In addition, remind the manager that team velocity is personal, like hair color or eye color. As soon as you change team members, the velocity is likely to change. If you change the product domain, the velocity could change. It’s a measure of past behavior that is likely to predict future behavior. It’s not a guarantee. “Double Your Velocity” is not the only agile schedule game. It is an external misunderstanding about a measurement that the team can manage to help its estimation.
Everyone Start Your Own Story
This game occurs when someone external to the team sees the team not meeting its burndown chart and imposes “help.”
I can see that you are not going to finish the stories you thought you were going to finish this iteration. Since you didn’t last iteration either, it’s time to do something drastic. No more swarming around stories. Nope, now all of you are going to start your own story, each of you–a manager circumventing the agile process, attempting to help a team.
“Everyone Start Your Own Story” creates waste, because it creates WIP (Work in Progress). Instead of the team collaborating, swarming around one story at a time, each person tries to make progress alone. But in agile, as in any project, very little can be done alone. Writing a user story on a card is a placeholder for a conversation. So if a single developer takes a user story, when does the customer or product owner have the time to talk to that developer and all the other developers? Maybe there are only four developers on the team, so there are only four open stories. How does the product owner have time to talk to all the developers? Are there four testers? I have yet to see a team with an equal number of testers. Maybe your team has an equal number of testers, so your developers and testers can pair on stories so you are only sharing the product owner or customer.
But it’s more likely that if every developer starts his or her own story, not only will the developers have to share the product owner or customer but the developers will have to share testers. So instead of pushing more work through the system faster, this game creates bottlenecks both at the beginning (when the developers start the stories) and whenever the developers need access to testers. Murphy’s Law dictates that regardless of what the estimates were, the developers will all need testers at the same time. Instead of pushing stories through the team faster, “Everyone Start Your Own Story” delays all the stories.
A better use of the team’s time is to swarm around features. Counter “Everyone Start Your Own Story” with “Everyone Start the Same Story Together”–swarming around a story. This reduces work in progress, and helps the team create any tools the team needs as they need it. It also allows the team to finish stories quickly, assuming the team has “right-sized” the story. I like stories that are small enough that the largest story can be completed by the entire team in one day. I realize that’s not always possible, but that’s what I like and aim for.
Come On, We Can Do More!
I bet you’ve seen teams who consistently complete some number of points per iteration, say 27 points. They might finish 29 points one iteration and 25 points another iteration, but if you look over six months of iterations, they consistently finish 27 points per iteration. But someone on the team thinks that they should commit to more points, say 30 or 35. For some reason, this person thinks the team should have a stretch goal every iteration.
This schedule game is not as bad as “Double Your Velocity”, but it’s not great. Estimation is not the place for stretch goals. You want to make estimation as accurate as possible. You want to commit to stories for the iteration so the product owner or customer knows what to expect.
The estimation is also important for the team. An accurate estimation helps the team maintain focus rather than worry about whether or not they will make the iteration goal. The accurate estimation helps maintain product and code quality because people know they have time to do the simplest thing that works (and to refactor the code and the tests as they proceed).
As long as there are teams and pressure to release, there will be schedule games. Do you have your favorite game to add to the list? Please tell us about it.
Copyright © 2012 Johanna Rothman. This article first appeared on Gantthead.com.