Tuesday, August 31, 2004

The Deeper Theory of Scrum

In response to requests for presentations on Scrum, my lectures in Minneapolis in 2003 are the best material. I'm moving it back to the top of the page for those interested in checking out the slides and the first slide says it all:

The Zen of SCRUM
So simple, anyone can implement it!
So easy, all can benefit!
So subtle, few achieve transcendent performance …
How is it that project manager does nothing, and achieves everything?
Interlocking principles emerge product out of chaos
Yet when novice removes one Scrum principle -- engine never fires …
Who can know why?
ScrumMaster must understand deeply and practice rigorously.
Only then will team members say, “This experience changed my life!”

Date: Tuesday, March 18, 2003
Topic: "Agile Software Development with SCRUM with Application to Healthcare Mobile Platform Development"
A distinguished lecture by Jeff Sutherland, inventor of the SCRUM software development process.
Location: O'Shaughnessy Education Center (OEC) Auditorium, University of St Thomas, St Paul Campus
Schedule: 5:30pm - 7:00: Hors d’oeuvres
7:00 - 10:00: Lecture
10:00 - 11:00 Questions and Answers

I had quite an evening in Minneapolis giving a three hour talk to OTUG followed by a discussion period that went to 11pm. My goal was to give some depth to the background and techniques for leading a Scrum development team to people who were already technology leaders. There are so many Scrums going on today around the world that it is easy for people to go through the motions without really understanding the movements. There is Tai Chi by the novice and Tai Chi by the master. They are the same Tai Chi but they are so different in effect that they appear to be two totally different things. I tried to outline the Zen of Scrum for those who are ready to practice.

The slides from the lecture are like the score of the music for the symphony. You can't really hear the music without being there. Yet people are asking for the slides which consist of two presentations. The second presentation was also given at Medtronics to a large group of their developers during the afternoon before the OTUG evening event. The two slide sets are an attempt to articulate a basic principle of Lao Tsu. "How can the project leader do nothing, yet achieve everything?"

Scrum: Theory and Practice
The Pursuit of Technical Excellence: Inventing and Reinventing Scrum in Five Companies

Friday, August 13, 2004

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.