Amazingly, one can be considered an expert and still write a book based on the it-worked-for-my-friend's-company type of argument.
Supposedly, there's the following framework: if the company has some issues, we should just switch to Scrum and then follow it strictly. If there's something messing with our switch, we should call it “impediment”, fix it, and be happily sure that these impediments were the main issues in our company. The question of why this is the case is never discussed.
Well, maybe this book isn't supposed to convert me. So it quickly goes to the description of how one should transit to Scrum (create Scrum team that will guide other teams to Scrum; also, it should fix the impediments) and some discussion of possible problems. Then, there are solutions.
Scrum master (spelled as “ScrumMaster”) isn't good enough? Replace him. Product Owner can't cope with the backlog? Replace him. Team still works slowly? Replace everyone.
Legacy code is discussed for several pages in the most obvious possible way. Proposed solution? Fix it or deal with it.
Finally, there's redundancy, more redundancy and some redundancy again. Also, redundancy.
