In 1997 Eliyahu Goldratt published a business novel titled Critical Chain in which he introduced a new way of scheduling and executing projects similar to the more familiar Critical Path method. Goldratt's version removes many of the estimating games that go on between managers and their staff. This results in projects that typically deliver in about 75 percent of the normal time. In this week's column, Clarke Ching demonstrates some of the ideas from Critical Chain and will show how to use it easily within agile projects.
In practice the Critical Chain technique has been used in multi-billion-dollar and multi-year projects, but I'll demonstrate the ideas using an extremely simplified example of a small project with just one developer and one project manager. The project manager and the developer have broken down the featureset into six tasks-A, B, C, D, E, and F-which can be performed sequentially.
With the tasks identified, the project manager knows how long the project should take, so she asks the developer to estimate how long it will take to complete each task. The developer looks at task A and says, "I could probably do that in one to three days, but that's only a guess. With all the interruptions that go on around here it could easily take me four to seven days. Heck, it could even take as much as eight days, maybe even more." He thinks for a bit and says, "Eight days." The developer knows that although the project manager has asked for an "estimate," which is a range, she really wants a commitment in the form of a single date. After all, her project management software only takes a single date.
Let's say, for the sake of this simple example, that the developer estimates that the tasks can be completed in about 8 days. The plan will then look like this:
AAAAAAAABBBBBBBBCCCCCCCCDDDDDDDDEEEEEEEEFFFFFFFF
The total duration is 6 x 8 = 48 days.
It's quite likely that the some project manager will automatically chop a bit of time off the high estimates but also keep some estimates as they are-as an informal contingency. These project managers won't tell their bosses; otherwise, they'd be accused of "padding." Let's just assume this doesn't happen.
Let's see how our project manager would prepare the equivalent Critical Chain plan. Having been given eight days as the "estimate," she asks the developer if eight days is a commitment-level estimate (i.e., a date to which, most of the time, the developer could commit). If not, she would ask the developer to re-estimate. Then she would tell the developer--and this is extremely important--that she only needs this estimate for her planning and that she doesn't care if the developer takes longer than eight days or less. She even promises that if she ever penalizes the developer (even if it's just with a dirty look) for taking more or less than eight days that she'll buy the entire team lunch for a week. (Maybe she even records a video of herself making that promise.) But then she does something that will scare the developer the very first time he sees it happen: She chops all of the commitment-level estimates in half, and she takes the bits she's chopped off, puts them on the end of the project plan, and calls this time a buffer.
So the project plan now looks like this:
AAAABBBBCCCCDDDDEEEEFFFFxxxxxxxxxxxxxxxxxxxxxxxx (where x is buffer time).
The duration is still 48 days.
The developer will probably say something like, "You're kidding me, right? I've only got half the time I promised. That sucks."
The project manager reminds the developer of the promise she made--about buying lunch if she ever penalizes anyone for taking more or less time than the eight days, or even the four days. She then says, "Besides, I'm going to make it easier for you to finish each of these tasks quickly by protecting you from all the interruptions you get. In fact, I'm going to fight to make sure that you only ever work on one task at a time."
Hopefully, the developer will think that with many of the interruptions
About the author
An independent consultant and regular columnist on StickyMinds.com, Clarke Ching is a passionate advocate of agile software development and a chairman of the AgileScotland special interest group. He is the author of the book Rolling Rocks Downhill, in which he demonstrates how to use lean, quality, and agile techniques to make your projects more productive and predictable. Read more about Clarke's work at www.clarkeching.com.
