Software Development Methodology Wars

Don’t get caught in the crossfire between evangelists

It is in the nature of technology evangelists that they are dedicated to their loves and intolerant of rivals. Whether it is Windows vs Macintosh or Android vs iPhone, simple debates can too easily turn into virtual trench warfare. Software development evangelists may be less vitriolic, but they are just as enthusiastic. Some shout about their favourite methodology, often claiming that ‘everyone is doing it’ – or that they will be soon. Agile is a good example. It is now firmly established as a development methodology, but it remains just one of several options, including waterfall, with most organisations using a mix of approaches. That mix might see some teams or projects employing one methodology while others use a different one, or it could see teams taking a hybrid approach – for example, Agile as part of a continuous development (CD) framework. Indeed, as shown here, a recent global survey of 923 senior development and QA staff revealed that almost two-thirds had no dominant or preferred methodology, and of those that did have a clear preference, less than half of them – just 14% overall – prioritised Agile. On the other hand, when we looked at it from the project perspective, we found that on average just over a third of projects were Agile-based. So clearly Agile is indeed well used, even if it’s not as dominant as its fans might claim. Some, when trying to explain this divergence, will undoubtedly exclaim “It’s horses for courses.” And it’s true that different projects have different requirements. Some will be a good fit for Agile, but others will not – or they might be long-running projects which already have their methodologies established. There’s also a learning aspect for those who are not yet Agile adepts – the developers involved may need to learn new skills, and the organisation itself might have to adapt to a new way of working. Transitioning to a new methodology requires time and adjustment, for example to change from fixed predefined deliverables to iterative delivery and continuous improvement and enhancement. That shift can be quite a shock to the corporate system, especially one where fiefdoms have evolved and empires been built up. There is more to it than that, though – in particular, software delivery is not just about development any more. What our survey confirms is that the delivery which matters now is delivery to the end user, not merely to whoever commissioned the software. In practical terms, this means acknowledging and accepting that the software development lifecycle does not end when you hand over a completed application. That application then goes into production, of course, and must be maintained and continually updated over its working life. This leads on to ideas such as lifecycle integration and DevOps, which acknowledge that when it comes to delivering a service to the user, software development and operations are interdependent and should work together. In practical terms, this translates to continuous delivery, which is emerging as a key enabling concept. CD helps operations to feed back into the development cycle, and with that in mind it’s little surprise that almost all our survey respondents saw CD as important, and most saw it as very important. But to achieve CD you also need to automate – that means automating your requirements modelling, builds, testing, release, etc., and you need an efficient feedback loop. This puts a heavy emphasis on tooling, and especially on using modern, open, API-enabled tools to integrate activity across the whole lifecycle. Other recent studies we’ve carried out suggest that the best place to find – or place – these tools is in a cloud, whether public, private or hybrid. The need to bring together nominally-different methodologies to make a stronger, more effective, whole – to add two plus two and get five – was clear to our survey group. Many were implementing Agile to some extent, but most of them were also implementing it alongside CD and perhaps DevOps too. Indeed, the combination of Agile and continuous development is a particularly popular one. So Agile is very important, but by itself it isn’t a magic bullet. It can be used stand-alone, but in most cases it’s preferable to use it as part of a bigger lifecycle-oriented or continuous delivery toolkit. In much the same way, DevOps is a nice idea, but to deliver on its promise you need to get all those necessary prerequisites in place and working together. Among other things, that means getting serious about automation, integration and open software tools. To learn more about continuous delivery and the overarching framework that Agile needs to work within, download the full report from the research study. Click here to get your copy.

Content Contributors: Dale Vile & Bryan Betts