Who’s On Phirst

So, as I am sure any reader of this is aware, agile programming methodologies (like Extreme Programming (which for some reason is called XP, not EP)) are all the rage nowadays. Seems like everyone is doing it, from small scrappy ones (ahem) to giant behemoths. Personally, I’m a big fan. Sure, it’s no silver bullet, but it beats the crap out of the age old waterfall projects I worked on back in the day.

Here at Phurnace we try to be agile. We do mostly 4 week iterations, which typically include 1 week of planning and 3 weeks of “doing.” All told, it works pretty well. One thing that we do a bit differently than any other place I work at though is how we approach scheduling – which, shocking, is the subject of this entry. Using this scheduling methodology we have hit the date for 20 of our 23 iterations. Once we were a day early, and twice we were a day late. Personally, I think that’s pretty awesome.

Here’s how we approach scheduling. For those interested, this approach is based in larger part upon work done by Dr. Eliyahu M. Goldratt and his Theory of Constraints (TOC) and Critical Chain Methodology. That, in turn, is also largely based on operations theory and the Central Limit Theorem. We don’t slavishly follow Dr. Goldratt’s methodology, but we borrow heavily from it (so credit where it is due). If you are interested, read Dr. Goldratt’s book The Goal for an intro to the TOC and Critical Chain for more depth on the Critical Chain Method.

Now that you are suitably impressed by my ability to hyperlink, let’s get into some specifics:

Because we are good and agile, all our planning starts with a customer story. You know the drill – “The customer should be able to something when they something in order to accomplish something else.” Stories for the most part come from products land, but anyone can write one. Well, except sales. We tried that once. Let’s just say boundaries are there for a reason. We use Xplanner to organize our stories.

So, at the beginning of the iteration we sit down and figure out what stories we would like to work. We always choose too many stories, but the temptation to “add just one more” is too much to resist. We also prioritize the stories, and try to build one to three central “themes” of the iteration. But once we have the stories selected we present them to Dev. Dev has a week to estimate and plan how to get those stories done.

The thing about estimating development (coding, testing, etc.) work that’s hard is that for the most part you have never done the task to be scheduled before. I mean, sure, you have developed software before; but, you have never developed this software before. If you had, you wouldn’t need to schedule it, right? It would be done already. So, for the most part software estimates are swags – best guesses. Sure, you can do research to improve the swag, but basically it’s still going to have a lot of uncertainty. And it’s that uncertainty that creates one of the big problems with how software tasks are scheduled.

Let me take you through the process that I am used to in a software shop. It goes kind of like this:

Product Manager: “Hey guys! I am super pumped about this next release! This time we are going to add support for 3 new platforms, and also add 2 new UI elements, and fix those 3 critical bugs we shipped with on the last release. So – how long do you think that will all take?”

Developers (thinking): 10 weeks. (This means they think 7 weeks, and give themselves a 40% “fudge factor.”)

Product Manager: Ok. (This means he is planning for 15 weeks, since projects are never on time.)

What’s going on here? The interesting thing is everyone involved is calculating risk, but no one is actually quantifying it. The only thing they are quantifying is an “expected” date – but there’s no analysis as to the underlying risks.

The good news is there are lots of ways to assess risk in estimates. PERT is a good one – and we are going to use a part of PERT to calculate the risk of each task. But PERT has some limitations that we are going to try to jump over. Realize, what we are doing by calculating risk is actually building a probability distribution of the likely completion times of each task.

In Part Two of this series we will go through the exercise of calculating “risk” in software projects, and give a real world example from Phurnace to see how we do it. In Part Three we will take that example and build a schedule that takes into account both actual completion dates as well as the riskiness of the tasks.