Reading this, I realized there were several small things that were missing from my day to day practices.
Still there are several parts in this book that I have difficulty agreeing with. To me a process has no meaning if it is not intelligent and flexible. To adapt agile or not what is more important is to keep thinking on your toes, you cannot close your eyes and blindly commit to x document or y approach. Agile or otherwise, it is important to always think, question things and find answers, all the time, at every step of the project.(I am getting repetitive here...sry...)
There are several things that hit home! especially when the author talks about cross functional collaboration!
My favorite chapter was #4: Delivering what users want (although again, I disagree with #18: fixed prices are broken promises - if you think it well, fixed price projects can be delivered well with Agile, it just needs more intelligence).
However my favorite lessons were #35: Attack problems in isolation and #39: Architects must write code.
What #39 says is extremely important! I have seen so many companies default here! Forget architects, we sometimes encounter team leads (and up) who have stopped writing code as a daily exercise! The chapter reasons well against this practice.
Overall this was a nice read. So many software engineering/management book sell fluff and read like they are written for retards. It's nice to see a book that gets it right "most of the time". Do read, even if to disagree. :)
S.