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