The jury’s in: Effective software delivery

Over the past few weeks, we’ve been running a series of articles, polls and feedback reports on the subject of software development in general, and agile development in particular. A number of major themes have evolved, notably that agility is not some kind of panacea for all software ills – indeed, in many cases it is as much a symptom of good software development practice as it is a cause.

In this final article in the initial series (though rest assured, there’s still plenty more meat to be boiled off the bones of your responses, comments and feedback), we thought it worth covering off the closely linked issues of communication, particularly between management and developers, and the level of formalisation that exists on development projects.

Sifting through the hundreds of responses to our most recent poll, we found there was a pretty broad range of management styles in practice (Figure 1). Indeed, and quite positively, only 14 per cent of respondents felt there was a ‘command and control’ approach to software project management.

Figure 1

Meanwhile, when we asked about the level of structure in software development projects, we were quite surprised to find that over half of respondents felt that there was no particularly formalised structure in place. Now we know that these polls are self-selecting in that people are more likely to respond to an area that interests them, but this doesn’t explain why there should be such a high proportion of less structured dev organisations out there.

Figure 2

Rather than drawing any rash conclusions about how absolute these figures are, what’s perhaps more worthwhile is considering whether such things make any difference. We did ask a number of perceptional questions around the state of ongoing projects (Figure 3). While the results are of passing interest in themselves – the amount of confidence about project metrics is rather low, for example – it is when we compare these results against such criteria as structure and organisation that we start to see the real nuggets.

Figure 3

Considering development structure first, there is a pronounced difference between level of formality and increased communications/awareness. Questions around the latter can be asked in a number of ways (Figures 4 and 5), what is most notable is how those organisations that don’t have a particularly formalised structure (that’s our 57 per cent, remember) are also the laggards when it comes to communications within the team, and awareness of project timescales.

Figure 4

Figure 5

There’s also a clear tick in the box for agile methodologies. As we have seen from prior feedback, it can be difficult to separate how much agile ways promote good communications, and how much they depend on them. When it comes to project timescales, however, we can see a pretty strong correlation between those adopting agile and the awareness of deadlines.

Turning to management, we can also see the importance of certain approaches when it comes to awareness (Figure 6). While there are differences, it could be argued that any of the first three approaches in the figure – centralised management, peer relationships or developer autonomy – would be better than either proscriptive management or leaving developers to get on with it.

Figure 6

This point comes across even more strongly when we consider a more fundamental question – that of software quality. All of the things discussed so far – communications, collaboration, awareness of timescales and so on – are project-level questions. It wouldn’t matter a jot to end-users if such things were good or bad, if the resulting software were unaffected (though of course developers might be a bit miffed). However, there is a clear correlation between such factors and the resulting quality of software (Figure 7).

Figure 7

Given its clear lead in the chart, it’s worth asking what is meant by ‘peer to peer basis’. We could either provide a long, rambling piece of psychobabble at this point, or alternatively refer the reader to the bottom line of the chart: when it comes to software quality, command and control structures just do not work. We’ve all worked in environments like this – and several books have been written about the alternative (we’d recommend the excellent Peopleware by Tom de Marco and Timothy Lister, which refuses to date).

So, what of agility? We can see agile methodologies as very much a means, rather than an end (Figure 8). There are clearly benefits to be had from adopting some level of formalisation in software projects, but the question of whether that formalisation comes from structured or agile methodologies would appear to be a red herring – far more important is whether the underlying criteria of communications and awareness are in place.

Figure 8

Indeed, it could no doubt be argued that a total lack of structure would be acceptable as long as everybody knew what they were working on, and when they had to deliver by… but to be fair, what else is the structure doing if not these things?

Ultimately, if there is a lesson to be learned, it is for the managers to learn it and not the developers. If you want to deliver high quality software, on time and to budget, then micro-management will not be the answer. The best managers are those who understand just how powerful is their resource pool, if only they learn how to harness it – the answer lies in stirrups, not shackles.