Who’s Playing Agile Schedule Games?

“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...

Why Does Management Care About Velocity?

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...

Leanpub Podcast Up

A few weeks ago, Peter Armstrong interviewed me for Leanpub, to ask me why I enjoyed writing on Leanpub. That podcast is up now on the Leanpub Buzz page. What’s very funny is that the interview is a few weeks old. I had no idea he was going to post it right after I wrote Dear Author. About 11 minutes in, I talk about the boring trap, the passive voice trap in my own writing. I think this is pretty...

Dear Author

In my role as technical editor for the Agile Journal and as a reviewer for my trusted colleagues, I have the opportunity to read drafts of articles and some books. I see some troublesome behavior. I know it because I exhibit it. In all cases, the author receives feedback the author doesn’t like, but doesn’t want to stop writing. Decide on One Idea I am the prime example of this one, so I will use an example from my writing. I was trying to write one of my Pragmatic Manager emails last week. I sent it to Esther. It was only about 200 words. She counted the number of ideas, in the opening story of fewer than 60 words and stopped at 9 ideas. She could not read anymore. “JR, what is the main idea of this piece?” I just about fell out of my chair laughing at myself. I read this in articles and chapters all the time. You need one main idea in an article or a chapter. When you are done with that idea, it’s time for another article or a chapter. If you have lots of ideas, it’s fine to have another article or a chapter. When I write books, I have a file called, “Stuff-to-put-somewhere”. It’s ideas I can’t use now, but might have a chance to use later. Maybe you don’t need a file like that, but you need a place to put stuff you are not going to use now. You do not need to put everything you know into this article or this book. Really. I promise you. BTW, Joyce Statz...

Who's Playing Agile Schedule Games Posted

My new Gantthead column is up, Who’s Playing Agile Schedule Games? If you liked the schedule games from the more traditional projects, you’ll love the agile schedule games. Please comment over...