“This is not a book for those who are completely new to Scrum or agile. There are other books, classes, and even websites for that. If you are completely new to Scrum, start with one of those.”
— Mike Cohn, Succeeding with Agile
Great. That’s just great. Good job I started with the Introduction first, otherwise the first chapters of this book would have been way too overwhelming!
Succeeding with Agile is a book that doesn’t teach you about Scrum or agile methodologies, it won’t give you a definition of ScrumMaster, sprint, or backlog… instead, it takes all that for granted and teaches how to pragmatically adopt — or better, ADAPT to — Scrum, in the context of yourself, your team, and even your entire organization.
“[…] this book draws on my experience with Scrum over the past 15 years, but especialle the last 4. For the last 4 years, every evening after I spent the day with one of my clients, I would go back to my hotel room and make notes about problems they were facing, the question they asked, and the advice I gave.”
Indeed, this book is a gold mine of information, anecdotes, tips and tricks about everything you could possibly want to know about making Scrum work, at any level. If you have some knowledge about agile development you definitely have some questions: will it work? … is it really more productive? … how can I make my boss understant this?. This book has all the answers you need. Most definitely, it also answer questions you didn’t think of.
If you don’t know what all this is about, then you’d better do your homework first:
The book is organized into five parts of different length, ranging from 20 to over 100 pages. If you read the book from the start till the very end, you’ll notice that the start of each part is like a new milestone in Scrum adoption: first the author makes sure that you are prepared (Part 1), then moves on to deal with individuals and initial resistance (Part 2), then teams (Part 3) and finally the whole organization (Part 4), until you can finally taste the fruits of you labor (Part 5).
In a way, you may well want to carry this book in your briefcase every day you go to work, and read it bit by bit, as you make progress in your quest for Scrum adoption.
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.
I’m not exaggerating when I say that this is by far the best book I’ve read in the past few years when it comes to the way it is organized. Start by reading the table of contents: if you take each chapter out and make a bulletted list of each section you’ll end up with a handy (and free!) cheat sheet on how to promote and adopt Agile methodologies.
This doesn’t mean the book isn’t a worthwhile read, but rather that it can also be used as a reference when needed.
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.
I really enjoyed this book. It took me ages to read it, not only because it’s quite long (450 pages), but also because it’s very dense of information. Another author could have made it three times longer, but I was glad Mike didn’t. I’m pretty certain I’ll keep it near me and read bits from it when I need to: it’s pretty much the Bible of Scrum adoption.
What’s wrong with it then? Not much. Perhaps the only thing I really missed was an introductory 50-page-chapter on Scrum and agile. I know this is not meant to be a book for beginners, but some basic glossary or Scrum cheat sheet would have made it accessible to an even wider audience, at virtually no cost for the author or the readers, who could have just skipped that part.
Anyhow, I give it a 9 out of 10.