I’ve just been reading the excellent new book called Agile Coaching by Rachel Davies and Liz Sedley.
It’s the result of many years spent coaching teams to be agile, and the cumulative experience really shows.
Writing about agile processes often seems to get lost in an abstract discussion of the nature of processes – analysing the team as a Complex Adaptive System and so on. Rachel and Liz comprehensively avoid such mistakes, and keep their advice firmly rooted in practical examples from their own real-world knowledge.
So, at the start of the book, they describe a generic agile process (usually a blend of XP, Scrum, Lean etc), and then use that as the basis for examining in detail how the process really works and how to coach people in using it.
The emphasis is always on the pragmatic application of the process, illustrated with plenty of examples and stories, which makes it very easy to relate to the daily experience of working with agile teams. Each chapter ends with a checklist of bullet points to summarise and reinforce the key messages.
The first section of the book describes the basics of the coach’s role – how to get started, how to work with people and lead change, how to build a team, and when to move on. Some of this would probably be just as relevant to coaching any activity, but much of it is specifically about the issues in applying agile principles to software development. In the chapters about working with other people there’s plenty of good advice – how to give feedback, resolve conflict and so on – that would make great reading for anyone who has to work with other people in ANY environment. I particularly like the bit about “Emotional Outbursts in Meetings”..!
The next section walks the reader through the iteration processes in more detail. There are chapters covering all the main elements of an iteration, including standups, stories and story cards, acceptance tests, estimating and planning, and keeping progress visible. As usual, there are plenty of hints and tips for coping with problems – ideas for what to do when the team is dispersed, or work at different hours, or just hate planning.
The third section focuses on issues of quality. There’s lots of techie detail here that’ll be familiar to anyone who’s worked in an agile development team – discussion of unit testing, continuous integration, pair programming and other practices. But the key focus is on how all these practices work to the end goal of running, tested, maintainable software. And again, some pointers for techniques to try when things are difficult.
Finally, there are some chapters on listening to feedback – in terms of process, that includes demos for external feedback, and retrospectives for internal feedback. Retrospectives in particular can be quite difficult to get right, and there’s a range of techniques to try as well as a checklist of “Retrospective Smells” (like “History Lesson” and “Hot Air”) that can indicate that the retrospective isn’t working as well as it should. The “Growing You” chapter gives some ideas for planning your own personal development.
It’s also a great grab-bag of hints and tips, and reminders of key principles.
There are plenty of pointers scattered throughout the book to further reading, from personality types to Kanban to pair programming. And as for the stories and examples that illustrate the chapters, having worked with Rachel at Connextra, I recognise some of them, and can vouch for the fact that they’re genuine..