August 10, 2007

In a previous post I talked about a client that wanted to know how their SCRUM projects compared against industry statistics in our QSM SLIM database, with regard to speed, staffing, productivity, and quality. I was very curious about what I’d find, because one thing that was unique about this organization was the sheer size of their SCRUM effort – almost 100 people on 7 or more SCRUM teams.

Well, the numbers are in, and they are pretty astounding. We gathered the end-to-end elapsed time, the team size and resultant effort. That gave us schedule and effort/cost data. Next came two measures that quantified what the team had built; this included the amount of software that was produced (also quantified by the number of “stories,” and the volume of requirements that the team had satisfied). The quality of the software was measured by the number of bugs in the code.

In a nutshell, this organization built software faster than almost everyone else in our database of 7,000+ projects. They might be somewhere in the 95th percentile or higher. I don’t want to speculate exactly whether it’s 96th or 97th percentile or whatever, because you get the point. It took them about 2 years to get to this level of maturity, but it’s yielding about the best results I have seen.

It gets really interesting when I plot their projects on a data chart along with 4 other companies also implementing agile, including XP and other variants. For companies with about 2 years or more maturity in using these methods, the numbers simply hit another level. It’s as though (at least from this sample), that a critical “escape velocity” is achieved. At that point, it’s like the DeLorean car from the old “Back to the Future” movies. They take off like a lightning bolt.

More to come on this, because as I look into it more closely, I believe we have a new pattern emerging from the data. In the old days, projects that used large teams to compress time would pay a heavy penalty on – defects. Haste makes waste. This makes sense – defects would literally climb geometrically, and it correlated to almost the square of the team size. This was known as Putnam’s 4th Power Trade-off Law.

However, on the companies I’ve consulted to in this sample, that doesn’t seem to be happening. They’re using larger teams and finishing the projects very fast – but without the dramatic rise in bugs that were typical of non-agile projects.

Stay tuned…. this could be a huge story for the software industry that I might take on the lecture circuit.