Anderson's "Agile Management" Reviewed

Posted by Deborah Hartmann Preuss on May 23, 2006

Sections

Process & Practices,

Architecture & Design

Topics

Agile ,

Delivering Value ,

Methodologies

Tags

Management ,

FDD ,

XP ,

TOC ,

Value & Metrics

Many first encounter the Theory of Constraints in Eli Goldratt's "business novel" The Goal.  TOC is an approach widely taught for use in the manufacturing industry.  In Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, David Anderson combines TOC with Agile software development, with the objective of creating a process that "scales in scope and discipline to be acceptable in the boardrooms of the Fortune 1000".  Is this necessary?  Does manufacturing theory actually enhance Agile software development?  From these reviews, it looks like the jury is out.

The book covers:

• 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
• Defining the four new roles for the agile manager in software projects-- and competitive IT organizations

Anderson compares traditional "waterfall", FDD, XP and RAD approaches, and proposes a rigorous metrics approach.  The book indicates that "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".  Agile proponents agree that projects must measure value delivered, insisting that value must be measured in terms of the organization's bottom line.

One reviewer feels that TOC theory, as presented in this book, is not helpful for Agile projects. The other reviewer, identifying herself as a "traditional" project manager, finds the book interesting and useful, conjecturing that it will help concretely prove the value of Agile methods.

Perhaps the book's usefulness is dependent on one's starting point - no two Agile projects are the same, and different "tools" apply in each situation.  In fact, for some projects the major challenges lie inside the development team. But when the most significant challenges to delivering value lie in the area of management, this book does address a couple of important aspects of Agile management not covered elsewhere, and could be a useful addition to an Agile Manager's toolkit, when balanced with the other Agile practices.

Read the reviews and judge for yourself.

Anderson is not the only one writing on TOC for Agile Project Management. Clarke Ching frequently blogs on the subject, and the most recent Carnival of the Agilists notes that Frank Patrick had compiled a list of his past posts on the TOC and "Critical Chain Project Management", including a comparison of Scrum and CCPM in "Agile/CCPM - Non-Meaningful Distinctions".

1. Back to top

   I think Agile can learn from TOC

   by Johnny Blaze

   I've worked on projects, not necessarily software development, where the Agile concept has been used. That is to say that team members were kept close together, verbal communication was emphasized, and all the stages of the project were as short as possible to be able to react as quickly as possible to "real world changes".
   
   Where I feel Agile can lean from TOC, and this is SOP in most Fortune 500 companies, is that there is a sit down before the project begins where the project is conceptualized, visualized, and the overal goal of the project is agreed upon. Only brief notes are taken my members as we're not looking to write a report off of this. We're just making sure that everyone is on the same page and agrees what the goals and metrics of the project will be. At the same time it allows us to pre-emptively identify bottlenecks and areas where if a delay is encountered will cause problems downstream. By identifying these problems early on we can come up with a few ideas of how to keep working and shist around resources to ensure that the project keeps going. This is useful in all areas of business, not just manufacturing. Delays are not only caused by lack of a physical product but delays in getting information, failure to ratify a standard, someone being out of town and not giving approval for something, possible euqipement failure or backlogs if some large scale modelling is done on computers, etc. While it is important to not over plan, you have to be ready for a number of likely scenarios that will impact your time table.
   
   In the end, both theories can learn from each other. The combination of Agile's close knit teams that are highly focused on project components at hand and TOC's flowcharts and group buy-ins on goals and metrics make an extremely effective combination in my experience.

   Reply

• Older >