The book encompasses 8 essays that can stand alone or can be read together as a book. They start out discussing projects in general and move to a more personal career perspective. The first thought I had on reading the first essay was this isn't a book about Agile software development. I found this unusual given how mainstream Agile software development has become and that IBM claims they are using Agile practices on enterprise projects. I don't mean this as criticism or a flaw with this book in any way. It's actually the main asset of this book from my perspective. The book has a lot of advice I have come across before, but it's presented in a slightly different way than one typically sees. There are sections titled, "When you can't plan accurately, plan often.", "Make two kinds of plan: Period and Product", and "Teams can perform better than individuals". Translated into Agile speak he is talking about adaptive planning, release planning vs iteration planning and focusing on team interactions over process. This is what I like about the book.
When I'm coaching experienced software people on Agile software development, I often find them saying, "Most of this is what I already do." They are right. Most Agile practices aren't new. They are good engineering practices that successful software teams have been doing for years. XP, lean, whatever you call them, can be defined as collections of best practices following common principles. Agile is usually an easy sell for developers. Unfortunately for managers who come from a large organization that manages via command and control (which is most corporations), Agile principles and practices feel significantly alien. They seem to give too much control to those who have little experience with it. Most resistance from managers sounds like, "if I didn't drive/manage these folks, they wouldn't be productive". Having been a manger in a few large organizations in my past, sadly, I can say this is actually true. It's not the individuals' fault. It's the managers. Command and control doesn't give the individuals the proper background as to why they are being asked to do things. Look at it this way: If I give you a stack of work and say, "this will help to bottom line.", you will do it. But, if I say, "I'm trusting you to figure this out as it will help us with the strategic initiative the CEO was talking about in the quarterly meeting. If you do this you will be helping our main strategic initiative this year and possibly get noticed/get a promotion/justify a raise, etc...", you are going to rock it. In large organizations the doers are rarely involved in decision making and thus have very little context as to what business related problems they are solving. Agile management turns that on it's head and only presents features to doers with the business value the solution will achieve. For those acclimated to command and control management: How do you get them to shift their mental paradigm to having the doers be part of the solution process?
The book presents good management and good engineering practices. It happens to be the case these are good Agile management principles too - without all of the Agile terminology. This book will present good practices in a non-threatening way so that an Agile manager and non-agile manager can find common ground. This book goes a long to to answering, "What is agile" without confusing and scaring people away with jargon and religious fervor over the "best" way to do things.
If you are a manager at a large organization, I can say this book will give you some helpful ideas what to try next. If you are in a large organization and want to learn a little bit about Agile principles and practices: This book will help - although I don't think its the intent of the book. If you are a developer trying to get your management to consider utilizing Agile practices: After utilizing the practices and principles in this book, when you present Agile management practices to your manager they might say, "I'm already doing that."
