I am a fan of Scrum, I’ve seen it work and it can benefit most development processes. But this book did not enhance my understanding nor do I believe it would encourage anyone to use the process. It comes across as a big advertisement, the author glosses over problems, he points to advantages that are not unique to Scrum, and generally fails to provide any concrete examples of why I should use Scrum.
The book does a good job of describing Scrum, its components, and to provide a basis for using the process. This is covered in the first 1/3 of the book. I believe that most readers should stop at this point. The rest of the book explains why Scrum works, its value, and advanced topics. But these aren’t convincing and I don’t see a real correlation to Scrum.
Then there are the contradictions.
The authors explain how having a technical writer on the team can relieve the developers of writing the documentation – which is required for the sprint delivery, and how including a tester so the developers don’t have to test their own code. Yet, two paragraphs later he talks about people being interchangeable, “Scrum avoids people who refuse to code”, there are no titles, no exceptions. And in one of his case studies he mentions the advantage he gained by putting off documentation until later in the project.
Later in the book, a case study talks about a design architect who is referred to as female in one sentence and male in the next. An earlier case study talked about an architect who left the project due to lack of control, and how not having an architect was a bonus for Scrum.
They mention the value of getting engineers into “flow”. Yet also insists that engineers work in bullpens, and that the lack of conversation indicates a poorly working team. They seem to believe that getting into the zone is free. In a later study, he talks about the advantage of having engineers in adjacent cubicles so that they only need to stand and talk over the cubicle wall.
Other suggestions include deferring peer reviews until after a sprint – “they have nothing to do with completing the project.”
Even the cover tie-in feels weak. (I have the cover with the psychology test where you identify colors of text indicating names of different colors.) He uses this text to illustrate the need for a team to focus. That consumes about 1.5 pages.
Apparently, applying Scrum practices to writing this book failed. They could have used a good editor and some better reviewers. They often aren’t clear on what practices are really important to Scrum. If I hadn’t practiced Scrum, this book would not help move me toward trying or even supporting the practice.
