When I do agile coaching for our clients, I hear a lot of Yesbuts. That’s when I say something that agile teams are supposed to do (like short iterations or frequent releases), and the client says «Yes, but…»

There are always lots of reasons (or excuses) why a client won’t buy into agile principles right away, and a legacy architecture is one of the most common given. «Agile works great for teams working on a new product, where they can design it right from the start, but we’ve got this awful legacy system to deal with.»

Awful legacy systems are the fall-back excuse that developers (including myself) often use for anything we don’t want to do or are scared to try. But there is some truth to the notion that your system architecture can hurt your ability to become more agile. Here are 6 ways it can hold you back…

1. Complicated deployment processes

If it’s hard to deploy your code, then you are going to be reluctant to deploy very often. One of our clients has had very haphazard deployment of some legacy PHP code in the past. Individual files were updated on the server outside of source control, database scripts are run on production but not logged in a central place, and everyone is nervous to do a large deployment to that site because they are not sure what will be overwritten. Recent work by their team and ours has made deployments less complicated and risky by putting all database scripts into source control, cleaning up the code repository, and scripting the deployment process.

2. Lots of fragile integration points

An architecture that is based on many disparate systems can be great in theory, especially if it’s based on well defined web services or API’s. But often a legacy system’s integration points end up deteriorating over time to be fragile, undocumented, and hacked, with too much business logic spanning across the integration points. This will make it hard for you to change any part of that business logic without also having to change multiple other parts of your system. The more you have to change at once, the more complicated that deployment will be, the more testing is needed, and the longer it is going to be before you deploy that change.

3. Complicated regression testing

What does your regression testing plan look like? If the answer is it’s all in your test lead’s head, then that will likely hurt your agility. Your architecture needs to be easily deployed to multiple test environments, ideally it should be automated, and you should be able to easily regression test that system functionality in each environment.

4. Large amounts of technical debt that are ignored

Every legacy system has technical debt, that’s not necessarily a problem. The problem is if you never do anything about it. All of the problems described above, and any other technical debt you have, can be addressed in small chunks, one piece at a time. Build technical debt into your backlog and sprints, and make sure that you keep improving the system over time. If you don’t, the burden of that debt will only get worse over time, and you will continue to push back a move to more agile software development.

Ok, not exactly architecture, but equally important…

The last two reasons are not exactly an architecture issue, but they are often the side effect of how your organize your teams in response to your architecture…

5. Teams silo’d around application layers

Let’s assume you have a typical 3 tier system architecture: Web front end, a web services layer, and a database layer. If your teams are broken into the same three silos, then you are hurting your ability to be more agile. Agile teams are organized instead around feature verticals, and they have all the skill sets they need to work on that feature of the site.

6. Full stack testing done by a single team

If your system is large enough that you have multiple teams on it, then you might be tempted to have a separate testing team which does the system-wide testing across those teams. This is likely to discourage teams from owning the quality of their work and not think about system wide implications. Specialized testing teams will almost certainly reduce quality (conversely to what you expect), or at least drastically increase the time to deployment. It’s much better to incorporate testing into each team and their day to day work.

Don’t let these reasons hold you back!

I’ve been careful to say that these 6 reasons all hurt your ability to become more agile. But they don’t prevent you from taking on agile methods. If you wait until the conditions are perfect to take on an agile transformation, you’ll never do it. I know this because I have had some potential clients call me every year and tell me «we’re not quite ready, we’ll do it next year.» Those customers have missed out on years of missed improvement opportunities.

Be aware that these things will hurt you, but use that as inspiration to try and fix these underlying architectural problems … not as an excuse to sweep them back under the rug.