Pages

Google+

Tuesday, January 17, 2012

Velocity Has Left The Building

I just came across an article about Agile Velocity: how to use it and why it's important. In some ways the author and I are similar...we both have experience as software developers, worked in management positions and we even have the same name, 'Alan' (I'm liking this guy already!). Well, turns out the guy is an 'Agile Coach' and is preaching about how useful velocity is (maybe we're not similar after all).



The concept of velocity is straightforward really. Velocity is like a bucket of finite size and features are put into the bucket, taking up space. This forces you to decide how many features can fit into the bucket at once. During a sprint planning the team gets together, talks about the effort surrounding a feature and assigns points to the feature based upon difficulty (ok the developers on the team assign the points).  Then you see how many features you can fit into a sprint: e.g. If you have a sprint velocity of 12, you can fit two 6 point features in there. After each sprint you see if your velocity needs to be lowered or raised base on how accurate your estimates were.

The good part about this is that the team is getting together and talking about what it takes to build a feature.  Things like:



  • What needs to happen before or after it's built.

  • Breaking down the feature into steps and thinking it out.

  • Sharing knowledge about how things are built with everyone on the team, even those who are not directly involved in coding it.

The not so good part is that most managers use this as a metric to gauge performance of a team and / or use this as the primary tool for deciding how many features can be put into a sprint.

After about a year of working with sprint velocity, I have thrown it out the window. It's great for the team to talk about how difficult a feature is and the effort involved in building it; however, I have yet seen a good use case for velocity.

The biggest problems are:

  • No matter what, points assigned to a feature are a guess, perhaps educated and accurate, but still a guess.

  • You can count on velocity being different for each sprint.

  • It's too easy to manipulate for selfish reasons - for both managers and developers.

  • Management gets a false sense of control over a project.

  • It teats people like robots....giving them dehumanizing 'efficiency' ratings.




So without this nice and neat number that a manager can shuffle features around with, how does management plan features with a team. Well...bad news for you 'set it and forget it' types, you're gonna have to continuously talk to your team about what can be done during the sprint. Of course there are certainly marketing goals that must be achieved during a sprint and this is where the team communication comes in. The team needs to discuss how and why features 1,2 & 3 need to be done by a certain time. This is also when you talk about how a feature can be designed so that marketing requirements are filled while still keeping quality high.

So what about that article mentioned at the beginning? The author begins writing about severals ways velocity is misused (good!), but then oddly comes back and makes the argument that velocity is what drives a team on the product's 'road trip' (huh? not good!). Some number like velocity should not be motivating your team - taking pride in a quality product should be. The team is also certainly not on a 'road trip'.  A road trip implies a roadmap (more on why these are bad later) with waypoints at finite points over a long period of time.

If you want to build innovative software, you're going to have to get comfortable with sometimes not knowing the best way to get to where you want to go.