Customer Reviews

Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results

5 star:		(6)
4 star:		(5)
3 star:		(2)
2 star:		(1)
1 star:		(0)

 

 

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...

Agile methods are all the rage these days, and with good reason: they work. Unfortunately, current practice is largely a hodgepodge of rules of thumb rather than a consistent theory derivable from basic, verifiable assumptions.

That's where David Anderson's book comes into play. David explores the foundations from which most of the Agile concepts can be derived. While most of the concepts are borrowed from manufacturing, David does an excellent job of explaining how they relate to software. The book is very well written, the graphics are excellent, and the concepts are ones that anyone involved with software will need to master if they want to stay competitive.

Excellent work, david.

The accounting-based framework for assessing the value contributions of a team seem like an effective way of measuring Agile products and whether or not they're good for the company.

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.

Anderson takes agile development, which is a loose-leaf collection of unintegrated practices, and transforms it into a serious discipline with a firm foundation. He accomplishes this by borrowing concepts from manufacturing (like theory of constraints) and applying them to software development. Such a book could only be written by someone thoroughly familiar with both software development and manufacturing; fortunately the author seems quite knowledgeable about both.

In all, this book is serious, contentful, and even profound at times. It is by far the best book I've read on the topic in quite a long while.

This is the hardest - and possibly best - Agile software book I have read so far. It's hard because it digs deeper into the cause and effect at play within agile environments and because it deals with the "bigger" financial aspects of lean. It's a well written, comprensive text.

This book is essential reading for IT managers, but senior developers should read it too. While some things in this book will make engineers say "I know that, but just didn't know how to say it", other things are real eye openers. Engineers will find some of the management theory to be dry reading, but it is relevant.

If you ask engineers who have used both traditional (i.e. waterfall) methods and agile methods they will tell you that agile methods are superior, but if you ask them why and how agile methods deliver better results almost none of them will be able to tell you. They know it from experience and intuition, but they do not understand the why and how.

Of course, since engineers don't know how and why agile methods work they are at a disadvantage when it comes to convincing management to try them. That's where David Anderson's book comes in. It explains how and why agile methods work in terms that engineers can identify with and that managers understand: increased profit, meaningful accounting, and the ability to repeat successes.

Being able to convince your manager to try agile methods is only one benefit. As a team lead or architect if you don't understand what makes agile methods work you may very well end up doing things that defeat their advantages.

This book explains why certain things help software development and why others impede it. Why and how should software development teams should identify and exploit constraints? What is Throughput Accounting and why should it be used for software development instead of Cost Acounting? How is software development different from other kinds of engineering and manufacturing businesses? How can the self organizing behavior intrinsic to successful software development efforts be improved?

Anderson's book is invaluable to the manager and valuable to the software engineer.

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.

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.

Agile Management for Software Engineering is targeted for managers and executives working in the software industry. Its focus is on introducing a technique called Throughput Accounting for measuring and tracking software projects. The author basically shows how traditional cost accounting based methods lead to suboptimal business results and how to correct that situation by applying principles of Lean Production and the Theory of Constraints.

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.