Looking Backwards

Recently, my director published a new "capacity sheet". It's an Excel sheet with a high-level summary of all the projects scheduled for the upcoming year, with breakdowns in hours. The hours themselves are based on some simple formulae. A salesperson assigns the project a t-shirt size (S, M, L, or XL) and this translates to a predefined number of hours.

The intention of the sheet is not to plan capacity of our systems (i.e. transactions per second, etc), but rather see if we have sufficient resources to do the work. Let me start off by saying, I like the idea...in principle. In fact, at my old company it seemed no thought was given to actually staffing for the work coming in, which meant all of us ended up working ridiculous hours. So, the idea is a good one.

The problem is the implementation. It’s fine to assign t-shirt sizes to projects that are 9-10 months out and haven't even been defined (you can't really do anything else), but we use these boiler-plate numbers even for the projects that are nearly started. Further, as you move further out in time, the exercise becomes more and more meaningless because invariably the client changes his wishes and prioritization of work. Now, I made these points last time my group went through the exercise and that's not really the point of this blog.

The point of this blog is that no one is that I've not heard one person mention the need to look at the exercise we went through last year. Having gone through the exercise before and having voiced a number of concerns about the value of the exercise, I decided to go back and look at the sheet from last year. What I found there was very telling and hopefully will persuade others to reevaluate the way in which we're handling things this year.

Almost 70% of the projects on our plan never even happened. And for those that we did do, the boiler plate estimates we used were not even close to the actuals. Now, this didn't specifically cause us problems insofar as we delivered on our commitments. That is primarily because in general the formulae grossly overestimate the amount of resources needed for any given project. Of course, I'm not sure the actuals in our time-tracking system will prove this, because as we know from Parkinson's Law, work expands to fill time.

The problem is going through the exercise this time around using these numbers uncritically, tells us that we're short staffed. Nothing could be further from the truth. I have many more developers than I need and many of them end up billing huge amounts of time to "sustainment" activities or training. Since these guys are offshore, I really couldn't say definitely what the hell they're doing half the time. I'd say we're probably 25-40% overstaffed.

But again, that's somewhat incidental to my point (I do have one!) for the blog and that is when doing something. George Santayana made the famous statement that ‘Those who do not remember the past are doomed to repeat it’. In general, I prefer Kurt Vonnegut’s rebuttal ‘I’ve got news for Mr. Santayana, we’re doomed to repeat the past no matter what. That’s what it is to be human’.

In the case of software engineering (and most sciences), you absolutely *have* to go back and look at what went right and what went wrong to improve. That’s what of the things I think Scrum and Agile absolutely nailed, the idea of iteration/sprint retrospectives. Unfortunately, things like that seem to be the exception rather than the rule. More often than not people don’t do this, so we continue to tread a sea of mediocrity in which nothing ever really improves.