Distributed software development is hard - But is there hope?

Poll results The Reg reader poll run earlier this week as part of our agile development workshop produced a set of results that do not paint a particularly inspiring picture. When asked how distributed software development was managed within organisations, almost half told us things were not that great. About a third gave feedback indicating that they were just about doing okay, but only one in five said things were managed well.

Only one in five. Ouch. So what sort of problems are organisations having? At the top level you talked about communication and collaboration challenges, which is a theme across 85 per cent of respondents. Perhaps this isn’t so surprising – what comes as a bit more of a shocker is how nearly 70 per cent remarked on software quality issues arising from too much variation in skill sets between sites. Distribute development and quality will suffer, seems to be the message.

There’s a range of other issues as illustrated in Figure 1. Different combinations of these challenges conspire in different organisations to give rise to the unimpressive overall performance we mentioned at the start.

Figure 1

While this may all sound a bit downhearted, by drilling into the data we find some very interesting correlations which provide a view of the kind of factors and behaviours that can make a difference. Looking into these factors we can learn a whole number of ways that organisations can help themselves improve how distributed development is done.

Take the way in which distributed development activity is managed and organised, for example. If we put to one side the respondents who either centralise or outsource everything completely (about one in five of the sample), we are left with three groups of similar size. The first of these implements a “hub and spoke” approach, in which a core central development function is surrounded by geographically-distributed satellite teams. The second group implements more of a peer-to-peer setup, in which activity is distributed across teams of equal status. This then leaves the third group, who behave in more of an ad hoc manner, i.e. mix the different approaches with no consistent policy on how things are managed between sites.