Architectuur in een SCRUM project - De kunst van het loslaten

"Noodzakelijke" architectuurproducten

Een SCRUM project is zeer gebaat bij iemand met veel architectuurinzicht en ervaring. Architectuurwerk in SCRUM is door voortdurende bijstelling complex en gedisciplineerd. Er is een sterke neiging om te zoeken naar zogenaamde "noodzakelijke" architectuurproducten die vooraf aan een team opgelegd zouden moeten worden. In de praktijk heeft een SCRUM team erg weinig nodig om te starten en zelfs dat zouden we niet moeten willen opleggen, maar voorstellen.

"We hebben een uitdaging, zullen we deze samen aanpakken?"

Een manager, architect of product owner zou een project moeten starten met de volgende uitspraken: "Ik heb een idee hoe we business value kunnen produceren" of "We hebben een business probleem..." en vervolgens "Wat vinden jullie van dit idee, is het duidelijk, is het een mooie uitdaging, zien we het zitten?" Het liefst hoor je vervolgens tjakka-achtige uitspraken dat men er helemaal voor gaat om daarna vervolgvragen te stellen in een workshop-achtige opstelling: "Wat hebben we aan het eind, wat moeten we hiervoor doen en hoe gaan we het oplossen?"

Domein kennis cruciaal

Met deze vragen geef je je helemaal over aan je team. Je legt al je vertrouwen in het team dat zij met de beste architectuur zullen komen. In deze opstelling is de ontbrekende architectuur- en domeinkennis cruciaal. Deze zal dus door domeinexperts ingebracht moeten worden voor zover het in teams ontbreekt. Het essentiële verschil is dat het team zelf alle architectuurbesluiten neemt en niet de architect. Hoewel het architectuurwerk voornamelijk over besluiten nemen gaat, is de architect niet meer degene die besluiten neemt.

Open space bijeenkomsten

Een concreet middel om het architectuurproces te bevorderen zijn open space bijeenkomsten. Een open space heeft verschillende vormen. Een goed werkende vorm is waarbij participatie door teamleden vrijblijvend is en een thema aan het begin gezamenlijk wordt gekozen en behandeld. Iedereen heeft even veel stem- en beslissingsbevoegdheid. We gaan net zo lang door totdat we een consensus hebben ofwel alle argumenten gehoord en afgewogen hebben. In de praktijk worden zelfs zeer complexe thema's binnen één of twee uur weggewerkt. Daarna is het een kwestie van vastlegging op een Wiki en voilà: we hebben een goed verwoorde en vastgelegde ‘just-in-time’ en ‘just-enough’ architectuur. Het gekozen thema is altijd een thema dat op dat moment speelt en de komende sprints opgelost moet worden. Er is dus geen tijd en ruimte voor eindeloze theoretische discussies over hypothetische situaties die nog helemaal niet spelen.

Vertrouw je “kind” toe aan het team

Het kind in deze context is een psychologisch effect waarbij de architect zich persoonlijk verbindt met zijn oplossing. Iedere kritiek op de oplossing voelt als kritiek op hem als persoon. Het lastigste aan de kunst van het loslaten is misschien wel dat we als architecten ons kind blijven beschermen in de naam van zogenaamde hogere of lange termijn doelen. De teamleden in een SCRUM project zijn echter uitstekend in staat rekening te houden met lange termijn doelen zolang ze voortdurend betrokken en op de hoogte zijn.