What is Slowing Down Your Agile Transformation? It Could be Your Legacy Applications
If you’ve tried an Agile Transformation yourself or with a partner, you know that every Transformation has many dimensions. You must look at an organization’s structure, project budgeting, product hierarchy, team practices, engineering practices, and much more. But what we’ve seen is that our clients can work on many of these aspects and still not experience the increased value that they were hoping to achieve.
A “fully Agile” software team can learn the new practices, be re-organized, be financed as a product instead of a project, and STILL take weeks or months to get a new feature into production. How could this be?
The problem can be embedded in the legacy software itself.
This blog post examines how this happens and what you can do about it.
Agile Transformations Need to Get into the Code
If you’re familiar with the LeadingAgile approach to Transformation, you know that we have what is probably the most comprehensive view of what an Agile Transformation entails. We have business architects reorganizing a company’s business capabilities to align with their customers and markets. We have product specialists who can connect the products produced to the business capabilities. We have organizational change specialists who can help employees switch to a more productive org structure and feel like they belong in the new world. And we have team coaches who can help instill the new team and engineering practices into each team member.
But it’s possible for a particular team to do all these types of Transformations successfully and still feel the pain of the slow introduction of features into production, sometimes measured in weeks or months. This doesn’t typically happen with teams doing “greenfield” development, where they are building something new. Instead, it happens with teams working on an existing code base that might be months or years old. In other words, legacy. In large organizations, this usually accounts for the majority of the IT staff. Many of them need to look after applications put into production a while ago and a) make sure they don’t go down and b) add new functionality as the business changes.
When you restructure your business capabilities, your products, and your teams, you can create a new structure that aligns with one another but is misaligned with how the legacy applications are structured. When this happens, the legacy apps will fight your Transformation and cause a situation where software teams must manage dependencies between teams, put work into other teams’ backlogs, wait for changes to be made, and slow down progress to a c-r-a-w-l.
So, what do you do? As it turns out, LeadingAgile has one more card up our sleeve to address this issue.
Extracting a Product; Restructuring Legacy
Some Agile consulting firms might say, “Well, just rewrite them! They’re old anyway!” But that doesn’t make economic sense in most cases. That legacy software represents an investment, and businesses need to recoup each investment by making the software last as long as possible, even if it’s limping along.
At LeadingAgile, we have a different approach. It is called “Product Extraction.” Here’s what we do:
Assess each legacy application along four axes:
- Is this app strategic to the business?
- Does this app get changed a lot?
- Is the app structured differently from how the teams are organized (now that we’ve transformed the team structure)?
- Is the app causing dependency issues between teams?
If the answer is “Yes” to all or most of these questions, we look at mitigation strategies.
Leave The Code Better Than You Found It
We use the “Campsite rule” for applications that are well-structured but need a bit of help. We coach the legacy team members to “leave the campsite a little better than you found it” regarding the code. Each time you change the code, you should add an extra automated test, refactor the code, add an interface, etc. Making these small improvements can add up over time! We’ve seen situations where code coverage for an entire application goes up from 5% to 50% just using this technique. And the tests are right where you want them—in the parts of the code where there are the most problems and the most activity.
What is Product Extraction?
Product Extraction is for apps that are still providing good business functionality and are generally maintainable but are poorly aligned to the structure of the teams (i.e., causing delays due to inter-team dependencies). In our experience, this is the situation with most legacy applications.
With Product Extraction, the team re-architects the code to match the team structure, kind of a reverse Conway’s Law (Organizations that design systems are constrained to produce designs that are copies of the communication structures of these organizations), you could say. The team pulls the code apart and puts it back together to reduce dependencies between teams and speeds features to production. We can either coach the team to do this themselves, or the LeadingAgile Studios team can take on the work, leaving the team to continue fulfilling their backlog of work. In either case, we always work with the team members to ensure that they have the skills to work with the newly structured legacy app once it is done, using our on-site technical coaches to instill those skills and practices.
Rewriting Legacy Applications
The last and most expensive option is to “Rewrite” the legacy application. There are two problems with this approach which is why we put it last in preference.
The first is that it is expensive. An entire team will need to assess the existing application and build a new one, which could take months and big money.
The second problem is that the business functionality that the legacy app provides might not be obvious and, therefore, might not be transferred to the new application. It’s easy to miss small decisions made in the legacy code that might be important for the business and might not be well-known to the software team or even its users and stakeholders. The legacy app might have outlived the people who wrote the software initially and the stakeholders who specified what it needed to do. With those people gone from the organization, or maybe the people are still there, but they’ve forgotten why they did what they did, it can be very difficult to do the detective work to understand all those decisions and the code that supports them. However, rewriting is the only alternative when the code is very difficult to maintain and/or uses an outdated platform that is expensive to maintain.
Does Product Extraction work for packaged applications? It sure does. We won’t be “restructuring” the package, to be sure. Still, we can add automated tests and interface surrounding the package to ensure that teams can operate more independently and reduce those nasty dependencies between teams.
That is the LeadingAgile Product Extraction process. We will present further blog posts to explain it further, but for now, remember that your legacy apps may be holding back your Agile Transformation in surprising ways, and there might be ways to address them in less expensive ways than rewriting old systems.
Daryl Kulak is the Principal Studio Director at LeadingAgile. He is also the co-author of the book “The Journey to Enterprise Agility: Systems Thinking and Organizational Legacy” with Dr. Hong Li (Springer International, 2017), available as a hardcover, Kindle version, and audiobook.