Part I is about making sure you know why becoming gile is important and beneficial to you and your work environment. It will teach you how to promote Scrum, its advantages and challenges, and the different ways to go about it: Start Small or Go All In? Stealth or Public Display? Things like that. Pointless theory? Not really: everything is well documented, with success stories to support one way or the other.

This part was very interesting from a psychological point of view: it deals with individuals and their possible reactions to becoming agile. You'll meet skeptics, followers, saboteurs and diehards — no hope? Well, of course not: you'll learn how to deal with each one of them in the best way possible. This part will also introduce you to new roles and responsabilities related to Scrum.

Up next, Teams. You're no longer dealing with single-minded individuals, but with more complex groups. New challenges emerge, mostly related to communication and people interactions. I particularly enjoyed Chapter 13 — The Product Backlog, which provides invaluable insights on this important everyday tool. Chapter 15 — Planning is another interesting read: it teaches you a lot about planning vs. estimating, and coming to compromises to meet deadlines.

If you made it up to here, then you're nearly done. You probably know most of the tricks by now, but there's still a lot to learn. Chapter 17 — Scaling Scrum is definitely worth reading, even just for the analysis between formal and informal communities, while Chapter 19 —Cohexisting with Other Approaches almost feels heretical at times: mixing Scrum with Waterfall? Is that even conceivable? Yes. Sometimes it's the only way, especially when you have to deal with compliance to standards like ISO9001. Once again, the author has a nice success story on how a company passed an ISO9001 audit by providing documentation in form of photocopied notes and by adding a single failing test to persuade the auditor that the automated test suite was not rigged. Priceless.

Only two chapters in this part of the book, which mainly deals with (self) assessment and progress analysis. Still worth a read, but you can safely leave it out for when you succeeded with agile.

From a technical writing point of view, this book is spotless. I should keep it on my desk to remind me how technical documentation should be written, except that… it's not a technical manual of course. But the formatting and the way content is laid out can make the most skilled technical writer very jealous: there's never a huge blob of boring text, never a series of pointless pictures: Mike Cohn (or his editors) did a terrific job composing this book.

You can start reading it from any point and it still makes sense, diagrams are simple and clear, and yet extremely useful, and so are the reference tables and spreadsheets. They never hurt, they are always in the right place, at the right time. And bold text is aptly used at the start of list items, so that even if you skim through the key concepts will still make it to your brain. Excellent.

Reading this book is like listening to a seminar hold by some charismatic icon like David Allen or JoAnn Hackos: you never get bored, and you constantly learn something. Mike's informal and conversational style is one of the main reasons why you should read this book instead of others on the subject: he is a great communicator, and he knows how to make his point across.

As an added value, Mike also uses two types of boxes throughout the book:

• Things to try now — Whenever a new strategy or practice is introduced, you'll find one of these boxes containing a bulleted list. “Commit to running the next two or three sprints without any overtime”, “Do you understand what motivates every other person on your team? If not, find out. How? Ask them.”, … these are just examples of some of the author's reccommendations to put you in the right track.
• Objection — Either actual quotes from customers and employees, or possible statements which may come out throughout the process of adopting Scrum. Things like “If the product includes less than what we've planned, no one will buy it”, or “My team won't self organize; team members are too passive and look to me to lead”, … of course, what makes these objection boxes valuable is not the statement themselves, but the tips on how what to do about them. There's not a single one left unanswered: you really feel you're covered in any situation.