The Robustness Index

Running into a common problem, again—deliver fast and maintain quality—a team of developers and I discussed how we might create visibility around this without having to get into long explanations about about technical debt with non-technically-minded people. We came up with the robustness index. Not a new idea, I am sure, but one that is worthy of mention nonetheless.

The business want features delivered quickly. (I am unable to determine exactly why the speed they seek is so important, but that’s a longer-term dialog.) The developers want to have a robust codebase in order to write bug-free software, and have a sense of pride and personal satisfaction with their work. These goals are inherently in conflict. Often, there are shortcuts that can be made to deliver the software quickly. This, as we all know, will add to our technical debt, possibly adding new problems, and causing future slowdown. But sometimes the business determines this is necessary, and find it easy to close their minds to the concerns of the developers, viewing, skeptically, their desire to have clean code as “gold plating”.

This team uses story points to determine effort. I’m not going to comment on that here—it works for them at the moment, up to a point. The business often push back and say, e.g. that’s a thirteen? surely not! and the developers, tired of the same dialog over and over, cave and say, well, maybe it’s an eight. And then they rush the work to meet the goals. Yes, I know all of this is riddled with dysfunction, and much work needs to be done before the dialogs become healthier. But remember, this is where they are now, and not well supported by upper management. They need to do something different, and this is their interim solution to raise awareness.

The developers decided to add a robustness number alongside the effort number. Robustness is measure on a scale of 1-10, where 1 is total crap and 10 is the kind of code quality a good developer seeks. So now a story may have multiple effort estimates, each accompanied by a robustness number, e.g. for one story the estimate may be 5-4, 8-7, 13-9. The message being, yes we can do it quickly, and this is what you will get: fast delivery, unstable result. If we do it more carefully (and slower) it looks more like this: greater effort, greater robustness. The hope is that data-loving business people will be moved by the number, whereas they have not been moved by the emotional pleas. The quality and robustness reflects on them, of course, and no one seeks to offer shoddy product.

This is not a solution, merely a way to help understand the risks associated with “being agile”, where the term is understood to mean “being faster”. The team plans to try this system in their next iteration, so I have no idea if it will be effective or not. I like the idea though, and am keen to see if it has any effect. If I get to follow up with this team, I’ll write write an update.