Feeds

The jury’s in: Effective software delivery

Communications and structure lead to quality

  • alert
  • submit to reddit

The Power of One Brief: Top reasons to choose HP BladeSystem

Reg Reader Workshop 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

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

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

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 4

Figure 5

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

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

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

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. ®

The Essential Guide to IT Transformation

More from The Register

next story
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
KDE releases ice-cream coloured Plasma 5 just in time for summer
Melty but refreshing - popular rival to Mint's Cinnamon's still a work in progress
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Another day, another Firefox: Version 31 is upon us ALREADY
Web devs, Mozilla really wants you to like this one
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
prev story

Whitepapers

Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Application security programs and practises
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Securing Web Applications Made Simple and Scalable
Learn how automated security testing can provide a simple and scalable way to protect your web applications.