Scrum zonder architecten: (g)een ideale wereld?

Tegenwoordig is Agile werken een veel voorkomende projectaanpak. Scrum is één van de Agile-methoden en voldoet aan veel actuele behoeften: korte feedbackcycli, directe klantbemoeienis en -interactie. Daarnaast kent deze methode ook een simpele rolverdeling, waarin drie teamrollen zijn gedefinieerd: de scrummaster, de product owner en het teamlid. Een architectenrol ontbreekt in dit rijtje. Opvallend, want uit de resultaten van de onlangs uitgevoerde Agile Survey 2011 blijkt dat 61 procent van alle architecten direct in een scrumteam werken of in een klein aantal scrumteams meedraaien. Wat is dan nog het verschil tussen een architect en een teamlid? Een scrumteam is natuurlijk self-organising en multidisciplinair. Een architect lijkt daardoor niet langer noodzakelijk, maar is dat daadwerkelijk zo?

Over het algemeen heeft een Scrumteam samen met de product owner een compromisloze focus op een systeem. De product owner bepaalt wat er op de product backlog van het systeem komt en wat de volgorde van de product backlog items is. Na iedere sprint levert het team software op die productieklaar is. Maar hoe vaak komt het voor dat systemen in productie in isolatie draaien? Systemen zijn onderdeel van een keten en afhankelijk van andere systemen of van organisatorische zaken, voordat zij daadwerkelijk door gebruikers kunnen worden gebruikt. Nadat een Scrumteam software oplevert, moet het nog in een grotere context worden gevalideerd. Om deze validatie succesvol te laten zijn, moet ervoor worden gezorgd dat de product backlog items technisch en organisatorisch in die context passen. De items moeten dan ook nog eens op het juiste moment worden geleverd. Dit is vanzelfsprekend de verantwoordelijkheid van de product owner: hij moet er namelijk voor zorgen dat de product backlog items in 'ready' status komen en hij is het enige aanspreekpunt voor het team als het gaat om wat het team moet gaan doen.

Maar werkt dit in de praktijk ook echt? Laten we eens kijken wat voor soort vragen een product owner dan allemaal beantwoord moet krijgen. Binnen welk landschap gaat het systeem draaien en welke eisen stelt dit aan integratietechnologie, verwerkingssnelheid, schaalbaarheid en beveiliging? Wat zijn de technische interfaces met andere systemen? Waar wordt het systeem gehost en welke eisen worden door functioneel en operationeel beheer gesteld? Welke processen moeten in de organisatie ingeregeld zijn om het systeem te gebruiken? Zijn er juridische eisen waaraan voldaan moet worden? Hoe kunnen we effectief valideren dat het systeem in de keten goed werkt? Allemaal vragen die beantwoord moeten zijn, voordat gebruikers daadwerkelijk gebruik kunnen maken van de nieuwe functionaliteit van een systeem in een keten. Pas als deze vragen beantwoord zijn, kunnen de product backlog items 'ready' gemaakt worden, kan het team ze effectief realiseren en kan de ontwikkelde functionaliteit ook snel in de handen van gebruikers komen en daadwerkelijk waarde gaan toevoegen voor onze klant.

Als we als IT-organisatie de gebruiker willen laten profiteren van een snel opgeleverde functionaliteit, dan moeten we aandacht besteden aan de samenhang tussen projecten en teams, de non-functionele eigenschappen van het systeem dat we ontwikkelen en de samenhang van ons systeem met het reeds bestaande landschap en de doelinfrastructuur. Hiermee komt de beginvraag weer terug. Welke rol is er eigenlijk verantwoordelijk voor deze aandachtsgebieden? Misschien is de architect dan toch echt onmisbaar.