Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results
A breakthrough approach to managing Agile software development . . . Agile methods might just be the alternative to outsourcing. However, Agile development must scale in scope and discipline to be acceptable in the boardrooms of the Fortune 1000. In "Agile Management for Software Engineering," David J. Anderson shows managers how to apply management science to gain the full business benefits of agility through application of the focused approach taught by Eli Goldratt in his Theory of Constraints. Whether you're using XP, Scrum, FDD, or another Agile approach, you'll learn how to develop management discipline for all phases of the engineering process, implement realistic financial and production metrics, and focus on building software that delivers maximum customer value and outstanding business results. Coverage includes:
- Making the business case for Agile methods: practical tools and disciplines
- How to choose an agile method for your next project
- Breakthrough application of Critical Chain Project Management and constraint-driven control of the flow of value
- Defines the four new roles for the agile manager in software projects--and competitive IT organizations
Whether you're a development manager, project manager, team leader, or senior IT executive, this book will help you achieve all four of your most urgent challenges: lower cost, faster delivery, improved quality, and focused alignment with the business.
Review By: Jan A. Scott
05/22/2006The subject matter in this book is much broader than its subtitle. The book is divided into three sections. The first deals with metrics and project management techniques for agile projects. The second discusses software development using the traditional waterfall method, the Feature Driven Development method, the Extreme Programming (XP) method, the Scrum method, and Rapid Application Development (RAD). The third section compares the four development methods.
The author introduces what he calls “throughput accounting,” which seeks to put a business-like value on software using the analogy of manufacturing. Ideas and software requirements are considered inventory, while the amount of money spent to create the requirements is considered investment. Throughput is defined as the sales price of the software (or the budget for an in-house project) minus the direct costs of distributing the software. Net profit is equal to throughput minus operating expense. Return on investment equals net profit divided by investment. Unlike cost accounting, which focuses on reducing costs, this method focuses on delivering value to the customer--a basic agile development goal. The author shows how these metrics can be applied to each of the development methods treated in the book.
The book touches on many principles familiar to project managers and quality engineering professionals. Waste is defined as requirements that are not used because they were poorly analyzed or changed. Poorly written code is also considered waste. Metrics based on throughput accounting are introduced to track and control these elements. According to the author, the traditional project management method, in which scope is fixed early, is wrong because it forces us to be extremely accurate in our estimates of work. He maintains that scope (which has the least certainty) should be flexible and date (which has the most certainty) should be fixed. This is one of the principles upon which agile development methods are based--pick short iterations and deliver valuable, working code within that iteration.
The author is clearly an advocate of agile programming methods, but he encourages the agile programming community to prove its worth in business terms by using metrics that can be compared across development methods. Agile developers often say that metrics are unnecessary because working code is all that is needed. The author’s response is that a CIO needs language that will “appeal to his wallet . . . profitability and return on investment.”
Although some of the metrics seem a bit contrived--even to a traditional project manager such as myself--I think the book’s basic premise is correct; we need to prove the value of agile methods.
In the last section of the book, four different methods are compared. The author is clearly most familiar with Feature Driven Development. He spends four chapters discussing it and only one chapter discussing RAD. These chapters are a good overview of each method, and enables readers to see how they differ.
The author concludes that Rigorous Software Methodologies (RSM)--those large-scale, traditional methodologies--are best when done well for big projects in mature industries where the requirements are well-known. Agile methods work best on smaller projects with less certain requirements. He points out that it is harder to do RSM well than XP or Scrum, so we must not compare a poorly executed traditional project with a well executed XP project. This, in itself, is an argument for agile methods.
Although you may not agree with the book’s conclusions--and I believe a good portion of the agile community may not--it is interesting and thought-provoking reading. If you’ve ever struggled to explain the value of Scrum or XP to your CIO, try the metrics explained in this book.
Review By: Robin F. Goldsmith, JD
05/22/2006In "Agile Management for Software Engineering," David J. Anderson attempts to bring together two schools of thought with advocates that tend toward religious zeal: agile development and the Theory of Constraints (TOC). Anderson’s analyses of agile methods, especially Extreme Programming (XP), have flashes of insight such as recognizing XP’s general lack of objective measures to support its claims. However, such types of objective analytical insights are decidedly lacking with regard to TOC and Feature Driven Development, Anderson’s favored agile method.
Agile and TOC both tend to characterize alternative approaches monolithically, assuming that everyone else always does things identically in the most ineffective manner possible. For example, agile depicts other methods as producing useless documentation at the expense of executable code, and TOC says other methods concentrate on costs rather than delivered value throughput. Equating executable code with throughput merges TOC and agile.
Except for embracing the widely accepted advantages of breaking work into small iterations, the bulk of the book repeatedly conveys premises based upon a seemingly gross misunderstanding of software development. He describes investment as the cost of defining requirements inventory and throughput value as the (presumably constant, irrespective of work to be done) operating expense of programming, testing, and implementing said inventory. TOC denigrates task estimating, yet relies on buffers needing far more accurate estimates than software development customarily makes. The author implies that project managers don’t understand that they need the most skilled, motivated, and undistracted workers.
Anderson’s writing is easy to read, but he tends to repeat concepts. Applying terms like “subordinating,” “protecting,” and “exploiting” constraints seems mainly like self-aggrandizement of the otherwise simple and well-known project manager’s triangle concepts.
Systems projects routinely encounter difficulties because they don’t adequately understand business requirements and the appropriate architecture and engineering work needed to satisfy those requirements. Coupled with mandatory, tight deadlines and arbitrary but always sparse budgets, projects inevitably are late, over budget, and wrong. Too much of Anderson’s simplistic treatment says that not doing certain things will make everything work out well, but he offers no way to turn the tide besides repeating agile and TOC mantras. His specious throughput return on investment definitions undermine his whole thesis.
To its credit, the agile movement has had successes in getting some organizations to play by its rules. It defines value as producing executable code within a timebox. Anderson is correct that focusing on very small components can create significant architectural issues. And refactoring to get code the way it should have been is just a cover for costly rework that does not add value.
Those who already have adopted agile may find the TOC rationale as further affirmation of existing beliefs. I would caution against trying to introduce TOC and agile based upon the book’s presentation.