How legacy applications can thrive in an agile world

Legacy applications come not only with legacy code and architecture, but often with legacy delivery, maintenance and support practices too.

Breathing new life into how these applications are developed and supported can result in big savings as well as dramatic improvements in delivery agility.

A case in point

One of our government clients found itself in this situation – it had a suite of legacy applications that were costing a lot of money to maintain and were slow to change. The customer experience wasn’t where it needed to be, and the part of the organisation concerned with the apps was used to just a couple of releases a year. Factor in the premium of outsourced development and support costs, and the increased complexity involved in using this model, and our client understandably wanted to realise a new future for the apps in question.

As Equal Experts was already moving these applications to the cloud, we were asked by our client to propose a solution that would allow them to insource the development, maintenance and support of these applications well into the future. The goals:

• Greatly reduced cost;
• Dramatically increased delivery agility (from releasing a few times a year to multiple times a day);
• Complete removal of supplier dependency – putting the client in control from end to end.

A complex environment

Breathing an agile (and cost effective) life into these legacy applications would require a number of key delivery transformations, each designed to reduce complexity, cost and time to market. Plenty of change was required as to date, the delivery of our client’s applications had depended on an array of unique teams, working within a complex and fragmented delivery structure:

• Subject matter experts owned the future vision of the services, but didn’t own the operability or bug-fix backlog, nor a direct relationship with the delivery teams;
• A support team supported the services and managed the wish list of bug fix and operability improvement changes, but had no power to implement either;
• A development team developed and maintained the services, but did not own backlog delivery priorities, nor could they sign off their work as ready for live or deploy it into production;
• A change board governed how and when deploys would take place;
• A final team tested and released the services into production, but didn’t have the full context needed to fully understand the changes that were being tested and released.

All of the above resulted in a complicated process to handle all the handoffs between the teams, and a huge array of documentation. The solution to each problem was the same, however: bringing the disparate parts of the wider team together was vital to simplify processes and empower change.

Moving to service team ownership: you build it, you own it

Equal Experts recommended and implemented a unified Service Team model that we were confident would greatly reduce these dependencies and handoffs and vastly simplify the delivery process – while dramatically increasing the unified team’s sense of ownership:

• Product Owners were moved into the delivery team and made priority decisions based on the full context of everything affecting their service (from bugs, to required operability performance and security improvements, and needed business change);
• The support function as an independent entity was removed, with support becoming part of the team’s overall responsibility. They developed and supported their service, and became masters of monitoring, alerting, customer issue deep-diving, and issue resolution. Support investigations that proved the need for change were added to the centralised backlog and prioritised against all other changes;
• The external test, release and change board teams’ remits were reduced, so that they added real value when needed, and were not used when not. The Product Owners were empowered to decide which changes needed integration testing and which needed to go through change board. Consequently, most changes that didn’t affect 3rd party services could now go live as soon as the service team agreed they were ready;
• The service team was empowered to deploy into production, enabling a gradual ramp up to multiple deploys a day;
• Quality became a whole team concern, rather than something the external test team had to worry about. The service team owned all measures of quality – functional, performance, security, usability – and began implementing the test pyramid into the legacy code and architecture. POs worked with the BAs to speak the same language as everyone within the team, writing stories in behaviour-driven development language (which fed right through to the automated test suite).

As these changes were implemented incrementally over time, the team built up to being able to confidently release changes multiple times a day, and the client became confident that this was safe and appropriate for the end users. Customer satisfaction went up and big bang deploys became a thing of the past. The client saved literally millions each year, and unnecessary paperwork and complexity was avoided altogether.

Lessons learned? Be patient.

The changes I’ve described above were (and continue to be) made gradually. Lessons were learned and pivots were taken. Time was allowed to learn and improve; significant effort was taken to foster a culture of knowledge sharing and constant learning and improvement.

Many Developers, Scrum Masters and QAs need time to adapt
We built our service teams with independent contractors from multiple suppliers, alongside junior permanent client team members. We found that in such an environment, it’s hard to build a team in which everyone quickly adopts a service ownership mentality, or has experience of owning a service. Teams need time to develop appreciation for the importance and demands of service ownership, and the amount of time that it takes away from doing standard development and testing activities.

Refactoring legacy apps to fully support agile delivery takes time
Legacy apps, especially those that are not test-driven, take time to refactor in order to retrofit unit tests and effective logging and alerting. Especially to a team new to working with those apps! We found that starting with a suitable level of outside-in tests, that covered core functionality, helped us better understand the apps as well as have greater confidence in changing them. We then started to write unit tests and refactor at a lower level, as well as adding contract tests between services, reducing the need for end-to-end testing.

Empowered POs and supporting wider processes need time to evolve
It takes time for a large organisation to move toward supporting autonomous delivery service teams and fully empowered POs. Patience is needed, along with conversations across the business, to help instill an effective approach that works into the rest of the business (whilst also enabling a culture of change within the service team).

Visualise your objectives and align regularly
A lot of work goes into building a new delivery culture, especially when it’s done alongside everyday development and delivery (as this client engagement was). This takes careful planning and consideration, and on our journey, we found regular sharing of focus, direction and progress essential. I captured our learnings around delivery visualisation in an earlier four part blog series.

Favour team-driven agility over a detailed set of practices
These legacy services came with the legacy of detailed ITIL service management practices that, once the team changes had been implemented, were no longer necessary. We removed these in favour of seeing all change (be that new features, operability improvements, or bug fixes) as simply a description of a change to be implemented. We captured all of these in a centralised feature backlog, using BDD to describe the intended change. We found this to be effective and simple.

If the success of this programme has proven anything, though, it’s that your legacy could have a bright future.