Agile Zone is brought to you in partnership with:

I am an organizational development coach and trainer, with a background in software development, graphic design, theatre arts, and team/groupwork facilitation. Inspired by (among others) Paulo Friere, Peter Block and Jesus of Nazareth, I have a keen mind, an anarchic edge and a passion for corporate enlightenment. Tobias has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

The Robustness Index

03.07.2013
| 1726 views |
  • submit to reddit
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.

Published at DZone with permission of its author, Tobias Mayer. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Benoît Labaere replied on Thu, 2013/03/07 - 3:36pm

A few years ago we introduced a similar indicator next to the cost of each required change. It was called "Risk" and was presented more or less like the probability of creating both regressions in existing features and bugs in the new one. This and having a sponsor impacted directly by the system's stability changed the way things were prioritized. Maybe the ugly bold font for high risk level helped a little bit, too.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.