Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 80 posts at DZone. You can read more from them at their website. View Full User Profile
Strategic Staffing, Or, How many people should I put on this (Agile) project?
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 is the loosest sense, think “piece of work”)
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.
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?
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.
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
small is essential because it reduces risk and because it minimises the
momentum which can make it difficult to cancel work.
minimises the influence of Conway’s Law [[link]]: “every organization
will produce systems which are a copy of the communication paths in the
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
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?”
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
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.
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
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.
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 [[link]].
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?
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.