Agile en architectuur (3/7)
De focus van de voorgaande delen in de serie lag op de noodzaak van wendbaarheid en de rol die architectuur en architecten spelen in het vormgeven van het evolutiepad van de organisatie. Maar wat is de verhouding tussen Agile en architectuur?
De bron van Agile is het Agile Manifesto. Het Agile Manifesto is een document met uitgangspunten. Een manifest waardig formuleert het principes, de concrete invulling ervan wordt aan jezelf overgelaten. Vergeet niet dat het manifest een tegenreactie was op de cultuur van softwareproductie waarbij de governance knellend was.
Het Agile manifesto zegt niets over de rol van architectuur. Het wordt vaak omgedraaid: omdat governance en architectuur niet expliciet worden benoemd is er volgens sommigen geen rol voor het architectuurproces.
In discussies over governance of architectuur is er altijd wel iemand die het volgende principe aanhaalt:
“Inspelen op verandering boven het volgen van een plan”
Om vervolgens te concluderen dat projectplannen en het planmatig architectuur bedrijven niet thuishoren in een Agile wereld.
Iedereen vergeet echter de kanttekening te lezen:
“Hoewel wij waardering hebben voor al hetgeen aan de rechterkant (van de zin) staat vermeld, hechten wij méér waarde aan wat aan de
linkerzijde (van de zin) wordt genoemd.”
En dat is precies waar het om gaat. De nadruk moet liggen op resultaat, op het bereiken van doelstellingen. Daarbij is planning belangrijk, maar instrumenteel. Als je al wat langer werkzaam bent is het niet zo moeilijk om de voorbeelden te noemen waarbij het halen van de planning een doel op zichzelf werd.
Het geciteerde principe verkondigt eigenlijk twee boodschappen:
- Wees niet blind voor verandering en wees voorbereid dat je moet veranderen (‘Change Will Happen’)
- Inspelen betekent ook dat je wendbaar bent op het moment dat de verandering zich voordoet. In een omgeving waar het tempo van verandering hoog is moet je lichtvoetig zijn en niet log.
In het manifest raken de principes wel een noodzaak tot architectuur. Dit wordt duidelijk uit de volgende principes:
“Agile processen bevorderen constante ontwikkeling.
De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.”
“Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.”
“Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.”
“De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.”
Het laatste principe is olie op het vuur in de discussie over een architectuurproces in een wendbare organisatie: zie je nou wel! Weg met de architecten!
Dat ligt wat genuanceerder. Er staat namelijk nergens dat architecten geen onderdeel uitmaken van een zelfsturend team.
Wat de principes duidelijk maken is dat je verantwoordelijkheid voor de kwaliteit en bruikbaarheid van informatieproducten moet leggen bij de mensen die de producten gebruiken en maken. Dat kan alleen als ze samenwerken en zelf beslissingen mogen nemen.
De verschillende Agile methoden werken deze principes op verschillende manieren uit in samenwerkingsmodellen. Er is echter een praktisch probleem. Hoe zorg je ervoor dat er enige mate van consistentie blijft als je conform bovenstaande principes werkt of als je de ontwikkeling wilt schalen over zelfsturende teams heen?
Als je daar vooraf niet goed over nadenkt loop je tegen grenzen aan. Spotify legt in zijn “Engineering Culture” filmpjes uit wat de ervaringen zijn met grootschalige Agile ontwikkelinspanningen. Eén van die punten is de tegenstelling tussen consistentie en het borgen van agility, of zoals zij het noemen ‘Alignment versus Autonomy’ (het fragment begint op 3:05).
De centrale stelling van Spotify is: “Alignment enables Autonomy”. Dit is consistent met onze eigen ervaring, op een veel kleinere schaal overigens. Om alignment te bereiken werk je van grof naar fijn.
Om architectuur alignment uit te leggen wil ik graag eerst een misverstand uit de weg ruimen dat ik vaak tegenkom: Agile werken betekent niet dat je geen idee hebt van waar je heen gaat of van wat je wilt bereiken. Het is niet alsof je een team in een kamer zet en ze maar laat uitzoeken wat ze gaan doen.
Een team draagt bij aan het bereiken van organisatiedoelstellingen. Eén van de goede aspecten van Agile werken is dat je alle benodigde kennis bij elkaar zet en dat je het collectief mandateert om hun verantwoordelijkheid te pakken voor het bereiken van resultaten. Hoe dat uitgewerkt wordt is aan het team.
Een architect kan onderdeel zijn van het team, of buiten het team staan en randvoorwaarden stellen aan een team. De passende vorm is situatiegebonden. Je moet inschatten wat het best werkt om afstemming met de organisatieomgeving (alignment) te borgen.
Agile teams werken niet in een vacuüm. Door duidelijke kaders en doelstellingen te stellen komt de professionele autonomie het best tot haar recht. En architectuurkennis is daar slechts één van de noodzakelijke ingrediënten in.
Binnen dat kader zijn er allerlei eisen die door het team met de gebruikers worden afgestemd en die leiden tot verschillende mogelijke oplossingen. De architect, binnen of buiten het team, kan toetsen of de consequenties van de alternatieven binnen het kader passen en toekomstige belemmeringen kunnen opleveren voor het wendbaar houden van de oplossing zelf. De argumentatie voor de uiteindelijke keuze die het team maakt zorgt voor een gezamenlijk beeld van waar de grenzen van de oplossing liggen. Het maakt het makkelijker om als team te besluiten dat je een oplossing moet loslaten als een verandering in de omgeving daartoe aanleiding geeft.
In de realisatie van de oplossing kan een team eisen stellen aan de manier van werken, aan templates, aan naamgevingsconventies, aan standaarden voor datamodellering, voor ETL. Al deze standaarden zijn erop gericht om technisch voorspelbare, beheerbare en vooral aanpasbare informatieproducten te maken. Het doel van Agile werken is dat je eenvoudig op verandering kan inspelen. Door je gezamenlijke werkwijze te standaardiseren, een operationele vorm van alignment, creëer je autonomie in de inhoudelijk uitwerking en kan je je concentreren op wat echt belangrijk is: het leveren van waarde door middel van informatie.
De beschreven manier van alignment zoeken levert flexibiliteit op het moment dat je moet inspelen op verandering. En omdat teams zelf het besluit nemen hoe ze inspelen op een ingrijpende verandering, is de weerstand tegen een dergelijke verandering lager.
Binnen het architectuurproces zijn we gewend om van grof naar fijn te werken: van principes die de richting wijzen tot het uitwerken van oplossingen en tijdelijke omwegen. In een wendbare omgeving ligt de verantwoordelijkheid voor beslissingen in het architectuurproces wel op een andere plek dan de meeste architecten gewend zijn. Dat vraagt wat van de mentaliteit van de architect. In de volgende aflevering van deze serie ga ik hier dieper op in.