Scrum is a management technique used in IT software development, and this was once considered one of the key texts.

As a non-IT person who now works with IT, this was interesting to me to look at Scrum from a management rather than an IT perspective. In this respect, the book comes up short, in that it was written in 2002 and is fairly full of jargon that is a) very IT development-heavy in a US corporate context, and b) that jargon is more than ten years out of date (even I can detect that!).

There are some practical aspects of Scrum, such as task estimating, which are not covered at all - which, considering how central task estimation is to Scrum is something of an oversight. And the book is very poorly edited. There is a lot of duplication of message and of text, which does give the impression of a tub-thumping endorsement of Scrum that some readers will find irritating. The author has practical experience of implementing Scrum, but his examples all start from the premise that he was brought in as a senior manager to make a project work, so his implementation of Scrum was made easy by a) his ability to drive through change with a degree of authority at his back, and b) an assumption that all his team are going to be 100% devoted to their work 100% of the time. A nice assumption, but one often at odds with the real world.

Nonetheless, I read this book as a refresher on Scrum and found it quite helpful. I'd been employed in a development environment as a tester some four years previously and worked with Scrum. A copy of this book was included in the cost of a Scrum Master training course, but to be honest I had not read it until now, when after a career break of some four years, I found myself in a new testing environment working with an IT systems development contractor who was employing Scrum. I found the case studies and some of the discussion of the philosophy of Scrum more interesting than some other readers with more of an IT bent might, which is a bit of a shame as they are the book's intended audience rather than people like me who are more people systems people. (I was quite amused by a short section explaining where the term 'Scrum' comes from, and debunking some people's ideas about that.)

As I said, the book is very poorly edited. There is one instance where a person being talked about in a case study changes gender in the middle of a paragraph, and a psychological test on perception, which relies on a particular colour graphic used on the cover of the first edition, is still referred to even though a subsequent edition has dropped the graphic! Other graphics in the book appear to be 1990s clip art or very basic chart work, and give the impression of much cheapness. And Pearson seem to have gone for a really low-cost approach to the book; my copy appears to have been printed on photocopier paper. I know I got this book for nothing, but the care that Pearson have lavished on this later edition suggest that that's all they think it's worth.

Really, the book needs a re-write to pitch it to a slightly different audience and revision to make the practical Scrum lessons a bit more relevant. ( )

One of the seminal books on scrum, however this is getting dated. Quite a bit of the advice in the book does not match contemporary leading practices or definitions of Scrum. ( )

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. ( )

This book contains a good overview of the philosophy, practice and jargon of the Scrum management system, and would be useful for someone trying to implement one in their organization. However the presentation is embarrassingly undercooked. The text is awkwardly stitched together from multiple contributors, typos abound, the illustrations appear to have been dashed off in Microsoft Paint, and too much time is spent asserting that Scrum is the greatest thing since sliced bread instead of letting the technique speak for itself. It's probably nothing a few more passes with an editor couldn't fix, but it's a shame that a book that extols the virtues of a fast-paced improvisational work style should come off like a rush job.

Errata:

• pg.7, para. 5: "Product backlog is never finalized." should be "The Product Backlog is never finalized."


• pg.16, para. 2: "The effect on the team was not to immediate respond..." should be "The effect on the team was not to immediately respond..."


• pg. 122, Table 6.1: The columns in the last row of the Scrum vs. Football comparison table are transposed.


• pg. 135, para. 1: The gender of the pronoun is inconsistent. The "architect" of the project is first referred to as "her" and "she" in one sentence, but with the pronoun "his" in the following one.

( )

Messy, careless, and bloated. I like the idea of Scrum, and I've seen it working, but this is not a good resource to get started with it. ( )