Good Books
A few months ago I read The Goal, by Eliyahu M. Goldratt, mainly because it has become extremely popular at business schools, and it looked fun. It was interesting, and fun. I didn’t understand how the book’s theory, called the Theory of Constraints, could possibly be applied to software development, but it was still interesting enough, and I figured if I ever found myself running a factory again, it would be helpful.
Last week I discovered his newer book, Critical Chain. This book applies the Theory of Constraints, introduced in The Goal, to project management, and it seems to really make sense.
Lets say you’re creating Painless Software Schedules. Most people’s intuition is to come up with conservative, padded estimates for each task, but they still find that their schedules always slip. Goldratt shows that the slip is precisely because we pad the estimates for each step, which leads to three problems:
- “Student Syndrome” – no matter how long you give students to work on something, they will start the night before. Phil Greenspun noticed this: “The first term that we taught 6.916, we gave the students one week to do Problem Set 1. It was pretty tough and some of them worked all night the last two nights. Having watched them still at their terminals when we left the lab at 4:00 am, we wanted to be kinder and gentler the next semester. So we gave them two weeks to do the same homework assignment. The first week went by. The students were working on other classes, playing sports on the lawn, going out with friends. They didn’t start working on the problem set until a few days before it was due and ended up in the lab all night just as before.”
- Multitasking, which, as I discuss, makes the lead time for each step dramatically longer, and
- the fact that delays accumulate, while advances do not (for example, if you have finished this week’s work on Friday morning, chances are you will waste time on Friday afternoon rather than starting the next week’s work. But if you don’t make it on time, you’ll still leave at 5 o’clock on Friday, accumulating a delay.)
Goldratt’s solution is to choose task estimates that are not padded: each individual task’s estimate should be exactly in the middle of the probability curve, so there is a 50% chance you will finish early and a 50% chance you will be late. You should move all the padding to the end of the project (or milestone) where it won’t do any harm.
I can’t do justice to an entire book in this short post, but if you’re doing any kind of project scheduling or management, I highly recommend that you read both books (read The Goal first no matter what you do, both because it’s more entertaining, and because it teaches you the foundation you need for Critical Chain).
