A quiet meeting this time, with just me, Miquel and newcomer Brett showing up to discuss Peopleware by De Marco and Lister (Looks like you didn’t choose the right one to come along to – usually we have more people and so the discussions flow a bit more).

Miquel started off the discussion by saying that he liked the book. He found it full of common sense ideas that companies generally ignore (or even do the opposite!). I liked the idea that most problems on software projects are sociological rather than technical.

Brett said that he had seen teams really coming together usually when there was a tight deadline to meet. But this didn’t usually last long. We then talked about overtime, which the authors are very much against. As a short term tactic to get a release ready it is fine, but once you start doing it for more than a few days then the downsides outweigh any advantages.

Miquel asked if the extra chapters in the 2nd edition had added much. There was a general consensus that the original book had covered most of the territory, so the extra chapters didn’t add a great deal.

Brett then said that although he had been an agile/XP enthusiast for some time, he hadn’t been able to apply these ideas because his work had always been quite isolating. Also, no-one he worked with was interested in trying any of these ideas out. I described how I use ideas such as the daily stand up meeting to help communication within the team.

Miquel pointed out that a literal reading of the book might suggest that stand up meetings are a waste of time and that everyone should be shut up in their own little office. This goes against a lot of agile thinking. But we agreed that if you look at what De Marco and Lister say closely they are against pointless status meetings and huge open plan spaces. Proponents of agile would tend to agree that stand up meetings should be short (that’s the reason you stand up) and that the best development environment is the war room. So there isn’t really much disagreement there.

I have read the book before, so there were less ‘a-ha!’ moments for me than the first time around. One thing I didn’t remember was the idea of a quota for errors, whereby a manager asks the members of his team what dead ends they have been down recently. The answer should not be ‘none’, because you would like people to experiment, which means sometimes failing.

Miquel liked the part at the beginning about the ‘High-Tech Illusion’ which makes managers think that they should spend their time thinking about technical issues rather than people issues. Not only are techie types better at solving those kind of problems, there is also this illusion that we ‘work in computers’. In fact, unless you are developing chips or writing operating systems you are just applying technology to solve real problems.

We moved on to talk about the idea of moving your development team away from the corporate building to actually get your project done. This sounded pretty radical and I was worried that it could hamper communication with other teams and with internal customers. I wonder if people really do this? I preferred the idea of getting your people to stay on extra days after a conference hotel to get some uninterrupted work time.

Finally we discussed the Black Team, which was an elite team of testers in IBM. The book holds them up as the best sort of jelled team, with their own in-jokes and even their own dress code (Black obviously). I was slightly concerned that their approach would alienate the people whose code they were testing. Lean teaches us that we should optimize the whole. If the feared Black Team don’t work well with their peers, will the whole development organisation work well?