Improving Velocity, or Getting Things Done

I’ve been asked by my project sponsor to come up with plan to improve velocity.  This is a tricky area, and one which I’m approaching with caution.  I’ve gone thought a few iterations of a document and found my perspective changing constantly.  I think I’ve finally settled on a safe approach.  My conclusions …

Velocity can be a false indicator of progress

I attended some six sigma training a while back, and one thing that struck me (I think this is a fairly standard criticism) is that while it can improve productivity, it doesn’t really focus on doing the right thing.  This same can be true when looking at velocity.  As a start, I can improve velocity by capturing more of the work we do in a sprint (e.g. meetings).  Other things, like spending a sprint researching and implementing a new technology, also contribute to velocity.  This wouldn’t have contributed to velocity if we’d got training and implemented some new technology in a quarter of the time.  How is this benefit captured?  This reminds me somewhat of the ‘false’ economy of disasters, for example.  Oil spills add to a country’s GDP, but that doesn’t mean they’re a good thing.

With this is mind, one must be careful in simply presenting a plan to improve velocity.  What I have said is that training in agile principles, as well as the possible use of a consultant to coach the team, will help.  I’m still having trouble quantifying it.  I can’t say our velocity will increase X% for every $X spent on training or consulting.  All I can say is things should improve.

Getting Things Done or Not Doing Things in the First Place …

The other piece of this is how we can avoid having to do certain things in the first place, or get things done more faster by cutting out steps.  Training, conferences, and even consultants can accelerate our progress in the project without ever changing our velocity (although they could possibly reduce the scope as represented in story points).  The key here is identifying some of the things we need to do (estimated or un-estimated) and then finding alternatives.  My architect could spend three weeks figuring out our business rules engine, or he could spend two days on training and accomplish the same task with another three or four days of effort.  Again the challenge here is quantifying it.  I can’t guarantee what impact training or in-house consulting will have in a well-quantified manner.

In this case I’m using past experience to predict the future.  We can look at other training sessions we’ve had, and make a guess at the impact, both in reduced effort, increased quality, and new ideas.  The problem here is that it’s just an assumption on top of a guess.

Anyway it’s been an interesting exercise and one that will probably be a lot easier with more experience in this model.