Almost every organization that does software work has stated that they struggle with resource capacity planning. In conferences, seminars, etc. that I attend and companies that I visit, those questions almost always boil down to this question:
- Do I have enough people to complete the projects that I need?
Or the variant…
- How many people are necessary to complete the projects that I need?
The above questions have a few visible assumptions built in. The first assumption is that somebody has defined a finite list of projects that they are worried about. The second assumption is that some sizing has taken place to estimate the sizes of the list of projects. The third assumption is that there is some assumed planning timeframe in which the question is applicable. The hidden item is an assumption that the level of people needed is variable, i.e. we will simply hire contractors or release them as demand exceeds capacity or vice-versa. That is a very expensive approach both in terms of hiring to scale up, or to release contractors along with the acquired intellectual property. Some organizations do this with full-time people; even more expensive and personally devastating.
The essence of the questions above is that of matching project demand and people capacity. As much as the infamous project iron triangle has been mocked and abused, it still provides some insight into the question of resource capacity and how it is changing as we transition from traditional project planning to agile project planning. When I hear the question above, I know that the mental shift to agile thinking has not yet happened.
Planning for a single project is just a microcosm, or fractal, of planning at the enterprise level. In a traditional project world, the project manager attempts to figure out the size of a team to meet a fixed schedule and fixed scope. In some cases, they have a fixed budget and a fixed scope, and try to develop a target completion date. The parallel is that the organization is trying to figure out how many people to address a fixed schedule (a planning year?) with a fixed scope (a list of projects), thus the questions above. Unfortunately, because we believed that we could forecast out an entire year, project managers would be handed a fixed scope, a fixed deadline and a fixed budget. The deadline may have been stated as fixed, but reality always set in. If the deadline was truly fixed, then perhaps the budget could be exceeded. It was more or less random as to which aspect of the triangle was going to break, and most often it was a last minute decision in crisis mode. Sometimes, the only lever the project team had was to reduce quality.
In the agile world, the iron triangle is turned upside down. The costs/people are fixed by having agile teams of 7 +/- 2, the deadline is fixed via sprints and a release date, and scope is allowed to float by judicious management of a prioritized backlog. The product owner controls that scope lever by managing the backlog to the velocity of the team. So let’s take the agile model and apply it at the enterprise level.
First, here’s the reality. Unless you really see people as cogs in the machine or just servers to be bought and sold, the reality is that you are going to have about the same number of people next year as you did this year, with maybe some planned growth or decline. Because most organizations have far more projects than they could ever accomplish, you can consider the backlog as infinite. Logistically, you simply are not going to double or halve your IT staff. (Obviously, there are those extraordinary circumstances of major growth or pending bankruptcy). So we have a fixed cost (people) and a fixed deadline (next year), so the only aspect of the iron triangle that is really flexible is scope, i.e. the number of projects that we can get done next year. And, let’s always assume that quality is not optional.
So the question is no longer how many people do we need. The question is how much can we get done with the people that we have!
In both the traditional world and the agile world, we still need to size the work that needs to be accomplished at some point. In the traditional approach, we went to all lengths to size the project by using function points, COCOMO, or built a glorious project plan detailed out with tasks and estimates. Then we had to blend that plan and schedule it with other proposed plans. It was a house of cards and was simply too expensive to do. Reality was that we tried to prioritize the projects and hoped we could get enough done, all the while hiring on an adhoc basis.
Taking an agile approach, we still need to size the projects, features, deliverables or whatever unit of work you like. My recommendation is to build your enterprise backlog at a higher level than user stories and then use the very same pointing techniques to size those larger chunks of work. Your only other option is to get all (and I mean all) of your teams to have a standard measure of velocity. Resistance may be high. You then can get an enterprise velocity by adding up all team points. But that also means that you need to develop stories and story points for a year’s worth of work. Not likely. So, keep it at a high level.
Begin to track your ability to deliver those larger chunks over a given unit of time (monthly, quarterly?) and establish an enterprise velocity. Assuming your costs (people) are more-or-less fixed and you are trying to identify how much you can get done, you simply take the enterprise velocity per unit of time to see how far down in the corporate backlog you can get in a year. If it isn’t far enough, an expensive approach is to add enough velocity (people) as a percentage to get to where you need to be. Add a bit more to account for ramp up time. However, I would strongly suggest that if you aren’t getting enough throughput, then leverage the principles of flow first and add people only as a last resort.
Although that is a bit over-simplified, the approach is far easier that the traditional one. The traditional approaches tried to be precise, but were never accurate. The agile approach won’t be precise. However, the accuracy will be much better, especially over time. That is evidenced by agile teams and their use of velocity for planning user stories and sprints. To get a stable, reliable, enterprise velocity you will need to keep your teams relatively stable. Rather than push work at them, they pull work off of an enterprise backlog. That ensures that capacity and demand are always in balance, eliminates unnecessarily high utilizations and multi-tasking and helps to establish a consistent velocity. Such an approach will take more than a year to get rolling. But, considering that organizations have been wrestling with the approach to resource capacity since the 70’s, a year or two isn’t that bad. You have to start sometime.
So the question of “How many people do I need?” is now replaced by “Am I getting enough throughput?”