Als architect heb je wellicht de neiging om alles vooraf uit te denken. Dit lijkt haaks te staan op de agile methode. Toch kan je wel degelijk ‘agile werken onder architectuur’. De vraag is alleen, hoe haal je het beste uit de twee werelden (agile werken onder architectuur)? En hoe treed je als architect op in een agile team? In deze blog geef ik je 5 do’s die je helpen je rol als architect binnen of buiten een agile team uit te voeren.
Agile begint in steeds meer organisaties zijn weg te vinden, net als het werken onder architectuur. Agile werken probeert met korte stapjes steeds meer waarde toe te voegen. Maar lijkt als nadeel te hebben dat overzicht en structuur ontbreken. Werken onder architectuur heeft de neiging om zich te evolueren tot een groot en allesomvattend documentatie-project, en daarmee een logge tool waarmee onvoldoende snelheid wordt behaald. Mensen hebben immers de neiging gestructureerd te willen werken, met als gevolg om alles vooraf uit te denken. Maar dit is vrijwel onmogelijk als het project groter uitvalt. Agile werken en werken onder architectuur hoeven elkaar niet in de weg te zitten, sterker nog ze moeten elkaar helpen om tot goede en onderhoudbare software te komen. Daarom deze tips voor de architect.
1 Kijk naar de toekomst vanuit de agile praktijk
De product-owner (PO) zorgt ervoor dat zijn product-backlog is uitgewerkt, maar hoe verder naar de toekomst hoe minder de items zijn uitgewerkt. Als architect moet je met de PO sparren over de backlog-items. Zodoende krijg je inzicht in de ontwikkelingen en ben je in staat keuzes te maken over de inzet van (standaard)componenten of ontwikkelpatronen op basis van principes, richtlijnen en afspraken. Daarnaast heb je als onderdeel van het team inzicht in de technische achterstand. Het is niet vanzelfsprekend dat de PO hiervoor aandacht heeft, doorgaans is hij afkomstig vanuit de business en zal een functionele focus hebben. Door nauw samen te werken met de PO kun je de technische achterstand bespreekbaar maken en laten opnemen op de product-backlog.
2 Schets (lean) kaders
Als architect in een agile-team sta je met één been in het team en met het andere been in de Enterprise Architectuur. Soms zorgt dit voor een onmogelijke spagaat. Door de principes te vertalen naar kaders voor je team(s), ten behoeve van concrete sturing, is het mogelijk om het team in de pas te laten lopen met de bedrijfskoers. Maar onthoud, lezen is als ontwikkelaar niet leuk, code schrijven wel, houdt de architectuur dus zo lean en mean mogelijk.
3 Ondersteun het team
Als architect hoef je niet bovenop het team te zitten, je moet ze dingen uit laten zoeken zodat hun werk nooit saai wordt. Maar wanneer ze inhoudelijk vastlopen moet je er als sparringspartner voor ze zijn. Belemmeringen op proces niveau worden door het team in overleg met de SCRUM-master opgelost, maar bij inhoudelijke belemmeringen speel je als architect een belangrijke rol. Door op een constructieve manier met het team te sparren probeer je het team weer op het goede spoor te zetten. Wees hierbij niet te vasthoudend aan de oplossing en de opgezette architectuur maar wel aan de opgestelde principes. Het kan voorkomen dat de uitwerking van het team, en de kennis die jullie opdoen, een herijking van de gemaakte keuze(s) vergen.
4 Bouw aan een kwaliteitscultuur
Als architect van het team moet je bij de start afspraken maken waarbij oog is voor de kwaliteitsbewaking. Ontwikkelaars zullen principes, richtlijnen en afspraken niet leuk vinden. Maar ze zorgen wel voor een continu leerproces en eenvoudiger beheer van de ontwikkelde code. Voorbeelden hiervan zijn: “indien er gebruik gemaakt wordt van authenticatie en autorisatie gebruiken we standaard X” (principe), “Voor de beveiliging van de applicatie gebruiken we de richtlijnen van het NCSC” (richtlijn) of “inchecken van code is alleen mogelijk wanneer unit-tests gekoppeld en uitgevoerd zijn” (afspraak). Hierbij moet in de architectuur ook stilgestaan worden bij onderwerpen zoals ontwikkelpatronen, hergebruik van componenten en compatibiliteit over teams.
5 Update de architectuur
Voorafgaand aan de sprint heb je met de PO afspraken gemaakt over de gewenste oplossing. Maar ook tijdens de sprint worden binnen het team keuzes en prioriteiten gemaakt. Deze keuzes moeten kort en bondig vastgelegd worden. Voor veel architecten is dit een uitdaging. Gebruik bij het vastleggen modellen die voor iedereen, dus niet alleen de ontwikkelaars, te doorgronden zijn (denk aan simpele procesmodellen, praatplaten en andere methodieken die zich hiervoor lenen). Hierdoor kun je de architectuur sneller vastleggen en in de toekomst sneller aanpassingen maken.
Conclusie
Wanneer je de 5 punten beschouwt merk je dat de architect in een agile team faciliterend werkt voor zowel de PO, het team, als over teams heen. Samen werk je aan de totstandkoming van het Minimum Viable Product (MVP). Het blijft belangrijk om als architect het project niet te vertragen, maar erop gebrand te zijn om uitdagingen aan te zien komen en ze te tackelen voordat ze tot problemen leiden. Mochten er gedurende het project toch problemen opkomen is het de uitdaging van de architect om snel en in overleg met de PO en het team een oplossing te vinden.