I have heard it asked many times, “Where do architects fit into Agile?” But that's the wrong question. Instead, you should be asking, "Is our architecture Agile-Ready?"
One reason for adopting Agile is to enable “flow” to breakout – meaning your organization accelerates moving business needs from the concept phase to delivering customer value in production. Agile, grounded in Lean principals, asks your teams to look at everything that does not contribute to “flow” as waste and to eliminate it. But what if your application architecture is holding you back?
Many applications were built and designed in an era of “big bang” waterfall engineering or started as small applications but evolved into large monolithic systems. These applications often contain many complex interworking parts and require a single large deployment to make even the slightest change. As organizations begin to adopt Agile practices, a non-Agile architecture can quickly become a critical choke point in accelerating delivery.
In Agile, one key role of an architect is to enable developers and testers to get more done while maintaining a certain level of coherence in the overall application architecture. A good architecture should allow Agile teams to quickly build small independent new features that integrate together yet are loosely coupled.
Over the years I have come across some common patterns that may indicate your architecture is holding you back:
1. Monolithic Applications
Your deployment artifact is one giant application bundle and every time you need to make even a small change you need to rebuild and deploy the entire application. This is one of the most common issues I have come across and often organizations assume the only fix is a costly and time-consuming rewrite. While this is one solution, we have had great success by breaking out small, but key, components in separate deployments. Breaking applications up into internal components or extracting a few important microservices is a great place to start.
2. Tedious Manual Regression
Every release requires a lengthy and expensive round of end-to-end manual regression testing. If your manual regression cycle is taking days or weeks to complete then going Agile will be tough. Introducing even a modest number of automated tests will make a big difference. Many organizations initially focus on automating the UI tests, but you get a bigger bang for your buck by starting with integration and unit tests.
3. No Unit Tests
This probably seems like an obvious one, and it is. However, we have found that it is one of the most common reasons teams cannot gain efficiency and speed. Despite the claims that “there is just not enough time to write unit tests,” we have found the opposite is true – if you don’t start writing unit tests now, your developers will slow down, which significantly increases your risk of defects. If you have no unit tests at all, don’t let that scare you. You will see huge gains by starting small and increasing coverage over time.
4. Cascade Effect
One seemingly small business request requires coordinated changes across multiple application layers or multiple teams. This leads to complex coordination issues, frustrated business owners, or unpredictability in how long a request will take to complete. These problems can be handled in two ways: either you can refactor your application code or create cross-functional teams that have the capabilities and knowledge to complete the entire business request.
5. Fragile Software
Every time you fix one defect something else breaks. A former client in the banking industry had a complex subroutine for handling money transfers. Nearly every production release to update or fix one problem created several new challenges. Entire releases were backed out, the organization was frustrated, and developers were afraid to touch the code. The decision was made to undertake a targeted rewrite of the subroutine, introducing excellent unit test coverage and following clean code practices. A small team of senior developers spent about three weeks on the rewrite and the results were astounding – that subroutine became the gold standard for future development practices and the change led to a (nearly) complete elimination of defects with the money transfer feature.
6. Shallow Knowledge Base
Every business request requires extensive research to figure out how to make the change. Before you adopted Agile you had specialist developers – individuals who were experts on one thing. Now, with the introduction of Sprint teams, you are finding that some teams are struggling to take on a story because they have limited knowledge of the code. We have concluded that the introduction of paired programming practices will significantly help to reduce, if not eliminate, this problem. When developers pair they are able to trade ideas and lean on each other. Not only does this reduce risk and speed up development but also shares knowledge more broadly and improves the team’s confidence going forward.
7. Poor Environment Configuration
Your “Development”, “Testing”, and “Staging” environments work differently and “environment issues” often impede your teams. This might be the single most common impediment I have heard during my 10+ years of working with Agile teams. There are many contributing factors: hardcoded environment properties, poor environment configuration, unstable or incomplete environments. To really help your Agile teams become productive, you need to treat your development and testing environments like production. Every minute an Agile team loses to “environment” issues is a minute they are not focused on solving your customer’s problems. The investment you make in an Agile team dedicated to solving these environment configuration issues will pay dividends immediately, visible through the productivity gains of the other Agile teams.
All too often when organizations fail to make progress with their Agile transformation it is because they neglected to address the underlying issues related to the application architecture. Making an existing legacy application Agile-Ready is not always easy, but even relatively small architectural changes can yield significant benefits. We have found that organizations that address architecture improvements strategically are more successful. One approach is to treat the architecture like any other Agile project, where your developers and testers are stakeholders who help inform the requirements and priorities for an architecture team. By prioritizing the high value, low effort architectural improvements first you will unleash your teams to focus on delivering value to your customers.
CirrusLabs can help you get there faster. We have years of practical hands-on experience helping companies transform their application’s architecture to help accelerate Agile delivery.
At CirrusLabs – WE GET AGILE®.