“But we have specialists outside the team, we have to beg… borrow… steal people… we can never get them when we want them, we have to wait, we can’t get them enough.”
It doesn’t matter how much I pontificate about dedicated, stable, consistent teams I hear this again and again. Does nobody listen to me? Does nobody read Xanpan or Continuous Digital?
And I wonder: how much management time is spent arguing over who (which individuals) is doing what this week?
Isn’t that kind of piecemeal resourcing micro-management?
Or is it just making work for “managers” to do?
Is there no better use of management time than arguing about who is doing what? How can the individuals concerned “step up to the plate” and take responsibility if they are pulled this way and that? How can they really “buy in” to work when they don’t know what they doing next week?
Still, there is another answer to the problem: “How do you manage staffing when people need to work on multiple work streams at once?”
Usually this is because some individuals have specialist skills or because a team cannot justify having a full time, 100%, dedicated specialist.
Before I give you the answer lets remind ourselves why the traditional solution can make things worse:
- When a resource (people or anything else) is scarce a queues are used to allocate the scarce resources and queues create delays
- Queues create delays in getting the work done – and are bad for morale
- Queues are an alternative cost: in this case the price comes from the cost-of-delay
- Queues disrupt schedules and predictability
- In the delay people try to do something useful but the useful thing is lower value, and may cause more work for others, it can even create conflict when the specialist becomes available
The solution, and it is a generic solution that can be applied whenever some scarce resource (people, beds, runways):
Have more of the scarce resource than is necessary.
So that sounds obvious I guess?
What you want is for there be enough of the scarce resource so that the queues do not form. As an opening gambit have 25% resource more than you expect to need, do not plan to use the scarce resource more than 75% of the available time.
Suppose for example you have several teams, each of who needs a UX designer 1-day a week. At first sight one designer could service five teams but if you did that there would still be queues.
Why?
Because of variability.
Some weeks Team-1 would need a day-and-a-half of the designer, sure some week they would need the designer less than a day but any variability would cause a ripple – or “bullwhip effect”. The disruption caused by variation would ripple out over time.
You need to balance several factors here:
- Utilisation
- Variability
- Wait time
- Predictability
Even if demand and capacity are perfectly matched then variability will increase wait time which will in turn reduce predictability. If variability and utilisation are high then there will be queues and predicability will be low.
- If you want 100% utilisation then you have to accept queues (delay) and a loss of predicability: ever landed at Heathrow airport? The airport runs at over 96% utilisation, there isn’t capacity to absorb variability so queues form in the air.
- If you want to minimise wait time with highly variable work you need low utilisation: why do fire departments have all those fire engines and fire fighters sitting around doing nothing most days?
Running a business, especially a service business, at 100% utilisation is crazy – unless your customers are happy with delays and no predicability.
One of the reasons budget airlines always use the same type of plane and one class of seating is to limit variation. Only as they have gained experience have they added extras.
Anyone who tries to run software development at 100% is going to suffer late delivery and will fail to meet end dates.
How do I know this?
Because I know a little about queuing theory. Queuing theory is a theory in the same way that Einstein’s Theory of Relativity is theory, i.e. it is not a theory, its proven. In both cases mathematics. If you want to know more I recommend Factory Physics.
So, what utilisation can you have?
Well, that is a complicated question. There are a number of parameters to consider and the maths is very complicated. So complicated in fact that mathematicians usually turn to simulation. You don’t need to run a simulation because you can observe the real world, you can experiment for yourself. (Kanban methods allow you to see the queues forming.)
That said: 76% (max).
Or rather: in the simplest queuing theory models queues start to form (and predictability suffers) once utilisation is above 76%.
Given that your environment is probably a lot more complicated then the simplest models you probably need to keep utilisation well below 76% if you want short lead times and predictability.
As a very broad rule of thumb: if you are sharing someone don’t commit more then three-quarters of their time.
And given that, a dedicated specialist doesn’t look so expensive after all. Back to where I came in.
| Published on Java Code Geeks with permission by Allan Kelly, partner at our JCG program. See the original article here: Utilisation and non-core team members Opinions expressed by Java Code Geeks contributors are their own. |
