What’s not optional, Part I+II
This is a strong book, rich in size and contents. It says in the introduction (“How To Use This Book”), “It is not necessary to read this book in order.” I took that literally and started at the end. The last chapter is called “You’re Not Done Yet” and the last sentence is “And with that, you are on your way to succeeding with agile.” Which is the title of the book. By Mike Cohn. Love that.
Succeeding with Agile
I like pragmatic books with sound advice. This book is full of that. So much so, that I write this review having only read two of five parts: One, Getting Started (and this might get you started on much more than just a book), and Two, Individuals. As always with Mike’s books, it’s extremely well written and full of examples. He needn’t have mentioned that it took him years to write it; you notice in every paragraph that it was distilled, rewritten, restructured and rewritten to just convey the few things you really need to know on a topic. Which is important, as Mike seems to cover every topic which ever was, is, or could be relevant for a company transitioning to Scrum.
What I especially like are the “Objection” and “Things to Try Now” side bars scattered through the book, along with an abundance of thoughts and examples from a multitude of people of the Agile community. Objections show common cases made against the introduction of Scrum (“We’re in a hurry. We can’t have two programmers on one task.”) and good arguments to counter those concerns, while taking them very seriously. Things to Try Now are action items which anyone trying to do Scrum can put into practice the next morning.
Getting Started
The first part is the most concise and full go at Transitioning to Agile that I’ve read so far. Actually, it didn’t contain anything particular new to me—but that’s due to all the other things I’ve read on the topic. It’s everything that should have been in Ken Schwaber’s The Enterprise and Scrum but wasn’t—on less than 100 pages. Follow Mike’s advice, and it will be hard (title of his first chapter), but you might actually succeed. Mike covers how to set the stage, different patterns to proceed, how to iterate towards Agility and with which projects to start. Sound advice, well written, and all you will need (to read. I’d still advise you to get the best coach you can find).
Individuals
For me personally, the second part was much more rewarding than the first—but, as I said, that’s due to my personal background. There are quite a few books on organisational change management, but Mike’s chapter “Overcoming Resistance” puts it all in an Agile context, which gives the topic new aspects. The discription of the Scrum roles is without surprises—good—but his remarks on the old roles, like architects, line managers, project managers and how and where people with those roles might find their place in an agile organisation and what obstacles need to be considered—that’s new stuff, and sound advice.
The last chapter of part II comprises technical practices—kind of XP distilled for Scrum. Technical Excellence is, according to Mike, what Scrum teams have to aim for, and, as always, ever improving at that. TDD, Refactoring, Collective Ownership, Continuous Integration and Pair Programming are the five techniques Mike covers. This is the chapter most intensely interspersed with Objection and Try Now side bars, which gives you good material for discussions with your hesitant peers. Mike closes the chapter with a few pages about “Intentional, yet Emergent” Design. Very good. And remember: “Improving Technical Practices Is Not Optional”!.
