The final result of a software development department is working code, code that we hope will be valuable (effective).
So, three years ago at Pearson, we invented a simple test for the efficiency of a software development department or project. The test is far from perfect and there is no perfect score. Additionally, it may not be worth us improving efficiency if it costs us in effectiveness. But the results we have seen, time and time again at Emergn in differing companies, highlights a major problem that development is usually far too expensive.
Developer Surround Ratio
Working code is typically produced by the developers.
So for every one hour of code development (the actual output), how many hours of support work do we have (for example, analysis, testing (we typically exclude developer testing), management (both project and executives who love not to be counted), administration, design, architecture etc). All things being equal (effectiveness not changing), it would be preferable to have nobody supporting them (usually a unrealistic proposition). However, we have found the ratios for support are way too high, whilst at the same time, developers are often the constrained resource leading to departments employing roles like management to basically say no (in a polite way of course). Instead departments should be examining these surround costs and eliminating them where it makes sense.
What Does It Look Like in The Real World
When I was appointed in charge of software development at Pearson, we had on a typical project six (6) hours of support for every developer hour (1) at one site. If you don’t have timesheets, just do a rough calculation. Now you might initially think this number looks crazy, but we have discovered at Emergn, that 6 : 1 is not an outlier and is actually quite a common ratio. Large companies have large ratios, but don’t have visibility that shows this problem.
Let’s put that into perspective. For every developer desk you have, you need 6 people working with him to do his job, six people watching his monitor as he codes, essentially telling him what to develop. Now of course this doesn’t happen, instead we have tons of waiting time in a typical project (queues) that actually hides this problem.
Now when I left Pearson, the ratio was switched from a total average of 3.8 to 1.8 (this is alongside improvements made in the department over a two year period leading to the company winning UK Agile Team of the Year). So we were both more effective and more efficient. We were able to cut department budgets, fund an agile transformation and complete more projects in a single year than ever. One of our leading projects had a ratio of 0.6 : 1.
Now get this, typically the average wage of the surround is also higher than the developer cost. In Pearson it was around 25% higher. So the average cost per hour of development went from £186 an hour to just £91 an hour with no negative (in fact positive) impact on effectiveness. A significantly better result than the usual choice of offshoring which typically drives up surround ratios, hiding the true cost of development by only looking at the developers cost per hour. The 0.6 project, was running at a cost of £52 per hour.
A Word of Warning
Improving the developer surround ratio is something that the vast majority of companies should be doing. We have found that this can only really be done in an evolutionary way (due to HR constraints and the need to not see effectiveness impacted). Alongside an Agile transformation, this makes perfect sense. We have found that a 1 : 1 ratio is usually a good point to initially achieve (of course, reiterating, there is no perfect score).
Let me be clear, effectiveness is almost always more important. By itself, developer surround ratio can make you focus on the wrong thing. However as part of an overall change of improving effectiveness and efficiency, the developer surround ratio can be used to manage costs within your department (the efficiency side). Aiming for a ratio of zero is likely to lead in massive drops in effectiveness – however we have found that very large ratios, rarely result in effectiveness either.
What is your developer surround ratio and how can you start improving it?