One of the questions that comes up again and again in the context of Agile work is “How do I know how many people to put on this project?”
(I’m using the word ‘Project’ in the loosest sense, think “piece of work”)
My usual answer is: Staff Strategically, allocate people to a piece of work in relation to how important this piece of work is relative to everything else you are trying to do. Keep teams together for as long as possible, only make small, gradual changes to teams over time.
This isn’t really a problem when work is underway, you simply sum up the ball-park estimates on the work remaining (in abstract points), measure the velocity (again in abstract points), divide total by the velocity and if you get an answer you like then all is well. If the answer is not soon enough you can (gradually) add more people, and if the answer is very good you might even slow down.
However, the problem really comes when you are starting a piece of work. Particularly if you are bidding on a contract to do work for someone else. The problem occurs because without any data (velocity, sum of outstanding work) you can’t estimate when you will be done, and without doing the work you can’t get any data.
Rule 1: Without data you can’t forecast anything so don’t pretend you can.
So, what do you do?
Option 1 is to pretend you aren’t doing Agile; use whatever methods and techniques you’ve used before, get an estimate (or maybe more of a guess) on how many people you need for how long then get started with those numbers. As soon as you start throw away the plans. Wing it for an couple of iterations, by then you have the data and can re-plan.
Not a perfect solution but one that could work.
Option 2 is to just start. Start as small as you can, I think two people is about as small as you can get – below that you are into the realm of micro-projects which have their own dynamics.
Let this mini-team run for a few iterations and then, as if by magic, you have data.
Once you have data you can: keep as is, grown, shrink or cancel entirely.
Rule 2: Start small, get data, grow later
Starting small is essential because it reduces risk and because it minimises the momentum which can make it difficult to cancel work.
It also minimises the influence of Conway’s Law: “every organization will produce systems which are a copy of the communication paths in the organization.”
If you start with a big team you will get a big project – allocate a C# developer, a DBA and a UI designer and you’ll get a three-tier architecture. If you start small you should get a small project.
In the longer term how you staff a project is less a function of “How many people do I need to do this work?” and more a question of “How many people can I afford to do this work?”
Projects are never really staffed on a “how many people do I need” basis, we just pretend they are. Writing today, March 2011, you will probably put more people on a piece of work than you would 18 months ago, but fewer than you would have three years ago.
Rule 3: Staff work strategically relative to the other work to be done and corporate priorities, rebalance only occasionally
Strategic staffing means looking at how any one piece of work stacks up against the other pieces of work in play – or proposed – and the resources that are available to use. It means considering: what is the benefit of a piece of work? What is the risk? What work absolutely must be done, and what work can be left undone? What work is experimental?
The trick is to arrange work so teams can grown, or shrink, as resources and priorities change.
That is not a recipe for changing team composition every week. Indeed, the general principle should be: keep teams together and consistent for as long as possible. Only change teams occasionally, and only grow teams slowly.
However, things do change and work needs rebalancing. This should be an active, measured, and occasional process. Better to change staff allocations once a quarter in a review meeting than every week as a knee-jerk reaction.
That is what strategic staffing is. If you find yourself changing staff allocations every few weeks in response to events you aren’t working strategically.
As for deciding how many people to put on a piece of work when you are bidding for a contract, well, its another argument for constructing contracts as ongoing, rolling contracts.
Telling your client: “We think we need six people for six months” is little better than lying if you don’t have data to back it up. Have these six people worked together before? How productive will they be with the client’s environment? With the clients requirements? What work might emerge?
Better to tell the client: “We propose to start with three people for three months, at the end of that time we will review progress with you and decide with you, when we have data, whether to increase or decrease staffing. If you want to move faster than we can allocate four people and review after one month.”
It might not be what your client wants to hear but it sure beats guessing, or lying. Involve your customer, give them choices. It might not be a great sales technique but if the client won’t engage in this conversation there are probably other conversations they won’t have either.
