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.

When we compare the performance of these three organisational and management approaches, we see some striking differences (Figure 2).

Figure 2

Interesting, isn’t it? Those taking a hub-and-spoke approach seem to find it easier to manage the distributed development process effectively, with the peer-to-peer model delivering less success. What's really telling, however, is that mixing the models appears to lead to many more issues. We can see this more explicitly if we break things out to the next level of detail (figure 3).

Figure 3

A key lesson here is that whichever approach you favour, it is important to be consistent. The kinds of governance frameworks, controls, and even support systems put in place to enable effective use of the hub and spoke model will be different to those required in a peer-to-peer development environment, and the evidence suggests that optimising for both is difficult to do.

Another major factor affecting performance is the motivation behind implementing a distributed approach to development in the first place. While about half of respondents tell us taking advantage of cheaper remote resources for cost-control purposes is a major driver, around a third highlight resource flexibility and/or a more a strategic value oriented initiative as being important. Some would argue that while the latter motivation is more noble, the former is more pragmatic, but the results of our poll suggests that putting too much emphasis on cost savings may actually be false economy (Figure 4).

Figure 4

Clearly, if cheap remote resources translates to inadequate experience and skill sets, an organisation’s thriftiness may come back to bite it. This could apply particularly if it leads to quality issues in the software – which could make things more expensive, not less.

This leads to the question of which parts of the development process are safe to distribute out to satellite or outsourced teams without running into trouble. The general consensus is to keep the critical early part of the life cycle (specification, analysis and design) in-house along with overall project management, putting the focus of remote activity on coding, testing and, to a lesser degree, integration work. (Figure 5)

Figure 5

Looking a bit more closely at this, we can get some insight into why the peer-to-peer model is attractive to some, despite the associated challenges our poll suggests. With a more even distribution of skill sets and experience between teams, those taking the peer-to-peer approach are more comfortable distributing some of the critical up-front specification, analysis and design, as well as integration and overall project management (Figure 6).

Figure 6

Going down the peer to peer route can therefore equate to better overall flexibility from a resourcing perspective, which in turn will have benefits in terms of overall delivery and responsiveness to the business. It’s not the only option or indeed the easiest, but it certainly merits consideration.

Beyond management and policy, one of the other key success factors for implementing a distributed development model successfully is having the right tooling in place, but the emphasis here is very much on generic email and document sharing, with more limited use of specialist software solutions (Figure 7). It's perhaps ironic that despite this emphasis, the main challenge is still collaboration, which points to the inadequacy of generic email-type mechanisms.

Figure 7

As we saw before there is a general correlation between adoption of appropriate tools and overall performance. We have seen a similar picture in this current poll, with those implementing change and/or configuration management, for example, faring better in terms of quality and control.

But picking up on the last of the capabilities in the above chart in particular, it is interesting to see around one in five respondents declaring extensive use of social networking tools, with a further 40 per cent making at least some use of such solutions. And when we look at the impact of this on performance, we can see that adoption of blogs, wikis, and so on can help to alleviate some of the previously identified challenges (Figure 8).

Figure 8

This kind of impact makes absolute sense. Putting facilities in place to allow developers to collaborate freely between locations can help to smooth over differences in skill sets and experience, break down 'us and them' barriers and prevent political problems, rationalise or work around differences in processes and practices and generally grease the wheels from a project management perspective.

So, is distributed software development hard to pull off successfully? The results of our poll suggests it is, but they also tell us that by paying attention to some of the key enablers of performance, there is indeed hope for those who are currently struggling. The bottom line: While saving money may cost more particularly with ad hoc approaches, there’s plenty that can be done to encourage better collaboration across all kinds of distributed environment. ®