I've been doing some research for a project at work on Critical Chain (a result of my articles <here and here> for Projects at Work being noticed within the company). I started by re-reading Goldratt's book Critical Chain. If you haven't read it, I recommend it. It's written as a novel and is an easy read, but still has some good content.
What I've been pondering is how to use Critical Chain in Program Management. I've come across some agilist talking about Critical Chain and Theory of Constraints (TOC-Goldratt's work in manufacturing). Dave Prior recently wrote an article for Projects at Work on transforming to agile where Drum-Buffer-Rope (part of TOC) was mentioned. There was also Mike Cottmeyer's mention of Theory of Constraints I mentioned in a previous post.
So is Critical Chain the answer to scaling agility? When Mike talked about scaling agility at the PMI North America Global Congress last year, he argued that Scrum isn't the answer to scaling agility. Some other tool that can address constraints needs to be used. I think many of us have experienced resources being the big constraint in a program. Critical Chain provides an answer to this.
When using Critical Chain, your first step is to identify the constraint. Let's say it's the number of U/I designers you have. You can't run four projects in parallel because your two designers will be constantly pulled back and forth, and we all know multi-tasking is bad! Critical Chain would say that you need to delay some of your projects to address this constraint, even if this means other resources are idle.
It sounds simple, but will it work? How else can you address constraints across a program? Do we also need to be concerned with buffers? Goldratt spends a lot of time talking about buffers on the project level, including resource buffers. But how does this scale to the program level? Do we need program schedules with resource buffers? I'm going to keep digging in. If you have any suggestions, let me know.