Review of Agile Coaching

The book: Agile Coaching by Rachel Davies and Liz Sedley (September 2010)

Why I chose this book …

I bought and read this book when I was approaching the first engagement where my role would be solely to coach. In nearly three years at ThoughtWorks, all of the projects I had worked on until January were either pure software delivery, or co-sourced delivery, where coaching of the team was a happy side effect of the work we did.


This is a great book for first time coaches. It consists of four parts: the first one covers coaching in general and people skills, and the rest walk through Agile practices and how to coach teams to use them. The last section also includes a chapter called “Growing You” which reminds the reader to look after their own skills – and sanity:

“It’s vital to invest in yourself and your own learning so you can grow as a person and keep your ideas fresh. You also need to take care of yourself in order to cope with the day-to-day demands of being an Agile coach.”

The good bits

The book is straightforward and easy to read. The content is broken up with lots of short stories and examples, which I really like – I find this helps to understand the points better.

The book encourages the reader to help the team to think for itself and make mistakes:

“Your goal is to grow a productive Agile team that thinks for itself rather than relying on you to lay down the Agile law. Showing people how to be Agile isn’t enough; they need to change how they work and how they think in order for Agile to stick.”

There are lots of practical recommendations and exercises for how to achieve this, which was great because it was immediately useful and applicable – I often found myself wanting to get into work and try out something the book had suggested. Alongside this, the authors pointed out common hurdles to introducing new practices, often illustrated with examples from their own experience.

I also enjoyed the chapters on development. The book isn’t a technical read and doesn’t try to be, but I thought it dealt reasonably well with the social issues around collective code ownership, refactoring, incremental design and pair programming.

Each of the chapters in the book is self-contained, so you can either dip in to the bits you want or read it from cover to cover.

The bad bits

I can’t really point to anything I disliked about this book! For more experienced coaches, it might not be as useful – I don’t think it contains anything groundbreaking or new.


I would definitely recommend this book for anybody looking to start coaching Agile, looking for a good general read on the subject or some tips and techniques for introducing Agile to a team.

Review of Head First Design Patterns

The book: Head First Design Patterns by Eric T Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra

Why I chose this book …

I switched from BA back to development last year and was looking for good books to learn from, and one of my friends suggested HFDP. I didn’t know much at all about design patterns – I’d only really encountered MVC.


This is a book to work through rather than a reference book. It presents a series of design patterns with exercises including code ‘fridge magnets’, crosswords and general challenges. The code samples are all in Java, but very simple and should be no problem for non-Java devs – there is a very positive review from an ActionScript developer on Amazon!

The patterns it covers are: Abstract Factory, Adapter, Command, Composite, Decorator, Facade, Factory Method, Iterator, Model-View-Controller, Observer, Proxy, Singleton, State, Strategy, Template Method.

In the appendix, it also covers: Bridge, Builder, Chain of Responsiblity, Flyweight, Interpreter, Mediator, Memento, Prototype, Visitor.

The first time I tried to read the book I put it down after I’d read about half of it, because I was struggling to relate it to the real world. I picked it up again when I was also reading Pro JavaScript Design Patterns, to try and understand that better.

Although I did read the whole book in the end, I didn’t follow the exercises – partly because I was using an e-reader, and partly because I just didn’t want to spend that much time on it. By the time I finished, I felt that I had got what I wanted out of it, which was a high level understanding of the patterns, and the ability to better recognise where I was using them and have a conversation about them.

The good bits

The book is really easy to read and follow, and mostly quite fun to read, which is its main strength, and this also shows in the reviews on Amazon. Each pattern is introduced using a story of somebody asking for a software solution. Often the authors use conversations between a fictional team of developers trying to solve the problem to explain the concepts. There are lots of diagrams and “Q&A”, reviews of what you should have learned, and a nice summary at the end of each chapter, which was good to refer back to.

The book also explains and emphasizes OO principles, and how they are linked to each pattern, which I liked. The extra summaries in the appendix of the patterns that didn’t quite make it into the main text were also really useful.

The bad bits

My main gripe with the book is that the stories and code samples are too far removed from real life situations, which made it more difficult to grasp some of the patterns first time around. The second time I read it, I had a lot more context and could relate what I was reading to real-world code I’d seen on projects.

The puzzles and exercises don’t lend themselves well to reading on an e-reader. I also grew slightly tired of the ‘Fireside Chats’ between design patterns, and after reading about two thirds of the book I began to wish they would hurry up a bit more.


I would recommend this book as a good read as an introduction to design patterns, especially for people who have enough coding experience to recognise the patterns in what they’ve done but don’t really know much about them. If you already know a fair bit about patterns and just want to brush up or read up on a specific one, you’re probably better off asking the interwebs :)