This text book treats the subject of agile software management well. The examples and explanations are quite comprehensive.

My professor required this book for my software project planning course. Being from a science background, I've never been very interested in business-related subject matter. However, in this book, Anderson provides simple models and strategies that seem simple and easy to apply. I've even had a somewhat hostile view of management in the past. This book has made me re-evaluate my attitude. I can now see that management does have an important role in a healthy organization.

Abraham Lincoln once asked something like, "If you call a tail a leg, how many legs does a dog have?" The answer is four. "Just because you call a tail a leg doesn't make it so." Just because you want to call some development practice "Agile" doesn't make it so. In this book, David Anderson makes a case for calling Theory of Constraints the underlying definition of Agile software development practices. The principle tie is that a key measure in the Theory of Constraints is called Throughput; the amount of value delivered to the customer. Agile methods pride themselves as delivering value to the customer quickly. Based on the Theory of Constraints definition, the Feature Driven Development (FDD) method, Anderson's personal expertise, turns out to be the most Agile of all.
In making the case for the Theory of Constraints based approach, Anderson has given us a lot of formulas and metrics for looking at software projects. This is the most thorough treatment of the subject I have seen yet. I wasn't fully satisfied with the metrics as I felt the book didn't deal with the biggest problem in metrics, the problem of characterizing the measure. To do good metrics, you have to be very clear on what you are measuring, the characterization problem. Without that, all the formulas, graphs, and trends are pretty much useless. Most of the book dealt with the problem by saying, "If you could measure `X', then..." I got really tired of all the Ifs in the book.
In fact, I am not sure I should like this book or not. I found myself half of the time saying to myself, "Hmm, that is a interesting idea," and the other half saying, "I don't think so." Perhaps it was all the Ifs, perhaps it was the repetition. I am glad to say at the end of the book Anderson does appear to have the intelligence to note that one size does not fit all and does a nice job of suggesting where the best choices in software development approaches might be.
So, who should read this book? Well, if you like Donald Reinertsen's and Eliyahu Goldratt's work and live in the software world, this book is for you. If you have to teach Agile seminars to software professionals (like me), then this should be on your reading list as well. If you are general software project manager or developer who is looking to improve the way you do software development, then I would probably pass on this book. Not that the ideas are all wrong but you probably will get lost along the way. If...

The text gives a good explantion of agile practices and theory. It looks closely at three agile development methods : Scrum, Extreme Programming (XP), and Feature Driven Development (FDD), with an emphasis on FDD.

One of Anderson's key points is although agile software development is an empirical process (eg. dependent upon experimentation and observation), it is not necessarily chaotic. Therefore, it can be planned and predicted.

The text also emphasizes in order for agile software development to be adopted in a large corporation, software managers need to provide development metrics that focus on what matters to the CIO -- namely financial and production metrics.

The bulk of the text covers how to derive these production and financial metrics for the various agile software development methods. Anderson's proposed metrics are based on throughput accounting and Goldratt's Theory of Constraints. Specifically, he covers how to compute net profit, throughput, and production rates.

Thought provoking and highly recommended.

Ignore the 4 stars, that's just because I feel the subject can and will get a better book, however this book has paved the way.

I've been looking at and reading about agile methodologies for a long time, and there has always been something missing, and that is how they can be tied in with known business management science. The measurement problem, and in particular, the measurement of software development _value_ hinders any attempt software development staff might make to change processes based on their knowledge of development alone. This book offers a clear way forward in breaking down that problem. It doesn't solve the problem by any means, but we should all hope that it is the start of a deeper insight into the costs and values of development that will allow all of us to measure and justify methods (agile or not) in business terms.

Read it, and get your boss to read it if you can.