Review - Succeeding with Agile
I just finished reading most of Succeeding with Agile: Software Development Using Scrum by Mike Cohn. I skipped the last part of the book, particularly the sections discussing scaling scrum. This is part of my objective to understand scrum, its benefits and drawbacks.
My knowledge before reading this book was quite limited - I couldn’t define a sprint, product backlog, or identify a product owner. I could however, tell you that agile methodologies generally forgo initial specification and research. Beginning the book, I was honestly a little skeptical. I have long seen problems with sequential development approaches like waterfall, but I wasn’t convinced that abandoning sequential development was absolutely necessary.
The book is not written for someone unfamiliar with the basics of scrum and it says so quite clearly in the introduction. After reading a few pages, it was clear I needed to get a basic understanding of the terminology, and so I found this information elsewhere before continuing far in the book. A few pages of definition would have been very helpful and avoided the need to get this information elsewhere.
The book starts with a discussion of why you should adopt scrum. Being a little skeptical, I found this part read like a sales pitch, as though Cohn was trying to convince me to try scrum. It quite nearly convinced me to abandon the book. While the information may be useful when deciding whether to try or adopt scrum for a project or organization, I think the discussion could be written differently to sound less like a sales pitch. Indeed, Cohn works as a consultant for scrum and the discussion strongly suggests hiring outside consulting talent.
The remainder of the book was informative and well laid out, with each section describing a particular element of scrum, and the discussion generally focused on best practices for implementing scrum. This makes a lot of sense given the books title. As someone who hasn’t yet worked with scrum, I still found the information useful and complete, although the frequent “things to try now” didn’t really apply.
On the whole, I found the book a little confused as to the audience. In some sense, the “things to try now” and other sections seemed to be written for someone looking to improve an existing scrum process. Other sections, such as the introductions sales pitch, seemed to be written for someone deciding whether to try scrum. Unfortunately, as someone on the outside, I found the book a bit lacking. In particular, the book describes automated testing as key to scrum, but then doesn’t discuss how to use scrum for a large legacy project that lacks unit tests where it is simply not possible to start from scratch. The practicalities of real software development were missing and for the mixed audience, it was sorely missing.
My other main comment was the book failed to describe any negative aspects of scrum. The book has many “objection” discussions as a way of dealing with antagonists, but in each of these, scrum always wins. I simply don’t believe any process is without flaws, and I would have liked to at least have these problems better identified. An argument that omits discussion of the problems simply isn’t convincing.
Despite these problems, I think the book was a good read. I am optimistic that scrum would solve some of the problems with waterfall and I think the book is a good reference for any project using scrum.