This is a hard review for me to write. I have a great respect for both of the authors and what they accomplished in the world of software development. I loved Ken's Agile Project Management with Scrum (Microsoft Professional). However, I did not like this book very much. Even considering that I'm not the audience, I do work a fair amount with management in organizations and I wouldn't give them this book. The book felt it was written in a hurry, it had awkward parts in it which most in the Scrum community would probably disagree with and it over-promised, giving me the feeling that Scrum is the silver bullet that magically resolves all problems. That said, it did also have some really good parts, which I'll try to point out also in this review.
The book consists of 2 parts and a bunch of appendixes. The first part is the "why" which explains why traditional waterfall development is not suitable today and how an empirical process is better suited for the job.
The first chapter is a "we are in crisis" chapter. Unfortunately, the only data it quotes is the CHAOS report, which has been challenged a lot of time already. Next to that, it provides some anecdotal cases. It introduces the Stacey diagram, which is great, except that it is significantly changed and Stacey doesn't use it himself anymore.
The second chapter introduces the basics of empirical process and shows how it resolves problems in traditional waterfall development. It also summarizes major points on self-organization and the "new new product development game" article that influenced Scrum strongly. Also the third chapter explains the idea of just starting and getting and inspect-adapt loop going and that way evaluating whether Scrum produces any results. And chapter four explains the art of the possible and why transparency is essential and how Scrum assists with that. Chapter four was pretty good.
Then, part 2. Chapter 5 is a short introduction to Scrum. Interestingly enough, it mentions that the ScrumMaster is 'a manager' which felt a bit odd and simplistic. The rest of the Scrum introduction was extremely short, just mentioning terms but not explaining them deeply.
Chapter 6-8 give examples on how to adopt Scrum. From small project team (chapter 6) to the whole organization (chapter 8). Chapter 6 ought to explain how to start Scrum on a project level, but when looking at the chapter, the first half spends time explaining burn-down charts and the second half is trying to convince the world that 30-day sprints are "the right length". I found this somewhat odd as most of the world seems to recommend against 30-day sprints. It even calculates the overhead for shorter Sprints, but that is than contradicted by the Scrum Guide in appendix A which clearly states that the meetings are proportional to the Sprint length.
Chapter 7 talks about "studio level" adoption, which seems to be a part of an organization. It starts with the suggestion to let everyone sign a contract that they'll use Scrum, which felt odd to me. Then it showed a survey for determining how people are aligned with Scrum assumptions, which was pretty good. Then it shows a "dashboard" of metrics for management to use which to me felt a bit simplistic (I know Ken is doing more work on this at the moment, and hope it will improve). It then calls velocity a measure of productivity (which can be quite dangerous) and suggests it to be measured in function points. I'm personally not aware of many Scrum projects that actually use function points, so I felt the mentioning of that was a bit odd. The end of the chapter related to technical dept was quite good again!
Chapter 8 about adopting Scrum to the enterprise was 3 pages. Chapter 9 are the steps of a change project. This mostly is a summary of Kotter's change management ideas. Chapter 10 explains the concept of using Scrum to adopt Scrum, which is a summary of Ken's Enterprise Scrum book.
Appendix 1 is terminology. Appendix 2 is the excellent Scrum Guide, which you can also find online. Appendix 3 is a play-book for adopting Scrum developed by Rally, which didn't seem to have changes much since 2005.
All in all, the book had its good moments followed up by moments that made my head shake. The tone of the book was quite selling, which annoyed me a bit at times. The explanations of Scrum felt mostly shallow and then deep on surprising moments (3 pages on why the Sprint length should be 30 days, about as much as about adoption of Scrum to the enterprise). In general, the book didn't feel like one whole and felt like it was put together in a hurry. I had thought about giving it 3 stars, but think that would be too much as I wouldn't recommend reading this book. If you want a better introduction to Scrum by the same author, pick up the somewhat dated Agile Project Management with Scrum (Microsoft Professional) or just download the Scrum Guide (or alternatives).
I had expected more from two respected and influential people in our industry.