Agile Project Management with Scrum (Microsoft Professional)

I found this book to be an excellent introduction to the subject, however it was sparce on details and practical application. There were a lot of the author's experieces which I thought were useful dos and don'ts. I really expected more details on how to implement Scrum and was disappointed at the lack of real details.

This is a good account of Scrum practices as used "for real" in several case studies, plus some general evangelism and two very useful appendices on Scrum rules and terminology definitions.

I do think it has become somewhat hard for Schwaber to imagine what it is like NOT to be familar with Scrum, as it is so deeply embedded in his thinking and practice! For instance, he uses the term "sashimi" early on without bothering to define it in Scrum terms - that comes later (Hence the 4 stars instead of 5. Would really like to give 4 1/2.)

His other book "Agile Software Development with SCRUM" has more in-depth coverage of the subject. It includes a fuller account of the essential difference between defined and empirical processes which is at the heart of Scrum and other agile methods. In this one, he does include the same reference to the (hard to find!) industrial engineering textbook that explains this, but in a more offhand way - just quoting a key paragraph a couple of times.

Perhaps the best sequence of reading depends on your role. If, like me, you are a developer, the first book is, I think, more rewarding for in-depth study and relationship to Agile principles in general, while this one is a good follow-up on implementation realities. For a manager wondering whether Scrum deserves exploring, this book will give a strong (positive) answer to that question, and can be followed by more in-depth study with the other book.

Excellent book. It presents Scrum in real-world environments. It talks about imperfect real-world situations and constantly *adapting* - and how Scrum is a top-notch tool to produce results. One of the great benefits of Scrum is the CONFIDENCE it gives developers and product owners - because real results are produced every 30 days. Anyway, this book is an excellent teaching tool because it shows how Scrum can help in the kinds of imperfect projects and environments we have all experienced. Highly recommended.

... you must not be taking Scrum very seriously.-)

For what it's worth: I read this book before I read the first book ("Agile Software Development with SCRUM"). I didn't have any trouble reading them in that order. I found this book slightly more helpful than the first. It seemed to cover the mechanics of Scrum in more detail. More importantly, it help me understand how to fit Scrum into the context of the real world.

The Scrum principle is simple. It starts with some common observations: that projects generally succeed when someone sidesteps the formal process and gets the job done anyway, and that big teams spend more time tripping over each other than typing code. Scrum starts with the radical idea of announcing that we're going to do what we were going to anyway, then mixing in big handfuls of eXtreme Programming.

This is a good second book. It attends less to the basics of running the team and working with the customers and corporate surroundings, although Schwaber does present all those basics. Instead, the focus is on case studies, especially ones that look like bad matches to Scrum management style. I like that emphasis: typical methodology books assume perfect compliance with fragile or rare prerequisite assumptions, then wash their hands of any circumstance that doesn't meet their delicate needs. This is a good bit more realistic - it's about the whole concept of cut-and-fit to get the most out of Scrum despite unfavorable situations and stakeholders.

Late in the book, Schwaber makes the point that people will do whatever they're rewarded for. However obvious this sounds, it's an ongoing source of corporate inanity. Suppose that percent of the code covered in testing is a major goal: programmers will dutifully eliminate handling of exceptional conditions or invalid preconditions for which tests are hard to generate (NOT an improvement). Suppose reduced development time is rewarded: watch testing time plummet and bug counts soar. I agree that progress must be measurable, and agree at the top of my lungs that the wrong measurements are worse than none at all.

Still, one theme comes through again and again: that, when the going gets weird, typical practitioners will rapidly find themselves in way over their heads. He, with more experience than any other Scrumster around, exerts the limits of his creativity to get past problems of fairly ordinary kinds (like intrasigent management). It's certainly a good recommendation for his consulting services. It's just not a message that a novice wants to hear. I have the strongest reservations about his fondness for bullpen office environments, as well.

There's good to be had here, I'm sure, but I'd have to see Scrum in action before I could really internalize the way it's meant to work.

//wiredweird

PS: It's just an amusing typo, not a deliberate act that "the ... team was going to use Scum [sic]," p.64