views:

1226

answers:

13

I am trying to find sensible resource-allocation models for developers. The department will have many different projects for different external customers, so I need to make some guidelines in order to avoid people getting angry due to lack of focus, not working on things they want to, etc.

Currently I have suggestion for a model:

  • Junior developers – will only work on one project at a time (reason: mainly that they are unable to control their own time use)
  • Intermediate developers – will mostly work one project at a time for 50 % or more, but might be 50-50 on two projects
  • Senior developers – will work at the most on 3 projects at a time; percentage can be e.g. 50 %, 30 % and 20 %.

It’s the seniors that I am worried about. As the customers might want to buy a junior-group only, I need to provide them with a mentor (senior) to make sure they have the knowledgeprogress and the aid that they need (someone with experience and knowledge about their project). A group of 5 juniors will get a senior at 50 % of the time.

The question is – can a senior handle 3 projects at a time (he will be hired with this in mind – I will not trick someone to believe that they will write code 100 % of the time and end up with 20 %), or is this too much? EDIT: The seniors I plan to use for mentors will not be expected to code at all. They will focus on mentoring and training themselves, e.g. in new and upcoming technologies.

I have a feeling that 2 projects is way better that 3? Or? What if the senior is needed 50 % on the “junior-project” and 30 % on analysis and design on another project. Can he handle one more project with the last 20 %?

(And no – time for training, coffee, etc. will not be part of the 100 %. I have already reduced the “real” amount of working hours with that in mind).

+1  A: 

Software development isn't like assembling a happy meal. Why would expose your customers to your pay grades? Why not assign the best team for the job and communicate that to your customers?

As to your specific question, I think it is unwise to have people working on more than one thing at once; projects can pull people in one direction or another and a balance of "50/50" or "33/33/33" will never occur in reality. The problem projects or the pushy managers will get 100% of the resources they want.

You may instead want to focus on when certain talent is needed on a project. Certainly, during the tail end of implementation and testing you will not need your senior people. But, you will absolutely need them during analysis, design and initial implementation.

davetron5000
I am trying to build a dept. that will reverse the Indiaflow. Why not use local team instead. Cost is of the essence for the customer in this case. I would like to focus on quality and peopleware, but customers will (only) care about price. So I give them juniors and make sure to aid them on the way
sonstabo
upvoted for telling it like it is
Steven A. Lowe
@sonstabo: if the customer only care about the price, find different customers; let the cheapskates reap what they sew.
Steven A. Lowe
+2  A: 

It depends a lot on the person. Knowing the nature of software projects, the shit WILL hit the fan sooner or later, and when all three of a senior's projects are turning sour at the same time, and three teams of juniors are yelling for guidance, how will you help your senior cope?

Ace
Yelling for guidance? I thought they normally just stumbled along blindly until they fell off the cliff :)
rmeador
+23  A: 

I would suggest that no people who are really involved in a project should be on more than 2 at the same time. Anything more than that and you get a serious drop in the quality and quantity of work.

Saying that a neat trick which works for us is to have seniors on multiple projects but acting as mentors/consultants. They help other people out, review their code, research solution for the bottlenecks, participate in spikes and so forth. They are tremendously useful this way but their participation is not counted towards the team velocity and they're outside of the project team proper.

P.S. It also helps to keep senior people from being bored.

P.P.S. A group of junior-only people is a sure recipe for disaster. You need to get at least one senior working full time on each such project.

Ilya Kochetov
This is more or less what I intend to do. It is not my intention to use the seniors for coding at all. But I did not think of using them for code reciew and spikes. Thanks for the advice!
sonstabo
I would even go this far: only one project at a time, or at least one project having the priority, eg. 70:30 split of time/tasks. If it's near 50:50 go for 2-4 weeks this project, then the same time the other project. Never let someone switch projects on a daily basis unless something's urgent.
steffenj
+1  A: 

How many tasks someone can handle has todo with his discipline and job motivation and not with the programming skill.

He can only work on one project at the very moment. Switiching the project makes you loose the context, and this problem happens with every human beeing. Also with senior developers.

Andre Bossard
+2  A: 

This really depeneds, if you want the highest quality in the least amount of time then the answer is one.

From your post it seems that speed of delivery or quality isn't the top priority but learning is quite high on the list, and in that case a senior developer can help and mentor Junior devs in multiple projects. This is usually the tradeoff that is made since it a effective way to "grow" the organization just make sure that the senior dev know's that his role is one of teacher and mentor (as well as peer) and not that of code-monkey extraordinare. It will help him immensly in aligning his priorites.

Torbjörn Gyllebring
He will be hired with the mentor-role in mind. I know plenty of senior-developers that would hate this position. So I would make sure he/she knows what they are up against.
sonstabo
Then I would say that instead of focusing on the number of projects focus on the number of people the senior developer will be mentoring and coaching. He'll be much more efficent if he got a small enough group that he can really get to know each of his adepts instead of them just being a big horde.
Torbjörn Gyllebring
In my current "model" he/she will only be responsible for a max of 8 juniors at any time.
sonstabo
+2  A: 

I find that I can be deeply involved with just one project at a time. I can have meetings and conversations with a half-dozen projects where someone else is actually responsible for delivery.

I can mentor and coach 5-10 other projects without any problem at all. Depends on the depth of involvement.

But when I'm responsible for the work product, I have to focus on just that.

S.Lott
The depth and the phase of the project makes a lot of difference here. If all the projects are deploying at the same time, the senior dev's head is going to explode. But if there's one project s/he's concentrating on that's going live, another mid-dev and one in planning, it might work out alright.
y0mbo
When you say mentor - do you feel that you are able to give good answers in regards to e.g. architecture for 5-10 projects at a time, e.g. during a week?
sonstabo
@y0mbo: That's why my limit for deep involvement is 1. Casual involvement -- even during deployment -- is someone else's problem, I'm just helping. It's the "chicken and pigs" problem. I can lay a lot of eggs, I can only provide bacon once.
S.Lott
@sonstabo: 5 is easy -- that's 8 hrs. mentoring. 10 is hard -- people might feel short-changed because I was "too high level". I'm a scarce resource, everyone has to cooperate in using me wisely. If someone wants detail, someone else has to back off. They must cooperate with each other.
S.Lott
+2  A: 

There is a quote that says that 9 women can't produce a baby in one month.

I think this applies here. If a developer is splitting his time 50/50 over two projects, could the projects be scheduled so that the developer works 100% on one and then when he's finished works 100% on the second one?

You get the productivity gains from having a focused developer but the work still takes the same length of time.

Si Keep
I agree - see my edit in the original post. The senior (mentors) are not supposed to provide any coding at all. They will focus on mentoring the others. So they will not deliver anything, at least not something that is a task in the project plan.
sonstabo
The quote is from Fred Brooks's book "The Mythical Man Month"
Rob Wells
+1  A: 

Focusing on resource allocation touches on only one of the three aspects of a project. How many projects a senior developer can work on concurrently depends as much on the scope and schedule of a project as it does on their individual abilities. Every developer, senior or not, is going to lose time due to context-switching, as Andre Bossard says.

I don't think there's a neat formula or stock answer to your question because there are so many variables to consider for each project. I'm sure you want all your projects to be of high quality, so I encourage you to allocate resources accordingly. Make it clear to customers that trying to save costs (by requesting a junior-only team) will increase time to deliver and may reduce quality. Laying out the costs of each choice on resources, schedule, and scope so the customer can make an informed decision is the best thing you can do.

Scott A. Lawrence
That is true-to ask the customer "What do you want - low cost or high quality". My problem is that I am expected to deliver high quality no matter the agreement entered with the customer. "You want 4 juniors, sure. But you'll have to pay for one mentor as well." But pitching this might make the job
sonstabo
Scott A. Lawrence
Its the customers that are my challenge. "How to sell high-end outsourcing" and increase the customes cost at the same time :) I have some time to come up with the pros and cons :)
sonstabo
A: 

If your juniors lack time management skills (not unusual) they need mentoring anyway, even if they are only working on a single project. It's easy to get carried away "gold-plating" the less important modules.

finnw
A: 

I'd say as many as you can fit on a hard drive. Though that's subjective because you're just diving someone's time/effort up between the projects.

Chad Moran
A: 

I totally agree with Ilya's answer. Switching contexts or tasks reduces productivity drastically. Joel wrote an interesting article about this phenomenon over at his web site.

Rob Wells
+1  A: 

as usual, "it depends"

  • it depends on the complexity of the project; really difficult projects/problems may tend to consume the senior developers' every waking moment no matter what theoretical distribution is planned; some problems are just hard (or really really interesting)
  • it depends on the senior developer - some may thrive on a mentoring-only role, others may become depressed if not allowed to code
  • it also depends on the quality of the junior teams -
    • juniors that ask seniors every little question that pops into their heads ("how do i code a loop in java? why isn't my MessageBox showing up on the browser? who do i call to get the internet installed on my computer? what's my password?") are going to drain the brain of even the most patient and benevolent senior,
    • while juniors that must figure out everything for themselves will quietly let the project die while they beat their head against a typo they...just...don't...see.

In short, all senior developers are not equal (ditto for junior/intermediate), you'd better talk to each one individually and construct a compatible team for each project. What is a better strategy: giving the customer a price that's appealing, or providing a team that can do the job? The perception that all programmers are interchangable is a huge part of the offshoring problem in the USA, but if you package up a bunch of juniors at a bargain you are continuing that perception, and probably defeating your stated purpose. Better to do the job right, or not at all, for long-term viability.

Steven A. Lowe
True - much the same way as a project plan :) Things change on the way. I am currently putting together a framework that I can work from. Changes to contracts, how to work with the customer, how to create a team will come on the way. But I need some ideas to tell the seniors when I start recruiting
sonstabo
@sonstabo: tell the seniors exactly what you are trying to do, and ask them how they can help or what they recommend. Pay close attention to what they say, and trust your instincts. Good people will help you find the right way, not-so-good people will play yes-man to get the job.
Steven A. Lowe
+1  A: 

Studies in aircraft cockpit design indicate that people can handle 5 + or - 2 tasks at once. Ideally you need to keep it below 5 to keep the risk of the pilot loosing his grip on the situation. I think this principle translates well into everything from GUI design to task management in other jobs. I believe the trick for your problem is to try and keep track of how many tasks the senior developers are trying to manage. On some more complex projects a senior developer could be completely consumed by that one project, where with multiple smaller simpler projects you might get away with 3+ at once.