Anderson's "Agile Management" Reviewed
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
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".
I think Agile can learn from TOC
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.