The same six people showed up for this meeting as last time: Adrian, Graeme, Miquel, Steven, Tom and me. Most of us had read the whole book, with just one or two of us not quite getting to the end.

Miquel started the discussion by saying that overall he thought it was a good book, covering a set of things which could be characterised as Common Denominators from Scrum, XP, Domain Driven Design etc.

Having not read DDD, Adrian was interested to know which parts mirrored that book. Graeme mentioned the Project Glossary, which has many similarities to Eric Evans’ Ubiquitous Language. (Later on, I pointed out that Command-Query Separation mentioned in the ‘Tell, Don’t ask’ section is like Side-effect free functions also mentioned in DDD).

Adrian said he found it less evangelical than other agile books, XP Explained in particular. He was especially keen on the ‘How Does it Feel?’ sections. Miquel agreed that he liked them too. Graeme also mentioned that he felt it had a moderate feel to it. Later on in the discussion he likened the ‘How Does it Feel?’ sections to unit tests. You know if your practice is working if you get the right output.

Steven was a little worried that it might be a little simplistic and that you only needed to read the chapter summary to know what was going to be said.

Talking about things that we didn’t like, Miquel felt that the keeping of a project log would be difficult and that this idea was a little Utopian. Adrian admitted that he used to do this, but didn’t do anything so formal any longer. I suggested that it would be difficult to write a good enough log that it would be useful for others encountering similar problems later on.

I pointed out the section where it says that there are no roles in Agile projects, which seemed a little odd to me. Adrian thought that they meant rigidly fixed roles. Graeme pointed out that there is discussion of the Lead Programmer being the Architect, but otherwise this topic is rather fuzzy in the book.

Adrian suggested that there was a similarity to XP Explained v2 with its Primary and Corollary practices. I didn’t feel this, it felt more like a collection of practices but without an overarching structure. Graeme pointed to the section at the end where there is discussion of introducing Agile. This part does seem to suggest that some practices should be brought in before others. He went on to say that some of the practices seemed to be merely teaching good manners.

I pointed to the section where there is discussion of using an automated issue tracking system. I felt this was interesting as many agile practitioners are very keen on paper based systems. Adrian suggested that if you are in a situation with a large number of bugs coming in then you’ll need something like Bugzilla, but that your aim should be to reduce the bugs so much that it is no longer needed. Tom said that in his previous job they’d used Bugzilla and it had worked well and Graeme mentioned its use in Open Source.

Adrian brought up the question of whether it was a good or bad thing that this book uses less of the Agile Jargon than others. I said that I thought the Jargon was useful in a similar way that Pattern names are useful. It gives a handle to make discussion easier. However, I thought that perhaps toning this down was fine for a book aimed at beginners, such as this.

We then moved on to a discussion about the things in the book that seem like good advice, but are not really agile. Adrian highlighted ‘Tell, Don’t Ask’, ‘Cohesive Code’ and ‘Substitute by Contract’, while Tom pointed out ‘Useful Error Messages’.

I mentioned the advice to ‘be the worst member of the band’, which is easier said than done. Adrian said that he’d seen situations where people were not hired because they would be too good and would threaten the existing lead programmers.

The next topic was Pragmatism versus Agility, since this book comes from the Pragmatic Programmers. Steven suggested that being Agile is about being pragmatic so only doing what is needed today. I suggested that this book is almost a sequel to the original Pragmatic Programmer book. Adrian had an interesting take on the difference between the Pragmatic and XP philosophies. He suggested that the former was more about making things better in your current environment, where XP tends to take the opposite approach of trying to change your environment to make things better.

We rounded things off by talking about where this book sits in relation to others. Graeme thought that this book had a different focus to others such as XP Explained in that it focusses heavily on the individual. Adrian said it was a book to give someone who was sceptical about agile and said that he would be giving a copy to his manager.