 |
Home > Detail: Critical Chain Scheduling for Software Projects
| A StickyMinds.com Original |
|  | |
Critical Chain Scheduling for Software Projects
By Clarke Ching
   
Summary: 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 gone, four days isn't an aggressive deadline after all. He asks what the buffer is for. The project manager says that since some tasks are going to take longer than the four days she has in her plan, she will use the buffer time to absorb the extra time. If they finish sooner than expected, then she'll add the time gained back into the buffer. So, if task A takes six days, task B takes five days, and task C takes four days, then the buffer will have three days eaten out of it.
Note that there are some rules during execution that are vitally important:
- The developer is asked always to single task, except during emergencies--that is, he's asked to work on A, then B, then C, and not to switch between them. Multitasking dilutes the effort applied to each task. Try to complete three tasks by multitasking, each of which should take about four days to complete, and you'll notice how each task suddenly takes twelve days or more.
- The project manager protects the developer from being asked to multitask.
- The project manager and developer check in daily--just like they do in a normal agile daily meeting.
I add the following fourth question to Scrum's normal three: How many days do you have left on the first task you are currently working on? This is different from the question, What percentage of the task have you completed? This new question reinforces the single-tasking rule, plus it gives you real-time information. Don't be surprised if the estimate goes up and down, though, as the developer learns more about the task. High estimates often reflect uncertainty, which disappears as you learn by doing a task. On the second day of working on the task, the estimate may well drop down from eight days to three, but the estimate may equally go up as well. That's why you have the buffer there--to protect you. Estimates are guesses after all.
The project manager must always keep her promise that she won't penalize the developer when estimates go up or down, or take more or less time than originally estimated. Estimates are guesses, not commitments.
Finally, given all these behavior changes, you'll find that the buffer is too long. You can chop it in half as well, and you'll still have a reliable project plan. There's loads of good statistical reasoning why you can do it, but take a look at the plan above where the buffer was half of the total duration and ask yourself if you really need it. If you think you do, then keep it, but plan to finish early.
So here's our new plan, with the buffer taking only one-third of the duration:
AAAABBBBCCCCDDDDEEEEFFFFxxxxxxxxxxxx (where x is buffer time).
The duration is now 36 days.
Given the behavior changes--especially the enforced single tasking--you've now got a project that is far more likely to finish on time even though it's only 75 percent of the original duration. You can now do twelve months’ worth of projects in nine months. That's a whopping 33 percent increase in capacity--for free. The biggest but least obvious benefit is that using this approach builds trust between managers and staff by removing all the unhealthy game playing that goes on with estimates.
You can scale this process to fit huge projects or for an iterative process. Let's say you are running a Scrum project where you promise to deliver a few features off the top of your backlog in, say, three weeks. Your resulting plan will have two weeks' worth of aggressive (and halved) tasks and a single week of buffer. So you add just enough features to fit in that time box. You'll find that each iteration will finish sometime during the third week. This approach means you can make more reliable promises, and, believe it or not, you can deliver more work in the same period of time.
Further Reading:
About the Author
Clarke Ching is a New Zealander living in Scotland. In addition to being an independent consultant and a regular columnist on StickyMinds.com, he's a passionate advocate of agile software development and a chairman of the AgileScotland special interest group, which meets monthly in Edinburgh. Clarke currently is writing a book titled Rolling Rocks Downhill, in which he explains why working with software projects often feels like pushing rocks uphill. He also demonstrates how to use lean, quality, and agile techniques to make your projects more productive and predictable. Read more about his book and other articles and listen to his podcasts at www.clarkeching.com.
Back to Top
StickyMinds.com Weekly Column From 8/11/2008
|
