The author covers different aspects of management in the software industry one by one--including project management, project planning, production metrics, staffing, resource planning, and product management--explaining how the concepts of Throughput Accounting fit into the picture.
The latter half of the book is dedicated to showing how the theory presented can be applied to a number of agile software processes, namely Feature Driven Development, Extreme Programming, and Scrum.
The first part of the book is a bit difficult to follow due to slightly repetitive text and never-ending acronyms. I wouldn't count this as a defect, however, as the subject of introducing financial measures inevitably requires a certain amount of equations in between beautiful words. Luckily, the latter part, where these measures are applied, flows much better. What I see missing in this book is more concrete examples beyond the arguably theoretical discussion about real-world application. I also noticed that I was constantly waiting for the author to connect the dots and bind the theories presented in a more or less waterfall context into modern, iterative and incremental processes.
All in all, I find Agile Management for Software Engineering to be a book with a solid message: how to better manage a software business. Considering the state of practice in the industry, I'd say this is a must buy for any manager or executive.
As an agile advocate, this additional perspective is what I have been looking for. The explanations of the Theory of Constraints has proven valuable to me in my interactions with customers already.
Unfortunately, the book was full of distracting grammar and even *spelling* errors. It also had a serious tendency to use a lot of acronyms / variables for concepts, but didn't bother to even quickly re-expand the name when they hadn't been used for a couple of chapters and jumped back up again. Plodding from chapter to chapter, it builds up formulae with just enough description to bury you in the details of the relationships between the variables, without actually conveying examples of what the variables represent in real life projects.
For being as formula-oriented as this book was, I would've expected to see a detailed example of a project, assessment of it as it went along, and the calculations of the value being delivered by the project. There were a few hypothetical examples, but nothing that actually sounded like a real evaluation of a project as it progressed.
Finally, they might as well have cut out SCRUM and XP. I would've been much happier if this book had just been an application of TOC (Theory of Constraints) to FDD (Feature-Driven Development) and if it had concentrated more on real examples of the two in practice, rather than trying to extract some theory and try to convey how one might apply it to other methodologies.
I just couldn't say that, having read all of it, I could correctly measure what they state, compute the numbers the the way they suggest, and then have any confidence in any decisions I made based on those numbers.