When Your Agile Orchestra Sounds More Like a Garage Band!

Picture this: You're at a music festival, and there's this incredible jam session happening on the stage. Multiple rock stars have come together to play the same song, each bringing their unique style and energy. The guitarist from one band is laying down some killer riffs, while another band’s drummer is keeping the rhythm tight, and the bassist is holding it all together. When it works, it's pure magic - the crowd goes wild, and everyone's feeding off each other's creativity. 

But here's the thing about jam sessions, they can also go spectacularly wrong. One musician starts playing in a different key, another changes the tempo without warning, and suddenly what should be harmonious turns into chaos. The audience starts heading for the exits, and you're left wondering how something with so much potential went so sideways. 

Welcome to the world of scaling Agile when your application spans multiple Agile Release Trains (ARTs). Just like our festival jam session, you've got different musicians (your ARTs) all jamming on the same song (your application), each bringing their own expertise and approach. The energy is fantastic, the ideas are flowing, and features are shipping faster than ever. But underneath all that creative momentum, there's a challenge: How do you maintain application integrity when everyone's jamming to their own beat?

This isn't just a technical problem; it's an orchestration challenge. And just like any good jam session, success comes down to having the right foundation, clear communication, and a shared understanding of how to keep the music tight while still letting everyone shine.

So, here are the seven most common problems that can turn your jam session into a cacophony, and how to avoid them and keep everyone playing in harmony.

What's the worry?  

Each ART might have its own favorite way of coding, testing, or picking software libraries. This mix-and-match can lead to messy code, hard to find bugs, and security holes because not everyone's following the same safety rules

How to fix it?

 Get your Communities of Practice (like, all the backend developers, or all the QA folks across ARTs) to agree on the basics: "Here's how we write clean code," "These are the security checks everyone must do," "Let's use this set of approved tools/libraries." Make sure these communities share tips across all ARTs

What's the worry? 

When multiple ARTs merge code into the same codebase frequently, it's easy to accidentally step on each other's toes. One ART might break something another ART built, and you might not know until users complain.

How to fix it? 

Automation is your guardian angel. Set up a CI/CD pipeline where every time someone tries to add code, it automatically checks if it builds okay, passes essential tests (unit, and especially integration), and doesn't have obvious errors. If there is the slightest problem, the code shouldn’t get in. Also, use "feature flags" - merge code even if it's not quite finished, but keep it hidden from users until it's done and tested with everything else.

What's the worry?

 Software uses building blocks from other places (libraries/dependencies). One ART might update a block, breaking something of another ART. Or worse, someone uses an old block with a known security flaw, making the whole application vulnerable. 

How to fix it? 

Have a clear system for deciding which "building blocks" are okay to use and how they get updated. Maybe a central team or a Community of Practice vets them first. And definitely use tools that automatically scan all your blocks for known security problems and yell loudly if they find one. Keep a list (a software Bill of Material) of all the ingredients you're using.

What's the worry? 

Because it's all one application, if any ART accidentally leaves a security hole in their code, it could potentially give attackers access to the whole system. 

How to fix it? 

Have something like Security Champions - folks within the ARTs who are keen on security - act as local guardians. Make security check-ups part of the routine for risky code changes. Get teams to think like potential attackers and maybe even use threat modeling to spot weak points. 

What's the worry? 

Individual pieces might work fine on their own, but do they work nicely together? Testing those interactions across features built by different ARTs is tricky and could get missed.  

How to fix it? 

You absolutely need tests that act like a real user, going through journeys that involve features from multiple ARTs (end-to-end tests). Roll out changes gradually - show the new stuff to just a small group of users first (canary release). If things look weird, roll it back before everyone sees it. 

What's the worry? 

When something inevitably goes wrong, figuring out which code change from which ART caused the issue can be a time-consuming blame game if you don't have good tracking. 

How to fix it? 

Be strict about why code was changed (for example with good commit messages), link changes back to user stories, and have really good logging. Logs should let you trace what happened during a user session, even as it jumps between parts of the application built by different ARTs.

What's the worry? 

Different ARTs managing their own settings can lead to the application behaving differently in testing versus live, causing "but it worked on my machine" headaches. 

How to fix it? 

Treat your settings like code (configuration as code). Store them centrally, manage them with version control, and apply them automatically. Make sure everyone is working with the same consistent configuration. 

Here's the thing about great jam sessions: they don't happen by accident. The best musicians know when to step forward for a solo and when to step back and support the rhythm section. They listen to each other, they respect the song's structure, and they have enough shared musical language to improvise together without losing the thread. 

Your ARTs need to operate the same way. Give them the freedom to innovate and own their pieces, but make sure they're all working from the same sheet music when it comes to the fundamentals - your coding standards, your security practices, lots of automation to catch mistakes early, ways to test how everything works together, and your deployment processes. 

The beauty of this approach is that you're not killing the creative energy which makes the Agile way of working effective and fun. You're just making sure that when your ARTs jam together, they create something beautiful instead of chaos. Your application stays solid, your users stay happy, and your teams can keep pushing boundaries without worrying about bringing down the house. 

Remember, a great jam needs both creative freedom and structural integrity. Get that balance right, and your cross-ART application won't just work - it'll sing.

Contact our Highberg Senior Consultant Davar Azarmi.