If your team uses a methodology like scrum or lean, or if you're considering moving to an agile methodology, you should buy this book. If you're feeling generous then buy a copy for every member of your team--the price is low enough to warrant it.
It's an easy read and could be read cover-to-cover in one sitting. As I see it, the author's intention is for you to become "enlightened" with an understanding that being agile is not about management process but about programming practices such as test-first development, pair programming and refactoring.
The book sets out with a history of agile ideas and then picks apart the various facets of those ideas, discussing why each makes sense. For example, the author offers an excellent theory of "scope" and how it is traditionally thought of versus how an agile practitioner might think of it. This advice in particular was an "aha!" moment for me; it succinctly described a team issue I'd previously encountered but could never manage to resolve.
At the end of the book is a dissection of various methodologies and techniques such as user stories, scrum, kanban and XP. The scathing review of scrum will resonate with anyone ever involved on a team that's been "agilized" by a consultant drafted in to improve the team's under-performance. The point is that scrum can be imposed but the team is still left decidedly un-agile.
The author helpfully mentions numerous websites and books that you can explore as you progress on your journey towards enlightenment; that's important because this book tells you the why, but not the how. It won't give you strategies for pair programming, for example. But it will start you in the right direction--or correct your direction if you've started off on the wrong path.