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:
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".
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".
Community comments
I think Agile can learn from TOC
by Johnny Blaze,
I think Agile can learn from TOC
by Johnny Blaze,
Your message is awaiting moderation. Thank you for participating in the discussion.
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.