I’m tempted to say that the turnout was a little ‘lean’ after last month’s meeting with the Poppendiecks. This time around there was just me, Tom, Steven and first timer John to discuss Alistair Cockburn’s Agile Software Development: The Cooperative Game (2nd edition).

Tom admitted that he had skipped the first few more abstract chapters, although skimming through them during our meeting he was interested to see that these early parts had more pictures and photos. He liked the book and the way Alistair Cockburn never says “This is what you should do” but found that there were times when he seemed to go into more detail than necessary in describing certain techniques. John had not read the second edition, but had previously read the original. He liked the idea of software as a cooperative game and had tried out the “information radiator” idea at work.

Steven on the other hand wasn’t so keen – he found that the book was too long. This mirrored my feelings. I really liked the first edition, which changed the way I thought about software development. But all of the extra material really weighs it down and obscures the central message. In particular, chapter 5.1 (i.e. the extra material added onto chapter 5) is almost 100 pages in length and could almost be a new book in itself! As with the first edition, I like the way the author does not say “I have come down the mountains with the tablets, here is how you make software”.

Looking into more detail at the material, Tom said he liked the idea that you should force yourself to develop in increments even if you can’t deliver that way. Recent real project experiences have led him to believe that it is worth doing incremental development even if you have to go through this kind of pretence. He also liked the sine waves on p167 showing healthy and unhealthy patterns of requirements and code stability. This also resonated with real project experiences.

I was interested in the section about motivation “Rewards that preserve joy”. I found the idea that praise could be demotivating to be a counter-intuitive one. We discussed how to give pride-in-work, pride-in-accomplishment and pride-in-contribution which are what the author suggests. I mentioned the idea that was mentioned by the Poppendiecks that you should try to run your corporate projects like open source ones, which give rewards other than monetary ones. Tom said he thought that the book contained a stereotype of open source development and that many developers in the high-profile projects are actually paid to do their work these days. John suggested that perhaps you shouldn’t give praise because once you’ve won someone’s approval, you don’t feel the need to do it again.

We then moved on to discuss the idea in the book that rather than mandating coding standards and so on it is better to have an archive of examples which follow these rules. Then newcomers can quickly get up and running. John mentioned the story where Alistair Cockburn copied some Smalltalk code and ended up using the MVC pattern quite by accident.

I mentioned that I like the idea of having a project charter (p182) which helps everyone pull in the same direction by making it clear what the priorities are and what trade-offs can be made. This reminded me of some of the ideas from Lean where you need to make it clear what value is being created by a project.

The discussion moved onto more general topics of Agile, many of them about John’s environment where there is no test driven development or continuous integration. He said that creating an installer was hard work, to which I gave him the standard agile suggestion on this: do it often, so that you have to become good at it.