Craig Larman at KI.

A few weeks ago, Craig Larman visited KI and had a one day presentation about agile development to some 30 people from different professions at KI. I was there and some parts were very interesting.

Of course, most of it is not new for the developers, but the we got some good firepower for convincing management about some more realistic practices. KI haven't been very good at embracing the new and hot in development methodology the latest years, but hopefully this is about to change.

So, what about the presentation? The first part, 'til lunch, were mostly statistics and "management-convincing" arguments why agile is good practice. The only really interesting part were Larman's dissecting of Royce's original paper on the waterfall method. It's really totally obvious to anyone that actually reads the paper instead of just looking at the graphs, that Royce really is against the waterfall method except for very small projects when all requirements are known upfront and cannot be changed.

The afternoon session contained much more of interest, at least for me. He talked some about good tools to practice good Agile, naming continuous integration, test driven development, good version control, self organizing teams and good dissemination of information through wikis as key points. IT Center - that is, me and me 4 colleagues - at KI are pretty good at this. The only weak point is our use of Wiki. I have some plans for this, since I totally agree with Craig about this. Wikis are unique in the way they combine simplicity with expressability and information processing.

After this I finally got something really worthwhile out of the presentation; Craig presented the first good argument for pair programming that I've ever heard. Regarding Pair Programming I'm probably like most programmers: very skeptical. I have tried it a few times and I don't like it. But anyway, Craig's premise was a situation where you had programmers working on several projects simultaneously, and also having maintenance work on applications they had the responsibility for.

In this case it's very easy that people get unproductive, due to insistent interruptions from other projects or immediate maintenance work. Usually this most of the maintenance work is also person dependent. (This situation describes exactly my groups current work environment.) When dealing with issues like this it makes sense to create a rotating schedule where programmers work on one project at a time, or completely on maintenance. When something that is dependent on someone in a project shows up, one of the maintenance programmers pair program with this person to fix the problem, which ensures that the next time this problem appears, there will be at least two persons capable of handling it.

All in all, it was an interesting session and I felt I got out of there knowing more than I knew before. The most important thing is still having someone to have as reference when talking with management about adopting more agile methods.

Maybe I'm imagining this, but it feels like since Craig was here, we've been allowed much more slack in using technology that's not "industry standard", but more agile to solve tasks suited for problems suited for it. For example using Ruby on Rails to create internal test and development tools for bigger projects seems to be totally accepted now.