08.20.09
Big spikes in velocity should tell you something
I posted something here at the start of my last agile project. I meant to follow it up but didn’t get around to it. Bad me. Anyway, it was a 10-iteration project that had the following velocities:
As you can see, there was a big spike around iterations 5 and 6 and a trough in iteration 9. The dip in iteration 9 was caused by paying off technical debt and resolving some deployment issues we hadn’t originally budgeted for. I hadn’t thought too much about what caused the surge in velocity around the middle of the project. At the time the attitude was “we’re going really fast, let’s just keep doing what we’re doing”. In hindsight I think the spike in velocity should have raised an alarm bell. Here’s why…
I am now working on a new project that reuses some of the work we did previously. Alas I have discovered that some of the code requires extensive refactoring. The current implementation of some features is both fragile and incomprehensible. There are methods that are hundreds of lines long (!) with no comments. There is hand-rolled code that duplicates the intent of library functions. Some functionality is poorly encapsulated and thus not reusable. All the usual suspects! SVN tells me that this code was committed when? That’s right, iterations 5 and 6 of the last project. It seems our gains in velocity came at the cost of maintainability.
All it not lost: the old code has pretty decent test coverage, so at least the refactoring effort isn’t working blind. That said, I think our iteration retrospectives will in future check our velocity against our historical performance. Up till now we’ve been pretty good at identifying the causes of slow iterations - from now on we’ll be having a look at what a fast iteration velocity is masking beneath the surface.