Enterprise Architecture and Agile development, bij nlscrum

Scrum wordt steeds meer gebruikt in Nederland, om software volgens agile te ontwikkelen. In nlscrum, de Nederlandse Scrum  gebruikers groep worden ervaringen met Scrum uitgewisseld. In de bijeenkomsten leer je van elkaar, doe je nieuwe ervaringen op, en kun je je netwerk uitbreiden. Op woensdag 31 augustus ben ik bij de bijeenkomst geweest bij Xebia over Enterprise Architecture and Agile development.

Met zo’n 60 deelnemers een behoorlijke opkomst, en dat was direct te merken toen ik bij het Xebia gebouw aankwam, de parkeerplaats was vol. Gelukkig tipte een Xebia medewerker mij voor parkeergelegenheid in de buurt, en daar kwam ik enkele bekenden tegen. Al meteen wat bijpraten, en ik ben nog niet eens binnen!

Voorafgaand aan de presentatie was er een smakelijke maaltijd, en dan raak je snel in gesprek met andere deelnemers. Een leuke discussie over wie nu verantwoordelijk is voor het halen van een delivery deadline? De product owner als eerste, door met de backlog ervoor te zorgen dat de belangrijkste functionaliteit erin zit (prioriteitstelling van user stories). De agile teams leveren in sprints de user stories op, door dat zo goed mogelijk te doen is de kans het grootste dat de deadline met de juiste functionaliteit gehaald wordt. In een organisatie die agile invoerde heb ik teams meegemaakt die shortcuts gingen nemen omdat ze de deadline wilde halen. Dat ging ten koste van de productkwaliteit en had als gevolg had dat later in het project verstoringen optraden. Er werden meer fouten gevonden dan verwacht, en de deadline werd uiteindelijk niet gehaald. Het is belangrijk om de Scrum rollen goed in te vullen: Product Owner is verantwoordelijk voor de backlog en de delivery/einddatum, team levert werkende software mbv de sprints. Uiteraard is het goed als het team weet wat de deadline en de vereiste functionaliteit is (dat zouden ze eenvoudig in de backlog moeten kunnen zien), en als ze oplossingen zien om de delivery datum te halen dat te overleggen met de product owner. De product owner moet ervoor waken dat hij teams niet onder druk zet met de deadline. Klinkt allemaal triviaal, maar als een organisatie altijd gedreven is geweest door deadlines, dan leer je dat niet zomaar af.

Tijd voor de opening van de avond, door Eelco Rustenburg. Hij was onder de indruk van de grote opkomst, en de snelle groei van nlscrum (ruim 700 leden inmiddels)! De avond bestond uit een presentatie door Ronald Doelen, en daarna een open space. De deelnemers brachten een variëteit aan interessant topics op, keuze gemaakt, en op naar de 1e discussie. Gaandeweg de 1e discussie werd mij duidelijk dat ik er niets leerde, en ook niets toe kon voegen, dus de law of two feet toegepast en naar een andere discussie.

De discussie die ik vond was over het belang van architectuur. Helaas gebeurt het nog te vaak dat te weinig aandacht wordt gegeven aan architectuur vraagstukken, met als gevolg dat gaandeweg het project het steeds lastiger wordt om nieuwe features te maken. Agile noemt dit technical debt, hele passende benaming want door onvoldoende aandacht voor de kwaliteit ga je inderdaad een “lening” aan die je later terugbetaald in de vorm van uren en geld. Al je kiest voor een oplossing met een lagere kwaliteit dan moet je op dat moment afvragen hoeveel technical debt je aankunt, en wanneer je het terug gaat betalen. Het kwantificeren van je technical debt is niet eenvoudig (wel belangrijk), en soms heb je ook te maken met tegenstrijdige belangen van de verschillende stakeholders. Het agile team zal, samen met architecten (als die niet in het team zitten), duidelijk moeten maken wat de consequenties zijn van bepaalde keuzen, nu en in de toekomst. Mooi om te zien was dat er tijdens de discussie ook diverse praktische oplossingen ingebracht werden door de deelnemers. Zoals gebruik maken van retrospectives om de oorzaken te begrijpen van technical debt (en die oorzaken aanpakken), gebruik van Total Cost of Ownership, betrekken van een stakeholder die zowel de ontwikkel- als onderhoudskosten moet betalen, etc. Ook ik kon diverse dingen inbrengen, en leerde van de ervaringen van andere; wederom bewijs dat de law of two feet er niet voor niets is.

De bel ging, tijd voor de 2e discussie. Ditmaal een onderwerp opgebracht door Jurgen Appelo, die zich afvroeg of Conway’s Law inderdaad klopt, en of je er dan gebruik van moet maken of juist niet? Conways Law zegt “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”. Vrij vertaald, de architectuur van je software volgt uit de communicatiestructuur van de ontwikkelorganisatie. Tijdens de discussie zagen we dat het afhangt van de grootte van de software die je ontwikkelt, en van de organisatie. Als je werkt met feature teams, waar ligt dan de grens mbt het aantal teams en ontwikkelaars? 100? 1000? Op een bepaald moment krijgt ze zoveel communicatie tussen ontwikkelaars uit verschillende feature teams dat het onpraktisch wordt; de keuze om dat de ontwikkelorganisatie in te richten volgens de gewenst architectuur wordt dan aantrekkelijk. Bv. door een platform groep, en feature teams. Overigens kunnen in zo’n platform groep meerdere scrum teams zitten, die middels een scrum-of-scrums zaken afstemmen. Maar je creëert op deze manier wel een product interface, en kanaliseert door de organisatievorm de communicatie over de productonderdelen. Overigens denk ik dat het soms wel goed kan zijn om de organisatie juist niet in te richten volgens de architectuur, en mensen bewust te spreiden in verschillende teams, wat cross team communication rondom architectuur issues stimuleert. Uiteraard moet je oppassen dat die communicatie wel haalbaar blijft, maar het zorgt wel voor een opbouwen van relaties tussen de diverse teams, en verbetert daarmee de totale communicatie binnen het project. Eindconclusie was dat Conway’s Law vanuit de praktijk lijkt te kloppen, en dat het dan beter is om er bij grotere projecten gebruik van te maken. Met nog wel de aanvulling dat het ook voorkomt dat een (te) grote en (te) complexe organisatie wordt opgezet om een product te ontwikkelen, wat met veel minder mensen gebruikmakend van feature teams goedkoper (en vaak ook sneller) had gekund. De hogere productiviteit van goed werkende teams wordt nog te weinig onderkend, helaas.

Hoe later op de avond, des te schoner de discussies. Het 3e tijdslot begon, en ik kwam in contact met 2 deelnemers die problemen hadden met stabiel houden van hun agile teams. Veel teamleden werkte aan meerdere projecten, en er kwamen ook regelmatig mensen bij of werden mensen weggehaald en toegewezen aan een andere team. Na wat heen er weer praten bleken de 2 deelnemers bij dezelfde organisatie te werken, dus logisch dat de problematiek van een zo herkenbaar was voor de ander! Waarmee nog maar eens het nut aangetoond van netwerkbijeenkomsten, zo spreek je je collega’s nog eens ;-). Overigens kun je dit soort netwerken ook prima doen binnen een bedrijf, maar dat terzijde. Tijdens de discussie kwamen we op diverse manieren om teams stabieler te houden. In een eerder posting over Establishing and Maintaining Stable Teams was voor de oplossing gekozen om work packages in te voeren, die daarna door fixed teams opgeleverd werden. Een andere oplossing is gebruik te maken van Kanban, om b.v. het aantal verschillende projecten waaraan een team werkt te beperken. Als er een nieuw project opgepakt moet worden door een team, prima, maar alleen als er een andere weggaat! Op deze manier heb ik eerder ook een portefeuille van projecten gemanaged voor de kwaliteitszorg, om te voorkomen dat de werkzaamheden van de teamleden teveel versnipperde en daardoor niet meer effectief waren. Mijn Kanban tip bleek bruikbaar voor de deelnemers, dus ook in deze discussie een bijdrage geleverd!

Tijd om nog even na te praten met een drankje, en uiteraard de organisators te bedanken! Leuk en leerzaam evenement, kijk uit naar de volgende bijeenkomst van nlscrum. Er zijn ook nog bijeenkomsten van andere netwerken, even naar de reclame:

  • Just Enough! op 12 september, over het tweede principe van het Agile Manifesto “Working software over comprehensive documentation”, georganiseerd door SPIder en het Agile Consortium Nederland.
  • Agile en ICT beleid bij de overheid op 26 september, georganiseerd door AgileOverheid

Nogmaals dank nlscrum voor het organiseren van dit evenement, en tot ziens!

Share this Experience
  • 17
    Shares

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

×
×

Cart