Blijf op de hoogte:

Contact: 033-7410041

Blogs

Architectuur en Scrumteams – 5 tips voor een goede samenwerking

Mark Kahmann
0

In een organisatie, waar wij een workshop over Agile en Architectuur verzorgden, is men sinds kort overgegaan op een Agile manier van werken met Scrumteams. Wij waren ingeschakeld door de architecten die ontdekten dat hun manier van werken sterk beïnvloed wordt door het ritme van de Scrumteams. In deze workshop hielpen wij de architecten en de teams na te denken over wat zij van elkaar verwachten. De bevindingen delen wij graag in deze blog.

Architectuur en scrum

graphic-scrum-team[1].gifEen Scrumteam werkt in sprints. Dit betekent dat zij in korte periodes van 2 tot 3 weken een werkend en getest onderdeel opleveren. De kracht van Scrum zijn de multidisciplinaire teams die elke dag kort bij elkaar komen om te overleggen wat zij gedaan hebben, waar zij tegen aan lopen en wat zij die dag gaan doen. Op deze manier kan snel en ad hoc een oplossing gevonden worden voor problemen die van tevoren niet voorspeld kunnen worden. Deze oplossingen brengen nieuwe architectuur vragen met zich mee die tijd kosten om te beantwoorden.

We spraken laatst een architect van Schiphol die vertelde fulltime bij zes Scrumteams mee te draaien om zo het overzicht te bewaren. Het bedrijf waar wij de workshop verzorgden, beschikt echter niet over de capaciteit om architecten fulltime met de Scrumteams bezig te laten zijn. Als het team moet wachten op het oordeel van een architect, die niet altijd beschikbaar is, dan lopen de sprints vertraging op. Aan de andere kant, als ad hoc beslissingen worden genomen zonder de input van een architect, moeten sommige van die beslissingen later worden teruggedraaid. Dit leidt vanzelfsprekend tot frustraties bij zowel het team als de architect als dit proces niet goed is ingericht.

 

Frustraties en verwachtingen

Architecten geven vaak aan het gevoel te hebben dat zij te laat in het proces pas worden betrokken en dat hun feedback niet altijd wordt meegenomen. Zij zijn zoekende naar hun rol ten opzichte van de Scrumteams. Het is vaak lastig om te bepalen welke kennis en inzichten van belang zijn voor de Scrumteams en welke informatie het alleen maar onoverzichtelijker maakt. Wat verwachten die Scrumteams dan eigenlijk?

De architecten zijn bewakers van de samenhang in het ICT-landschap. Zij moeten zorgen voor overzicht en een vertaling van de visie en doelen van de organisatie naar architectuur principes en kaders. De teams moeten dit dus meekrijgen. Als de kaders duidelijk gecommuniceerd worden, kunnen teams binnen die kaders zelf op zoek gaan naar oplossingen zonder daarvoor steeds bij de architect aan te moeten kloppen. Architecten zijn vaak schaars in een organisatie en hebben vaak weinig tijd.  Uit onze workshop kwam een aantal tips om inhoud te geven aan de rol van de architect t.a.v. de Scrumteams:

TIP 1:
Goede communicatie: Een goede manier om de richtlijnen en principes te communiceren richting de Scrumteams is om als architect in workshopverband aan meerdere teams tegelijkertijd uitleg te geven. Een vorm die je kan kiezen is om deze richtlijnen en principes te printen op A2 formaat en op te hangen bij de Scrumteams. Bij een groot FMCG-organisatie zagen we dat ze een overzicht op een kaart hadden geprint die ingeklapt was tot de grootte van een creditcard. Op deze manier kan iedereen de principes en richtlijnen altijd op zak hebben. Alleen het distribueren van deze kaarten is niet genoeg. Daarbij hoort natuurlijk ook de nodige uitleg en toelichting!

TIP 2:
Neem de architectuurprincipes op in de ‘Definition of Done’: De Definition of Done (DoD) is het document dat de exitcriteria voor de sprints bevat. Met andere woorden: Wanneer ben je klaar met de sprint? De DoD bevat de kwaliteitseisen aan de producten die aan het einde van de sprint worden opgeleverd. Dit is een commitment dat het team als geheel afgeeft. Wanneer aan het einde van de sprint niet voldaan is aan de DoD, is het product niet klaar voor oplevering. Dus, als er niet voldaan is aan de architectuurprincipes is het product dus niet gereed.

TIP 3:
Maak duidelijk met welke vragen men bij wie moet zijn: neem de tijd om met de teams te bespreken voor welke vragen (en antwoorden) zij bij welke architect (bijv. informatie-architect of solution architect) terecht kunnen. Het is extra zonde van de tijd als zij na enige vertraging te horen krijgen dat zij bij een andere architect of bij bijvoorbeeld de leverancier moeten zijn. Hierover afspraken maken voorkomt veel vertraging en frustratie.

TIP 4:
Organiseer als architect een of twee keer per week een vast inloopspreekuur. Voor de architect betekent dit dat vragen geclusterd komen en niet door de weeks tussen andere werkzaamheden door. Tegelijkertijd weet een Scrumteam dan op welk moment zij bij de architect terecht kunnen en op een antwoord kunnen rekenen.

TIP 5:
Pro-actieve betrokkenheid: Alle problemen met vragen achteraf kunnen deels voorkomen worden door als architect pro-actief bij het proces betrokken te zijn. Door te weten waar de teams mee bezig zijn, bijvoorbeeld door deelname aan de sprintdemo’s, kun je wellicht niet exact voorspellen tegen welke vragen zij aanlopen maar wel de richting van de vragen. Dit vereist dat de architecten uit de ivorentoren moeten komen!

Wil je meer lezen over hoe architectuur en een Agile manier van werken elkaar kunnen versterken? Lees dan deze blog of bekijk hier ons trainingsaanbod. Voor specifieke vragen kunt u contact opnemen met Mark Kahmann. 

 

Uitslagen Agile Portfolio Management survey

In de afgelopen weken heeft een grote groep respondenten van diverse typen organisaties de moeite genomen om deel te nemen aan het Agile Portfolio Management onderzoek van Bvolve. Download hieronder de gratis slidedeck met alle uitslagen.

 

New Call-to-action

 

Agile, Scrumteams