possible implementation pitfall? The catch of course, is in the word only.
One other thing Scrum literature will often tell you is that Scrum is a simple process with complex behaviour , meaning that the process itself is indeed simple. There are just a few roles and there are simple process steps and practices to follow.
We have seen numerous problems occurring when people started doing things exactly as specified in the books. The book says: "estimation should be in gummy bears", "we can have only one product owner", "burn downs should be in hours", "everything should be on the product backlog and prioritized according to business value", etc. We see a lot of dogma. People act according to the book, see that things do not work in their specific situation but do not adapt their behavior because the book tells them to do it in that specific manner.
Please note that in the end it is all about achieving the right results. The behaviour we would like to see from team members, product owners, ScrumMasters and all stakeholders should lead up to that result and is much more complicated than you'd first expect when studying the process. This complex behaviour is excellently captured by a series of pattern languages by James O. Coplien and Neil B. Harrison in their book "Organizational Patterns of Agile Software Development". A fair number of patterns they've described in this book can directly be "mapped" onto Scrum. The point is; you can read the book and follow the mechanics of the process, but that will not really get you where you would like to be.
We experienced that you should do what best suits your particular situation even if this means not following all the details of the books. If you literally follow the book you could, for example have potential shippable product at the end of every sprint. If you are exploring solutions you know you are not going to ship your product at the end of a sprint. If you know you are building a rough version, validating it and slowly build up quality, there is no need to have a potential shippable product meeting all company standards at the end of each sprint. So, if you know all this, then don't build it like the book says!
Another thing you could infer from "the book" is that sprints should start before specifications are complete. What if agreeing and clarifying on specifications takes a couple of weeks thanks to the multitude of stakeholders and system complexity? And what if finishing them during the sprint will not give you enough time to prepare the specifications for the next sprint? Well.... complete them as much as possible before the sprint starts or maybe build up a small buffer of specifications.
You will need books to help teach the mechanics of the process and to strengthen you're overall knowledge about Lean amp; Agile in general and Scrum more particular. This is especially the way to go when you are in the process of learning and adopting Scrum. But also realise that at some point following the books are not going to help you take the really important steps. You'll have to understand the underlying principles and get to the upper stages of the Dreyfus model of skill acquisition; the true meaning of Do, Check, Inspect and Adapt does not fit into a book. So start out using the books to get yourself going and once you are competent forget about the books and adapt according to the principles of Agile and Lean.