If there’s a silver lining to the COVID-19 pandemic, it may be the spike in innovation that has resulted. Spurred by urgent customer needs, companies are breaking traditional bureaucratic procedures and expediting delivery of essential products and services.
How can companies maintain this agility when the crisis is over? By making the business system – the thing that connects an organization’s many parts to achieve a common purpose – more agile. And the best way to create an agile business system is to build it using agile methods. That requires engaging people in testing, learning, and adapting through every innovation process.
Why agile goes wrong
We see many agile software development teams, but few agile IT organizations. Most simply can’t keep up with rapidly changing customer expectations and the demand for digital innovation.
[ What's missing from your agile conversion? Read What not to say to agile teams. ]
There are at least two reasons for this. First, many business leaders think of agile software development as something that can live solely within the four walls of the IT department – they don’t understand that the business system must be built around the critical roles played by other parts of the company.
Agile systems require the involvement of product managers from the business functions the software serves. They rely on planning and budgeting that empowers agile teams to base their work on customer value rather than predetermined project deliverables. And they benefit from human resources policies that help attract and motivate top engineering talent.
An agile success story
When agile software development teams work in concert with other parts of their organization, the results can be powerful. For example, in 2017, the Royal Bank of Scotland launched a project to digitize and improve its mortgage application, a paper process averaging 66 pages in length.
One of the major stumbling blocks was inflexible technology. Creating a cross-functional agile team that worked in two-week sprints, the bank was able to work through many different obstacles, including critical changes in a range of systems.
Working alongside designers conducting customer research, operations and customer service experts, process experts, and others, software engineers wrote the essential code, assisted by data engineers and data analysts. Instead of specifying features in advance, the team sought customer feedback on each iteration of the product, building and improving it based on that input.
In the end, the bank was able to launch the UK’s first paperless mortgage application while also improving customer satisfaction and growing its business. The average application-to-offer time dropped from 23 days to 11 days.
After proving and refining their model with a few teams, RBS gradually rolled out agile teams to more and more parts of the IT organization. The bank recognized how this agile approach helped the company avoid the risks it would have run standing up large numbers of teams at once with an untested model.
Monolithic vs. microservices
Another reason many IT organizations are not agile is they underinvested in the necessary assets, including modular architecture, automation, and engineering skills. Improving architecture particularly benefits from an agile approach, but a lack of agile thinking often stands in the way.
Arguably, the biggest obstacle to agility in technology departments today is poor architecture. Instead of modern, modular architectures, many IT systems still use tightly coupled, monolithic architectures that limit their speed and ability to change. In monolithic architectures, changing one component means you must also change others. When teams implement new features, they bump into each other’s work. Because components are dependent on one another, changing one part of the system often requires full regression testing, which further slows delivery.
This problem can be so complex and overwhelming that IT departments feel they must decide between doing nothing or doing everything in one big bang. A big bang cutover to a new system may sound preferable, but keep in mind that changing one piece of software affects others in unexpected ways. This path can require years of design, construction, and expensive testing. It’s not agile.
A better approach to modernizing a monolithic architecture uses agile principles: stepwise change, guided by business value. An increasingly popular version of this approach involves moving incrementally to microservices. Microservices are self-contained, loosely coupled components that can be modified, tested, and deployed independently of the systems that use them.
When migrating from monolithic to modular microservices, the first step is to identify where you can unlock business value by separating a component from the monolith. These are generally found in the areas where teams collide most often, or in areas that change most often or that are fragile or unstable.
[ Also read: How to make the case for microservices ]
Next, the team must figure out which components are easiest to separate from the monolith. Once they’ve determined that, they should work in small increments, sometimes prioritized with the help of software intelligence tools. Microservices are usually organized by customer experience or business capability rather than by stack layer. Creating them requires cross-functional skills since a business capability might cross several silos, as redesigning RBS’s mortgage application process did.
As RBS discovered, creating an agile business system using agile methods can enable your team to deliver new technological capabilities more effectively, and help accelerate the evolution of the entire organization.
When the COVID crisis has passed, organizations that have built an agile business system will have the flexibility, speed, and decision-making skills to thrive, whatever the future looks like.
[ Culture change is the hardest part of digital transformation. Get the digital transformation eBook: Teaching an elephant to dance. ]
