What is a healthy development team size?

Question

I have mainly worked in small teams or as solo developer and I am now working in a team of two working in-house maintaining a suite of business applications. There are bugs and as the system is 14 years old there is a lot legacy code and so one of the projects I am tasked with is to bring the application up to date so we are working on a re-write. The business moves on though and there are major changes that come up every few months as well as business support such as ad-hoc reporting, proof of concepts etc.. On top of this we are the dba team, look after and second line support. Oh yeah and I project manage too.

So hopefully I've painted the picture that we as a team are busy. Infact it is getting past the point where I think we need another pair of hands. My reasoning:

• Projects are not moving forward. (The rewrite takes second place as there is no immediate business value.
• The db needs severe refactoring (performance is an issue in some areas - but looking at this has been postponed as there is no quantifiable business benefit)
• Each project that is started has to be cut short and so we are accruing huge technical debt.
• As a result of which we are constantly fire fighting,
• We are creating more applications to cover more of the business process all the time. As a result there is more to support.

I've tried to break things down into iterations and to be as agile as possible but the problems are still there and I feel they are getting worse.

So my question is how do you quantify how many developers you need in a team? What sort of things can I go to my boss with and ask him for more help?

Answer 1

Read The Mythical Man Month.

Answer 2

You need more than two :)

As you're managing as well you have at best 1 1/2 people working on the actual projects. At least half your time will be taken up with management activities.

You need to take the tasks you've been given and with their deadlines show how many people you'd need in an ideal world to deliver them. You can then take this to your manager and have a conversation about what resources you need to do your job. Point out that with insufficient resources things don't get done.

If you get agreement to hire new people, don't hire them all at once as you and your current colleague will be spending all your time training the new people & not delivering anything. Phasing in the new staff will enable them to be involved in training the ones that follow.

You won't get all the staff you need, but you might get three or four at which point you'll be able to plan your work a lot better than you can now. You might even be able to pay off some of that debt.

Answer 3

While reading the Mythical Man Month is solid advice, too often people cite the book as a reason not to add people. In your case, I think it's obvious that you need more hands.

My first hire, if I were me, would be a support/bug fix guy. It sounds like you're getting bogged down in user requests and are unable to make progress on the product with these requests. If you get a bug fixer, you can promote those fixes into the new release without having to do them yourself.

Secondly, get a DBA. A good one. Not just one of the street. They will change your life, I promise. Your apps will run faster, your uptime will be better, and your servers will be cleaner.

Thirdly, hire developers as you need them. If you find yourself developing three different mission critical apps, get at least one more developer in there to take one off of your plate. As has been mentioned by Rob, a great way to get new developers is by running them through the bug fixing/support position to get them familiar with the projects. This is a great way to train and get some bugs swatted while you're at it.

The Mythical Man Month is all about throwing resources at a single project near the end of the lifecycle to try to push it out the door. That doesn't work, and won't work. Ever. But you have multiple projects across multiple domains with a lot of people asking for more. You need to break up your development/staff into these domains (DBA, support, new dev), and then possibly into business domains (Accounting apps, CRM, CMS, etc, etc). IMHO, your need is entirely justified.

Space out your hires so that you can train them and give them ample time to get into the swing of things. Support, then DBA, then new devs. I say all of this with one final caveat: Do not, under any circumstances, hire somebody just because you need to fill the position. Hire quality or don't hire at all. Your life will turn into more of a living hell if you hire the wrong person for any of these positions.

Answer 4

Personally I've found that a close nit team of 5-9 developers works best. That way you'll usually have a very strong language (C#, VB, java) dev, a strong SQL dev, a best practices dev etc. that way when a dev has been struggling with someone for more than 20-30min they can ask the other dev for help.

The MOST important thing though is to spend time outside of the office together. even if you just have breakfast together on a friday morning or go to a movie once a month. Its amazing how it builds the inter-personal relationships.

The better your team can "play" together, the better they'll work together!

Answer 5

You have to be able to credibly estimate effort required for particular project scopes in order to show you need more staff. Do you have a track record on scoping? Have you been tracking estimated completion dates as tasks are accepted, planned and assigned? Having those kinds of numbers along with the list of upcoming tasks gives you the ammunition to argue for more staff. If you can't show there's a mismatch, you will often run into pushback about hiring more developers.

It's not easy to demonstrate technical debt to non-techie managers. Are your gatekeepes savvy enough to understand this argument already? If not, you may need to start making the point by including a factor for paying off the debt in your estimates. If you are explicit about the accumulating debt and its effect on your future estimates, you can start arguring for more help to reduce that cost.

As far as the fire fighting, you also need to be clear that this is a direct cost against your estimates. When new fires arise, be explicit about the cost in lost time on your current milestones. If you're still fighting fires when new assignments arise, be clear that those problems have to be addressed, and it can only be done before or after since there isn't dedicated staff allocated.

Answer 6

Hiring should be based on business needs - my recommendation is to provide accurate, solid information about what projects are in the pipe-line, how much effort is required to support the current application as is, the on-going impact of changes to the stability of the application and the potential risks at hand if the application is not properly maintained and updated. To me the following steps need to take place (ongoing):

• the business provides the new projects
• you provide the effort for those projects and effort for properly supporting the existing application
• the business provides the priority and the budget
• you plan it all out and...
• all of the above is used to derive the people and skill sets needed to successfully execute.

Don't hire based on assumptions hire based on a plan - a short delivery will require more people and with more people more management and support (logistics) - the longer the deliver of all projects the few people and support. Go to the business with a plan and you have a better chance of getting the people you know you'll need as opposed to going to them with a request for more people.

Answer 7

Reality check:

• Projects are not moving forward. (The rewrite takes second place as there is no immediate business value).

If there is no immediate business value, then why are you doing it? Busy work? If there is a real value to it, then you need to document it.

• The db needs severe refactoring (performance is an issue in some areas - but looking at this has been postponed as there is no quantifiable business benefit)

Again if there is no quantifiable business benefit, then why are you doing it?

---

Once you cam jutify working on those projects and how fast you need them done, then you cans start quantifying how many and what kind of people you need.

You need to know:

• how much work is to be performed

• what kind of work is to be performed

• how fast it needs to get done

From there, with some contingeny resources, you can decide how many people you really need to have, and justify it to your boss.

---

Now, you can't just throw people at the project and hope it gets done (see Brooks' law). The more people you add to a project the more communication that must happen between them.

At some point it becomes benefitial to separate the project into sub projects. I won't give you a hard number, but when the ammount of work that gets done by adding one person gets surpassed by the extra communication that they cause; its definitely time to split the project.

This of course, would require you to do more PM work, and taken to greater and greater levels, sub PMs (or team leads) to help you manage the whole project.

Answer 8

You are probably in the best position to judge precisely whether you need to hire someone extra. However, even if you decide to that, you aren't liable to find someone good overnight.

So while you are waiting for your personnel ship to come in, why not take a look at how your team is working right now with the people you have? So instead of steering you to TMMM, why not read Peopleware for ideas? A good companion article online is Joel's A Field Guide to Developers.

The kinds of things you should look at should be obvious from this. Do your developers all have private offices? Do their phones have caller-ID and off-switches? You don't have PA systems interrupting them throughout the day, do you? Do they all have multiple monitors and good quality chairs? Do you routinely buy them whatever software books they might take a fancy to?

Do you move heaven and earth to shield them from office politics? Do you let them pick their own projects to work on? Their own tools?