Agile opstellen van enterprise architectuur

Veel software ontwikkelteams werken met agile/SCRUM. Er wordt hoog opgegeven over de verbeteringen die dit brengt: meer klantgericht, door kleinere iteraties minder risico’s op softwareproducten die niet passen, plus meer efficiency: goed is goed genoeg. En niet in de laatste plaats meer ‘fun’ door een groter gevoel van eigen verantwoordelijkheid in zelfsturende teams. Het zou toch fantastisch zijn als architectuurteams dit ook weten te realiseren met agile/SCRUM? Maar is agile/SCRUM werken geschikt voor het opstellen van architectuur? Kunnen de beloftes van agile werken ook worden waargemaakt in het opstellen van architectuur? Hoe kun je architectuur op agile wijze opstellen?

Als de betrokkenen de intentie hebben uitgesproken om agile te werken, dan  zijn er twee randvoorwaarden:

  1. Een van de architecten is een ervaren Scrum Master die het team faciliteert en begeleidt op weg naar agile architecturen.
  2. Er is een Product Owner met kennis van de business én van architectuur die de stakeholders vertegenwoordigt.

Architecten enthousiast? Zijn de rollen van Scrum Master en Product Owner verdeeld? Start!

Sprint 0

In sprint 0 maak je afspraken over het proces: de lengte van sprints, planning van de Sprint Events en vul je daarnaast de Product Backlog met enterprise architectuurmodellen en inrichtingswerkzaamheden. De initiële vulling van de Product Backlog komt bijvoorbeeld uit: bestaande architectuur planningsdocumenten, zoals een jaarplan of TOGAF fase A Architectuurvisie met het Statement of Architecture Work. Vanuit Novius neem ik ook graag het Novius Architectuur Raamwerk mee als richtlijn voor de op te stellen baseline van enterprise architectuur modellen.

Sprint 1, 2, 3, …

Het team is klaar om aan de slag te gaan en start met de Sprint Planning.

  • Sprint Planning: Er zijn mij een paar dingen opgevallen aan de planning van architectuurproducten. Ten eerste vereist architectuur veelal intensieve afstemming met stakeholders en materiedeskundigen. De exacte mate waarin vormt onderdeel van de Definition of Done en moet afgestemd zijn op de sprintduur. Het maken van afspraken en het plannen van workshops is een van de eerste dingen die de architect zal moeten doen wanneer hij de betreffende taak oppakt. Dit is een van de concrete manieren waarop SCRUM architectuur efficiënter en meer klantgericht maakt: inherent betere planning van afstemming door focus op het resultaat.Ten tweede worden architecten geholpen door de Product Owner met het antwoord op vragen over wanneer een architectuur moet worden opgeleverd, welke kwaliteit die moet hebben en hoeveel prioriteit dat heeft. Omdat SCRUM hier expliciet aandacht aan besteedt wordt transparant wie wat moet leveren. De Product Owner rol is hierbij cruciaal omdat die als ‘stem van de stakeholders’ het architectuurwerk moet prioriteren en eisen moet stellen aan de kwaliteit. De architecten kunnen zich zo focussen op het werk waar ze echt goed in zijn: architecturen opstellen.Ten derde is het nog wel eens een uitdaging om een groot architectuurproduct, zoals de enterprise architectuur,  op te knippen in kleinere delen die gemaakt kunnen worden in 1 sprint. Door bij het opknippen tevens te denken in termen van meeste toegevoegde waarde wordt bereikt dat de enterprise architectuur niet van voren (klanten) naar achteren (infra) wordt opgesteld, maar veel meer de focus krijgt op waar de komende tijd verandering plaatsvindt. En dat er bijvoorbeeld eerst een houtskoolschets van (een paar) modellen in samenhang wordt gemaakt, waarna de modellen verder worden uitgewerkt in pentekeningen en vervolgens pas op het gewenste abstractieniveau. Bij tijdgebrek of urgente projecten tussendoor zijn de belangrijkste elementen van de enterprise architectuur dan in ieder geval (grof)uitgewerkt.En tot slot: de ervaring leert dat een sprint nokvol plannen niet aansluit bij de werkelijkheid van enterprise architectuur opstellen en daarover communiceren. Er is behoefte aan ruimte voor de meer creatieve, adhoc activiteiten om de enterprise architectuur geaccepteerd te krijgen. Hiervoor moet de sprint planning ruimte laten.
  • Daily scrum: Een architectuurteam zit bij voorkeur dicht bij elkaar in de buurt om afstemming te vereenvoudigen, maar architecten stemmen veel af met belanghebbenden en zijn dus regelmatig onderweg. Een daily scrum kan dan te intensief zijn en vaak wordt dan een weekly scrum voorgesteld. Hoewel dit logisch klinkt, blijkt in de praktijk toch vaak,  dat architecten die naast hun werk aan de enterprise architectuur nog andere ‘klussen’ hebben liggen, lopende de week de Sprint Backlog uit het oog verliezen en er dus pas na een week weer mee geconfronteerd worden. Als dit herkenbaar is, dan is het zeker het overwegen waard om dagelijks toch (kort!) samen te komen, desnoods in een video- of teleconference.
  • Sprint Review: “Het mooie van de sprint review is dat er eindelijk eens iemand belangstelling toont voor mijn architectuur” verzucht menig architect die met agile/SCRUM is gaan werken. En dat is ook mooi. Een kans om een feestje te vieren en ‘tastbaar’ resultaat te presenteren. De uitdaging in de sprint review van architectuur is om het resultaat in een korte demonstratie te laten zien. Voorbereiding is essentieel. Architectuur is natuurlijk een prachtig onderwerp om veel over te vertellen en de complexiteit biedt ook aanknopingspunten voor stakeholders om veel vragen te stellen. Ik begin graag met een korte Sprint Review en dwing mezelf compact mijn houtskoolschetsen, pentekeningen en modellen met de principes daarachter te presenteren om zo de stakeholders betrokken te krijgen. Als de stakeholders zelf behoefte krijgen aan verlenging en verdieping, dan herplannen we de volgende Sprint Review op verzoek van de dan betrokken en geïnteresseerde stakeholders.
  • Sprint Retrospective: Deze fase is voor architecten niet anders dan voor andere SCRUM-teams en mijn eigen ervaring is dat er in gewone architectuurteams weinig tot geen ruimte wordt gemaakt om op reguliere basis met elkaar opbouwend kritisch naar het gezamenlijke proces van architecturen te kijken. En het spreekt voor zich dat een team dat hiermee begint (in het kader van SCRUM) het als heel prettig ervaart om complimenten uit te wisselen en problemen constructief te bespreken.

Klaar met de Retrospective? Tijd voor een nieuwe sprint, te beginnen met de Sprint Planning. Succes!

Morgen beginnen? Lees hieronder wat je aan voorbereiding kunt doen!

 Verdeling van rollen in de SCRUM-aanpak

Agile architectuur opstellen werkt volgens de SCRUM aanpak, met de rollen en processen zoals beschreven in de scrumguide. De rol van Scrum Master in het architectuurteam is cruciaal en hiervoor is ervaring vereist. Deze rol is feitelijk de trekker van de transitie naar agile werken. Er zijn ondertussen genoeg architecten die in een agile organisatie gewerkt hebben, anders moet hier iemand voor worden aangenomen of ingehuurd. Het ‘product’ van het architectuurteam is hier de enterprise architectuur. De rol van Product Owner vereist dus kennis van de kwaliteit van architectuur, maar ook kennis van de behoefte aan architectuur (goed is goed genoeg) van de afnemers van architectuur: projecten en afdelingshoofden. Deze rol past goed bij de lead-architect, de team-lead of in kleinere organisaties de CIO. Bij stakeholders van de enterprise architectuur kun je denken aan informatiemanagers, I-adviseurs, projectarchitecten, portfoliomanagers en lijn- en stafmanagement. Zij maken natuurlijk zelf uit of ze zichzelf als zodanig beschouwen en dus de Sprint review bezoeken. Last but not least: teamleden van het architectuurteam moeten welwillend tot enthousiast zijn, maar vooral geduldig en leergierig. Het agile opstellen van architectuur leer je in iteraties, sprint na sprint, en dus zijn getemperde verwachtingen voor de korte termijn op hun plaats.

 Ondersteuning met een kanban-bord

Het architectuurteam moet een plek hebben om bij elkaar te komen en bij voorkeur redelijk bij elkaar in de buurt werken. Voor het kanban-board werk ik zelf graag met Trello, maar een fysiek overzicht van de sprintplanning is ook aan te raden, zeker als het architectuurteam naast die van architect ook andere rollen in de organisatie heeft en het architectuurwerk dus concurreert met ander werk.

Ben jij geïnteresseerd en wil je meer weten over hoe Novius dit aanpakt? Neem dan contact met mij op via vakkersdijk@novius.nl of 06-26322811. Of anders via het secretariaat van Novius via 0343 76 00 76.

Victor Akkersdijk

Senior Business Consultant en CC Manager bij Novius

Inleiding

Victor Akkersdijk, senior architect bij Adviesgroep Novius, deelt in dit blog zijn ervaringen met een aantal organisaties waar hij met behulp van een agile/SCRUM aanpak de architectuurfunctie heeft ingericht en heeft geholpen de bedrijfsarchitectuur (enterprise architectuur), doel-architectuur en projectstart-architecturen (PSA) op te stellen.
Om deze blog focus te geven gebruikt Victor als voorbeeld het agile opstellen van enterprise architectuur. Hij gaat uit van een organisatie waar de meerwaarde van architectuur onderkend is en waar gezocht wordt naar een aanpak om het architectuur voortbrengings-proces vorm te geven. Om dat voortbrengings-proces met agile/SCRUM in te richten is voorkennis en training in agile/SCRUM geen randvoorwaarde. Mocht dit wel al zo zijn, dan is dat natuurlijk perfect. Echter, (klein) beginnen met enthousiaste stakeholders is belangrijker dan een uitgebreide voorbereiding met SCRUM-trainingen.

“Zie je zo!” Empathie en compassie in een klantgerichte organisatie
No. 5 van 6 – Een goede verkenning als basis voor succes

Geef een reactie

Het e-mailadres wordt niet gepubliceerd.

Fill out this field
Fill out this field
Geef een geldig e-mailadres op.

Menu