Blog

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.

Deze blog is geschreven door Sander van den Berg. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van Svandenberg
Sander van den Berg
Xebia - Senior Consultant

Sander van den Berg begon zijn IT-carrière in 1999 en heeft veel ervaring op het gebied van softwareontwikkeling: van implementatie tot architectuur. Sander heeft onder andere gewerkt als ontwerper van softwarearchitecturen bij Defensie, waar hij vooral werkte aan MDA-/ MDD-oplossingen. In 2010 is Sander begonnen bij Xebia als Senior Consultant voor de business unit IT Architects (XITA), waar hij onder andere verantwoordelijk is voor de Xebia Lean Architecture methode.

Sander zoekt met zijn pragmatische aanpak altijd naar de juiste oplossing voor moeilijk op te lossen problemen. Hij kan door zijn achtergrond de vertaalslag maken van de behoefte naar lean architectuur en zorgdragen voor de implementatie die voldoet aan hoge kwaliteit.
Zijn visie op (software)architectuur is dat de architectenrol moet draaien om coaching en leidinggeven met een hands-on mentaliteit om problemen aan te kunnen pakken: Think Big, act Small!

 
Reacties
Joyce Nijkamp op vrijdag 20 januari 2012 0:26

herkenbaar; de architect ondersteunt de PO in iterateoverstijgende prioritering met kennis over huidige- en doelarchitectuur en daarmee over de gewenste volgorde, timing en integratie van features in het applicatie- en infrastuctuurlandschap.

Anko Tijman op vrijdag 3 februari 2012 8:12

Sander, helemaal met je artikel eens - op de laatste 2 zinnen na dan. Ik ben het zeker met je eens dat architectuur een onderbelicht aandachtsgebied binnen veel agile projecten is geweest en dat -nu grotere organisaties ook agile implementeren- het een must is dat agile teams daar aandacht aan gaan besteden.
Maar een aparte rol voor de architect ineen agile team is geen agile oplossing. Als testconsultant vind ik een tester onontbeerlijk, en een ontwerper vindt zijn rol essentieel. "Wij van WC-Eend", zeg maar.

Mijn visie is dat de agile teams kundig(er) worden in architectuur en voor een belangrijk deel die verantwoordleijk zelf in het team opnemen. En voor aansturing en coaching is er een "echte" architect, met focus puur op architectuur. Met een separate rol voor de architect creëer je een situatie waarin het team geen verantwoordleijkheid neemt voor architectuur. En dat wil je niet.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.