Een agile transformatie. Wat betekent dat voor architecten?

Inspect & adapt is één van de kerngedachtes van agile

We kijken terug op de manier waarop we hebben gewerkt en op het resultaat. De lessen die we daaruit leren gebruiken we om beter te worden. Kunnen we dat ook op een hoog niveau doen, over teams en organisaties heen? 

In deze serie interviews onderzoeken we wat we kunnen leren van mensen die hun sporen hebben verdiend in Agile transformaties. Ben Kooistra, agile coach en trainer bij Capgemini, staat in dit interview centraal. 

Waarom Ben? Hij werkt ruim 40 jaar in de ICT, waar hij verschillende rollen vervulde, waaronder die van architect. Hij startte in het beheer, zette een integrated development environment op. Kwam in contact met maturity modellen zoals CMM, CMMI, COBIT, stond aan de wieg van het IAF bij Capgemini en werkt nu met SAFe. Ben heeft een passie voor kwaliteit: het meten, verbeteren, ondersteunen en coachen zit in zijn genen. ‘Continuous improvement’ is hem op het lijf geschreven. 

Ben deelt een aantal inzichten, bijvoorbeeld: de architect van nu is minder voorschrijvend en meer oplossingsgericht: hij denkt mee met de scrum teams. Dat vraagt een dienende en coachende houding met vaardigheden als luisteren, doorvragen, uitleggen, overtuigen. En: governance krijgt niet de aandacht die het verdient, met alle gevolgen voor veiligheid en kwaliteit. Hij ervaart dat SAFe veel handvatten biedt om governance over agile in te richten. Meer weten? Lees hieronder verder! 

Scrum-teams leveren zelfstandig een oplossing, die waarde toevoegt voor de business. Wat is de rol van een architect daarin?

Agile vraagt een mindset verandering van alle betrokkenen. Agile zijn is bestendiger dan agile doen. Dat geldt ook voor de architect en dat is niet altijd eenvoudig. Een organisatie begint met scrum en scrum-teams, als eerste interpretatie van agile in een IT-delivery organisatie. Laten we nu maar lekker gaan scrummen, dan kunnen we snel aanpassingen doorvoeren en onze gebruikers tevreden stellen! Maar op het moment dat je 30 teams hebt, heb je een andere uitdaging. Als die 30 teams hun eigen oplossingen bedenken, wordt het vanzelf chaos. Dan heb ik het nog niet over het ontbreken van aandacht voor security en beveiliging. Dat wordt in die chaos verder onderbelicht, met alle kansen voor hackers. Daar zit een rol voor de architect: structuur brengen en chaos voorkomen. Architectuur is een belangrijke discipline, zeker ook in een agile context en ik vind dat zwaar onderbelicht in veel organisaties. 

Na de start met agile werken krijg je de doorontwikkeling naar DevOps. Het team is verantwoordelijk voor het ontwerpen, realiseren èn het in beheer nemen van de functionaliteit. Dat is een goede ontwikkeling. Je ziet de laatste tijd dat DevSecOps en ook BusDevSecOps in opkomst is. Je begint bij de business, je hebt je development discipline, je hebt je security meegenomen en je hebt je operatie. Dat pak je allemaal samen in dat ene team, dat verantwoordelijk is voor het hele plaatje.

In veel organisaties komen beheerders en architecten in de knel, omdat ze onderdeel moeten zijn van 5 of meer scrum teams. 

Dat komt omdat ze de traditionele beheerdiscipline en architectuurdiscipline in stand houden. Die plakken ze tegen de ontwikkelorganisatie aan, die inmiddels bestaat uit veel scrum-teams. Dus je hebt een club architecten en die moeten dan ineens al die verschillende teams gaan helpen, coachen en begeleiden. Dat kan dus niet! 

De developers zijn fulltime bezig met hun werk en zeggen: de architect heb ik maar even nodig. Het is niet nodig dat een architect fulltime in een team zit, omdat hij er niet een volle taak heeft.

Als architect moet je denken: ‘Wil ik de verantwoordelijkheid hebben om aan het resultaat van het team bij te dragen, committeer ik me aan de doelstellingen van de sprints?’ Zo ja, dan moet je die tijd ook vrij maken en dan ben je onderdeel van het team. Dat is een bewuste keus. Je zit dan als architect in maximaal 2 teams omdat je daarnaast je architectuur taken moet uitvoeren.  

Als je dat niet kunt of wilt, dan maak je afspraken met de teams die je begeleidt. Je bent op afspraak en afroep bij stand-ups, bij refinements, demo’s, planningen. Je committeert je dan op een andere manier aan de teams, waardoor het je minder tijd kost en je meer teams kunt begeleiden. Maximaal 3 of 4 teams, afhankelijk van de volwassenheid van de teams. Dat brengt direct met zich mee dat je het team vertrouwt en dat je ze loslaat. Maar je houdt wel de vinger aan de pols vanuit de bovenliggende architectuur waar je verantwoordelijk voor bent.

Wat is jouw werkwijze?

  Ik maak gebruik van de dynamiek en de mechanismes die in SAFe zitten. De drie lagen: teams, systems, solutions en uiteindelijk het portfolio. Dat is de manier om je als ook als architect te profileren. Je bent dus system architect, solution architect of je bent enterprise domain architect. Je maakt je rol specifiek.  Dat is een grote uitdaging voor traditionele architecten, zij zijn dat niet gewend. Zij zijn gericht op een domein: infrastructuur, business processen of een onderdeel van het applicatielandschap. Zij stellen daarvoor een specifieke architectuur op en schrijven dat voor aan de teams. En dat is anti-agile. 

Je moet als architect dienend zijn, loslaten, het laten ontstaan en dat is absoluut een mindset-change.

Wat moet je loslaten?

Het opleveren van traditionele architectuurproducten en documenten: modellen, views, richtlijnen, de standaards, de keuzes. Dat staat op een te grote afstand van waar de teams dagelijks mee bezig zijn en mee worstelen. 

Draai het om en geef de teams de ruimte om zelf in eerste instantie een architectuur op te stellen. Want het agile team is verantwoordelijk voor de architectuur van de oplossing die zij bieden. 

Dus: geef het team de ruimte om zelf een architectuur op te stellen. Maar een architect denkt: dat is mijn taak. Er kan een conflict ontstaan met de architectuur die de architect zelf heeft bedacht. 

De architect moet in staat zijn om de architectuur die hij bedacht heeft, even te laten voor wat het is. Op het moment dat hij de eerste resultaten vanuit de teams krijgt, spiegelt hij deze aan de ideeën die hij al had over de bovenliggende architectuur en kijkt of het past. Om dat te stimuleren stel je samen met het de teams een agile startarchitectuur op voor de teams die samen werken aan het systeem of een oplossing.  De agile startarchitectuur is een levend document. 

Het is niet meer dan een A4-tje met wat pointers: hier kun je dit vinden, daar kun je dat vinden, let hier op, let daarop. Niet om het aan het team op te leggen, maar om het ze mee te geven: ‘Het is nog niet helemaal uitgewerkt, dat mogen jullie doen. En houd rekening met deze standaarden en principes.’ Als het team zich daaraan kan confirmeren, is het goed. En als het team ermee worstelt, heb je iets om samen te bespreken. Het is een communicatiemiddel, het hoeft niet helemaal af te zijn. Vaak wil de architect dat de architectuur helemaal af is voor de developers er mee mogen werken, zoals de building permits en de controle in verschillende architecture boards. Dat laat je los. Niet om het niet meer te doen, maar om het op een andere manier te doen. Je houdt de controle met respect voor en vertrouwen in de teams. Het team moet ook ervaren dat ze jou kunnen vertrouwen, dat je meedenkt en oplossingen met hen zoekt. Dat is een erg belangrijke verbetering, die je vanuit de mindset-change in een organisatie teweeg moet brengen.  

Dat betekent ook dat de architect het gesprek goed moet kunnen voeren, moet kunnen luisteren, coachen, uitleggen, overtuigen. En bereid moet zijn oplossingen te vinden, samen met het team.

Stel dat het ene team de ene kant op wil, en het andere team de architectuur in een andere richting wil aanpassen?

Dan kom je bij de system architect, die verantwoordelijk is voor de structuur en architectuur van het systeem. Die moet kijken of het past. ‘Sta ik het toe of moet ik het team bijsturen?’  Dat vraagt afstemming tussen de agile architect en de scrum teams die er samen voor zorgen dat het systeem werkt.

Je noemde SAFe, dat goede handvatten geeft aan de architect.

Ik noem SAFe ook wel het Governance of agile Framework. Je kunt met SAFe de agile discipline op alle lagen in een organisatie positioneren. Je kunt de juiste dingen inrichten vanuit een governance optiek: hoe krijg ik control over agile? Wordt het geld doelmatig besteed? Daar geeft SAFe veel concrete handvatten en voorbeelden voor.  Je kunt processen inrichten, sturen, monitoren en verbeteren. Je zet governance in om te zorgen dat de organisatie in goede banen blijft. Met SAFe kun je het operating model zodanig herinrichten, dat de organisatie wendbaar (agile) wordt en nog beter aan haar business doelstellingen kan voldoen.  

Veel organisaties die agile willen worden, realiseren zich onvoldoende dat het om een transformatie gaat, een ontdekkingstocht, die zich niet laat uitstippelen en waarvan cultuur, mindset en vaardigheden een belangrijk onderdeel zijn. En geen transitie van een oude situatie naar een bekende, nieuwe werkwijze. Dan wordt het agile doen, en niet agile zijn.

Benieuwd naar onze Agile trainingen?

Of heb je vragen over dit vakgebied of één van onze trainingen? Neem gerust contact met ons op. We helpen je graag!