When managing development teams on medium or large IT development projects (effort in excess of 18 developer months), the majority of the cost of the project is used up in developer time rather than capital expenditure. Therefore, at times when budgets are stretched, it is especially important to understand the issues surrounding developer productivity.

There isn't a line on your balance sheet for your developers' productivity (except perhaps the bottom line - but only if it's really bad). Without understanding the detail of what your developers have to do during their day, it is hard to manage and optimise it.

Here are three things that will help you get the most out of your developers.

Minimise interruptions

The number one cause of developer productivity loss is interruptions. I cannot stress this enough.

When solving complex problems involving a number of components or a wide range of scenarios, it takes time for the developer to build a personal model of what is to be done or what is going wrong. To refresh one's memory of previously written code, to determine possible problems and formulate a plan to solve them - all of these things require complete concentration. Interrupting during this process requires a context switch meaning that all of this information has to be parked while another issue is tackled. A single interruption like this can set someone back by half an hour or more. If this happens frequently enough, it really eats into time and hence the budget.

A few techniques to reduce interruptions:

  • Schedule meetings at the beginning or end of the day - not in the middle of the morning or afternoon.
  • If developers are required to answer client calls or provide support, interruptions can be minimised by having a strict support rota - where one developer is dedicated to support and does not need to produce other deliverables during this period.
  • If this isn't practical, another possibility is to restrict calls to a particular time of day - so as to free up the remainder for uninterrupted work.

Using any method that is appropriate in your workplace, it is really important to ensure that developers have at least a couple of hours per day without any forced interruptions.

Pair programming

Pair programming is where two developers sit together at the same workstation and work as a team on solving a particular problem or producing some new functionality.

Pair programming on the face of it can sound like a fairly cushy thing as it requires double the developer resource but it can reduce development and testing time considerably. Having two heads looking at a screen rather than one means that those silly mistakes that everyone makes but often misses individually will get picked up very quickly. Finding such bugs early reduces the cost to fix and it means that other developers don't have to help out later (which would take longer as they'd have to context switch, then understand the code and the issue in order to be able to help fix it). Once developers get over the initial irritation at having someone reviewing their code in real-time over their shoulder, this helps greatly.

Deal with bureaucracy - so developers don't have to

First of all, minimising unnecessary bureaucracy is an excellent first step that will skyrocket everyone's productivity and should be undertaken as a matter of course.

It is essential that developers provide work estimates for tasks and keep the actual time spent on tasks up to date. However, developers should only do the things that it is not possible for the project manager to do. Other tasks involved with project planning, such as using this information to keep a project plan up to date and managing budgets should be done by the project manager. Delegation is something that PMs have to be able to do effectively in order to succeed. However, having the ability to delegate tasks selectively and appropriately is an excellent skill and one which will improve productivity all round.