Hide this

Results from Google Books

Click on a thumbnail to go to Google Books.

Agile Software Development with Scrum by Ken…

Agile Software Development with Scrum

by Ken Schwaber

MembersReviewsPopularityAverage ratingMentions
271541,869 (3.54)1
  1. 00
    The Mythical Man-Month by Frederick P. Brooks (billmcn)
    billmcn: If you're interested in software management, you have to read the classic.

Sign up for LibraryThing to find out whether you'll like this book.

No current Talk conversations about this book.

» See also 1 mention

Showing 5 of 5
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. ( )
  pratalife | Feb 9, 2014 |
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. ( )
  Nodosaurus | Oct 28, 2012 |
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.


  • 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.

( )
  billmcn | Dec 20, 2010 |
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. ( )
  jorgearanda | Dec 11, 2009 |
Showing 5 of 5
no reviews | add a review
You must log in to edit Common Knowledge data.
For more help see the Common Knowledge help page.
Series (with order)
Canonical title
Original title
Alternative titles
Original publication date
Important places
Important events
Related movies
Awards and honors
First words
Last words
Disambiguation notice
Publisher's editors
Publisher series
Original language

References to this work on external resources.

Wikipedia in English (4)

Book description
Haiku summary

No descriptions found.

No library descriptions found.

Quick Links

Swap Ebooks Audio
29 wanted

Popular covers


Average: (3.54)
1 1
1.5 1
2 6
2.5 1
3 12
3.5 5
4 14
4.5 5
5 7

Is this you?

Become a LibraryThing Author.


Help/FAQs | About | Privacy/Terms | Blog | Contact | LibraryThing.com | APIs | WikiThing | Common Knowledge | Legacy Libraries | Early Reviewers | 91,487,642 books! | Top bar: Always visible