Stel je dit voor: je bent op een muziekfestival en er vindt een geweldige jamsessie plaats op het podium. Meerdere rocksterren spelen samen hetzelfde nummer, ieder met hun eigen stijl en energie. De gitarist van de ene band speelt fantastische riffs, terwijl de drummer van een andere band het ritme strak houdt en de bassist alles bij elkaar brengt. Als het werkt, is het pure magie – het publiek gaat uit z’n dak en iedereen voedt elkaars creativiteit.
Maar het probleem met jamsessies is: ze kunnen ook compleet de mist in gaan. De ene muzikant speelt ineens in een andere toonsoort, een ander verandert het tempo zonder waarschuwing, en wat harmonieus had moeten zijn, verandert in complete chaos. Het publiek druipt af en jij vraagt je af hoe iets met zoveel potentie zo fout kon gaan.
Welkom in de wereld van het schalen van Agile wanneer je applicatie meerdere Agile Release Trains (ARTs) overstijgt. Net als bij die festival-jamsessie heb je verschillende muzikanten (je ARTs) die allemaal op hetzelfde nummer (je applicatie) aan het jammen zijn, elk met hun eigen expertise en aanpak. De energie is geweldig, ideeën stromen binnen en features worden sneller dan ooit opgeleverd. Maar onder al dat creatieve momentum schuilt een uitdaging: hoe behoud je de integriteit van je applicatie als iedereen op z’n eigen beat speelt?
Dit is niet alleen een technisch probleem; het is een orkestratie-uitdaging. En net als bij een goede jamsessie draait succes om een stevige basis, duidelijke communicatie en gedeeld begrip van hoe je de muziek strak houdt, terwijl iedereen de ruimte krijgt om te schitteren.
Hier zijn de zeven meest voorkomende problemen die je jamsessie kunnen veranderen in een kakofonie – en hoe je ze voorkomt om iedereen in harmonie te laten spelen.
Probleem 1: “Iedereen doet het op zijn eigen manier”
Wat is het risico?
Elke ART kan zijn eigen manier hebben van coderen, testen of het kiezen van softwarebibliotheken. Deze mix leidt tot rommelige code, moeilijk vindbare bugs en beveiligingslekken omdat niet iedereen dezelfde veiligheidsregels volgt.
Oplossing:
Zorg dat je Communities of Practice (bijvoorbeeld alle backend developers of QA’ers over ARTs heen) het eens zijn over de basis: “Zo schrijven wij schone code”, “Dit zijn de verplichte security checks”, “We gebruiken deze goedgekeurde tools/bibliotheken.” Laat deze communities actief kennis delen tussen de ARTs.
Probleem 2: “Oeps, we hebben je spullen kapotgemaakt”
Wat is het risico?
Als meerdere ARTs voortdurend code integreren in dezelfde codebase, kunnen ze elkaar onbedoeld in de weg zitten. Eén ART kan iets breken van een andere ART – en je komt er pas achter als gebruikers klagen.
Oplossing:
Automatisering is je redder. Zet een CI/CD-pijplijn op waarin elke codewijziging automatisch wordt getest op bouwbaarheid, unit- én integratietests doorstaat, en geen fouten bevat. Gebruik feature flags zodat je onafgewerkte code veilig kunt integreren, maar verbergen tot het volledig getest is.
Probleem 3: “Welke versie gebruiken we eigenlijk?!” (Dependencies)
Wat is het risico?
Software gebruikt bouwstenen (libraries/dependencies). Eén ART kan een blokje updaten dat iets anders breekt. Of erger nog: iemand gebruikt een verouderd blok met een bekend beveiligingsprobleem.
Oplossing:
Zorg voor een duidelijk systeem waarin bepaald wordt welke ‘bouwstenen’ gebruikt mogen worden en hoe updates plaatsvinden. Laat een centraal team of Community of Practice deze beoordelen. Gebruik tools die alle libraries automatisch scannen op bekende kwetsbaarheden. Houd een lijst bij (een Software Bill of Materials) van alles wat je gebruikt.
Probleem 4: “Eén gat maakt het schip lek”
Wat is het risico?
Omdat het één applicatie is, kan een beveiligingslek in de code van één ART het hele systeem kwetsbaar maken.
Oplossing:
Stel Security Champions aan binnen elke ART – mensen met een passie voor beveiliging die als lokale bewakers fungeren. Maak security-checks standaard bij risicovolle wijzigingen. Laat teams denken als aanvallers en pas threat modeling toe om zwakke plekken op te sporen.
Probleem 5: “Hebben we het wel samen getest?”
Wat is het risico?
De losse onderdelen werken misschien goed, maar werkt het geheel ook? Samenwerking tussen features van verschillende ARTs wordt vaak onvoldoende getest.
Oplossing:
Zorg voor end-to-end tests die een echte gebruikersreis simuleren, waarbij meerdere ART-features samenkomen. Gebruik canary releases – laat een kleine groep gebruikers nieuwe features eerst zien. Draai terug als er iets misgaat vóórdat iedereen het ziet.
Probleem 6: “Wie heeft dit kapotgemaakt?”
Wat is het risico?
Als er iets misgaat, is het lastig te achterhalen welke codewijziging van welke ART het probleem veroorzaakte.
Oplossing:
Wees strikt over het waarom van een codewijziging (goede commit messages!), koppel wijzigingen aan user stories, en zorg voor uitstekende logging. Logboeken moeten een gebruikerssessie kunnen volgen – ook als die heen en weer springt tussen verschillende onderdelen van de applicatie.
Probleem 7: “Instellingen overal en nergens”
Wat is het risico?
Als ARTs hun eigen configuraties beheren, kan je app zich anders gedragen in test dan in productie – het bekende “maar op mijn laptop werkte het!”
Oplossing:
Behandel configuraties als code (configuration as code). Beheer ze centraal, onder versiebeheer, en pas ze automatisch toe. Zorg dat iedereen met dezelfde instellingen werkt.
Het punt met geweldige jamsessies is: ze ontstaan niet zomaar. De beste muzikanten weten wanneer ze moeten soleren en wanneer ze de ritmesectie moeten ondersteunen. Ze luisteren naar elkaar, respecteren de structuur van het nummer en delen genoeg muzikale taal om samen te improviseren zonder de draad kwijt te raken.
Je ARTs moeten op dezelfde manier opereren. Geef ze de vrijheid om te innoveren en eigenaarschap te voelen over hun onderdelen, maar zorg ervoor dat ze allemaal dezelfde bladmuziek volgen voor de basis: je codestandaarden, je securitypraktijken, veel automatisering om fouten vroeg op te sporen, manieren om alles als geheel te testen en een robuust deploymentproces.
Het mooie hiervan is: je onderdrukt niet de creatieve energie die Agile zo effectief én leuk maakt. Je zorgt er gewoon voor dat wanneer je ARTs samen jammen, ze iets moois creëren in plaats van chaos. Je applicatie blijft solide, je gebruikers blijven tevreden en je teams kunnen grenzen verleggen zonder het huis te laten instorten.
Onthoud: een goede jam vereist zowel creatieve vrijheid als structurele integriteit. Krijg je die balans goed, dan doet je cross-ART applicatie niet alleen wat ‘ie moet – hij zingt.
Wil je meer weten?
Neem contact op met Highberg Senior Consultant Davar Azarmi.
