Today I had the honor to be the keynote speaker at the British Computer Society conference. The presentation is here and the following is the text that supports the presentation.

Application development is at the heart of many businesses – for companies that develop their own applications, getting updates out to the business faster is a necessary part of being competitive. How the various processes involved with application development and delivery are managed can therefore have an impact on the success of the organisation as a whole.

New development methodologies like scrum, agile and kanban are being taken up by developers in response to increases in business demand for applications. Instead of traditional waterfall approaches, these methods focus on continuous improvement and helping developers to be more productive. Rather than large development projects being delivered every six months, agile software development has releases going out far more frequently – releases can be going out every month, or even weekly.

This approach benefits the developers as they can see results from their work far more quickly. The business benefits as in theory it gets better quality software faster and that meets its needs as they evolve. However, this change in dynamic can have unforeseen consequences for other parts of the application delivery chain, and across the business as a whole.

Unintended consequences

The biggest example of this is around change management and release management. As agile development increases the number of releases and updates produced, so the number of individual changes that a development team creates goes up too. The volume of releases that has to be delivered out to the business increases as well.

For most companies, release management still tends to be a manual process. This flood of new updates from development does not necessarily bring with it extra funding, so it means more hectic schedules for the release management team, more to manage and more opportunity for things to go wrong.

Why is this bad news for developers? Because the business does not see the work involved in the development of the application, but instead sees the result of that work. If the release of software out to the business goes wrong, then the end result is that the effort put in by the development does not result in benefit for end-users. It also then requires more costly clean-up to take place and put things right.

Similarly, change management is affected by the influx of new development models. For regulated industries like manufacturing, defence and finance, any change to code has to be approved and linked back to business authorisation.

When a release comes through every six months or so, the sign-off and tracking side of things is relatively easy. However, if agile is taken on in these environments, then the number of changes that have to follow the audit and sign-off side of things will go up considerably. The end result for the business is of the organisation is either more complicated processes or the development of a whole new way of working onto business managers.

These industries tend to be slow-moving, so agile is only just starting to make inroads into the development teams that are working for these companies. What is stopping agile from being used more widely is that the overall processes and best practices for managing the interaction between the development team and the business are still being worked on. As part of evaluating these new development practices, the cost implications of maintaining proper change management controls have to be considered against the undoubted productivity gains that can be achieved based on new development methods.

Avoiding roadblocks

As part of this overall change in development, managing change management and release management properly requires the automation of more processes. Rather than relying on manual work to hand over between steps in the process of delivering software, these links can be automated to speed things up.

This approach breaks down into two areas: first, understanding what tools and services are already being used by the business and application teams as part of managing the development process. The second is to get a good overview of what the business process for development currently is. The ultimate aim is to marry these two sections together so that the tools, technology and processes all work together, rather than against each other.

What is important to understand is that your existing tools should feed into this automation work – at no point should this be a ‘rip and replace’ exercise. Organisations have too much invested in their current IT to make this a worthwhile exercise, and the potential costs far outweight the value that would be generated. Instead, enterprises should look at how they can orchestrate their existing tools to close the gaps between parts of the development process.

At the same time, this bridging of gaps should also address the business process that goes alongside the tools that developers use. The best examples of where these schisms currently exist are between the business and the development side around demand for application updates and changes, and the release of those changes back into the business.

Again, the process for feeding change requests into the development team is often manual and intensive for both the development and business sides. To automate and streamline this involves looking at the process for how change requests are evaluated and put through, and what information can be taken out of these tools. This data can then be put into a workflow that sends it over to the next link in the software development chain in the right format to appear within the tools that they are using.

As agile or scrum is taken up within the development team, the process for feeding back change requests or sign-offs would be treated in the same way – data would run through the automated workflow and be in a form that suits the recipient, rather than requiring them to work on it. By taking this approach, the enterprise can orchestrate its overall processes and pull them together within the context of the whole application life-cycle.

The history of IT is littered with projects where the intentions were good, but the results that were delivered did not meet expectations due to unforeseen consequences. For application development, the impact of new development methods should have a real business benefit for the organisation, but without the right degree of thinking around the complete business process, these can be lost due to other issues. Companies must evaluate the whole process that exists around areas such as application development, and then apply automation and orchestration to see the best return on their efforts.