Critical Chain, Agile, and Program Management

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.

Less WIP for better flying

I spent the end of the this week at ProjectFlow2011, a conference put on by Realization. Realization focuses on software and professional services using a Critical Chain approach.

The conference speakers were primarily Realization customers sharing success stories. One story that I found interesting was from Delta Airlines, primarily because I fly on Delta so much. The challenge Delta had after the merger with Northwest was how many different types of airplanes they had to support. There was almost no overlap between the planes Delta flew and the ones Northwest flew. Over the course of a year, Delta was able to reduce their cancellations by 62%.

One primary change had to do with reducing multi-tasking. Before the change, they would look at all upcoming scheduled maintenance on all airplanes every night and would perform any work that was on the schedule for the next 2 1/2 days. This meant each plane had some other maintenance due 2 1/2 days later. The change they made was working on fewer aircraft each night, but looking forward 15 days on each plane they worked on. By focusing on fewer planes at a time (less work in progress), they were able to keep all the planes running better.

There were a number of other companies that shared the similar stories and reduction of work in progress was one of the key tools used to improve project execution. I'll save some of the other techniques, such as buffers, for future blog posts.