SCRUM: Productivity Gains with eXtreme Programming

For some years now, several authors of the Agile Manifesto have discussed Scrum as a process wrapper for XP processes. It's introduction to a new team can be quick and easy, and XP engineering processes can be adopted over time as the team can adapt. Also, Scrum has a scaling strategy that has repeatedly worked on large implementations, whereas XP engineering approaches are most clearly visible in a small team.

The May/June 2003 issue of IEEE Software focused on XP. One of the more interesting articles is about the experience of a team of two building an application of 2445 lines of code at NASA Langley Research Center building government research software in Ruby. Since Ruby combines some of the best features of Smalltalk and Perl, it is arguably one of the most enjoyable modern programming languages and a major change form the FORTRAN programming these researchers were familiar with.

Wood, William A. and Kleb, William I. Exploring XP for Scientific Work. IEEE Software 20:3:30-36, May/June 2003.

While 2545 lines of code is not very useful for most commercial projects, having spent 13 years in a previous incarnation on research software in numerical analysis and statistics, I know a few lines of code may incorporate many person-years of hard won knowledge. Consider that this small piece of code "delivers a software test bed for evaluating the performance of a numerical scheme to solve a model advection-diffusion problem. The model employs a multistage Runge-Kutta strategy for temporal evolution with multigrid sequencing. The particular algorithmic research feature is a strategy for the pointwise optimization of the Runge-Kutta coefficients to achieve particular damping characteristics as a tool for convergence acceleration."

The typical commercial developer would need to spend a couple of years on a masters degree to be able to write this kind of code. But I digress. One of the most interesting aspects of this paper is that the single pair of programmers produced 912 lines of production code (the remainder was test code and utilities) at the rate of 27 lines per hour for the pair. On previous projects, programmers produced 12 lines of production code per hour, or 24 for a pair of programmers. However, they had to deliver 2144 lines of code to achieve the same level of functionality as the XP application, more than twice as much code.

In the project, relentless refactoring combined with Ruby advantages over Fortran where key considerations that more than doubled productivity in a NASA project on an initial project with a new development process and a new language. On the average, FORTRAN takes 107 lines of code per function point and Ruby lies somewhere between Perl (21) and Java (53). I would expect on future projects they could push productivity gains even higher.