Two books - one recommendation

It has been a busy week but somewhere along the line I found time to finish both my current novel and my serious book.

The novel was Newtons Wake by Ken MacCleod. I really liked his early works (The Cassini Division, Stone Canal) but his last couple have been a bit of a disappointment. In truth I struggled to finish Newton’s Wake, he had some good ideas in the book but they just didn’t hang together.

On the other hand I really enjoyed Effective Coaching by Myles Downey. I got interested in the subject of coaching a couple of years back and everything I’ve learned about it since makes me think it is a good thing.

Downey’s book is a good introduction to coaching and makes some good points. Little of it was completely new but that was because I read John Witemore’s book Coaching For Performance a couple of years back. That is another good book on the subject and also worth reading.

I’m not a professional coach and I don’t think I’ll ever be one, but the techniques are useful when your trying to managing people or just trying to help them in daily work. So, if you’ve not encountered coaching before I recommend reading either of these books. The two books are complimentary really, reading them back to back probably isn’t worth it but reading one then reading the other a year or two later as a refresher is worth it.

One quick lesson from Downey:

Performance = Potential - Interference

Couldn’t be more true. Once I get focused on something I can really do something, when I’m only partly interested, or not sure what I should be doing then things go slower. Sometimes you need to go slow on things but sometimes you just need it done. Part of the coach's role is to remove the interference.

Bringing it back to software development, I think one of the things the Agile methods do for developers is to focus them on the task in hand. You can see this when a team is working with a card-and-board system, the card is the piece of work to be done, you focus on it, you get it done. The same is true of pair programming. Its all about removing interference.

Many of the Agile methodologies have a role of project coach - XP has an explicit coach role and Scrum has the Scrum master role. As far as I know those behind these agile methods didn’t draw on the work of Witemore, Downey and others but I think they should, there is a lot to learn from these guys. Unfortunately, once again, the software profession seems to prefer re-inventing the wheel.