Scaling Agile met de ‘subway map’

Scaling Agile met de 'subway map'
 
Softwareontwikkeling op basis van Agile heeft zich in kleine organisaties inmiddels bewezen. Maar wat zijn de stappen als er in de breedte van een grote ontwikkelorganisatie succesvol op een agile manier samengewerkt moet worden?
 
Cesario Ramos, Anko Tijman, Derk-Jan de Grood
 
Menig IT-organisatie van enig omvang zoekt mogelijkheden om Agile op grote schaal te introduceren. Vanuit de positieve ervaring met individuele teams, wil men de voordelen van Agile breder in de organisatie zien. Opschalen is noodzakelijk om in de breedte van een organisatie succesvol op een agile manier samen te werken. Volgens ons zoeken veel organisaties naar een definitie van ‘scaling agile’. Raamwerken als LeSS (Large Scale Scrum), SPS (Scaled Professional Scrum) en SAFe (Scaled Agile Framework) helpen niet echt bij het vinden van de definitie aange zien ze een eigen doelstelling en aanpak hebben. Daarnaast sturen veel organisaties nog vanuit een ‘command and control’-cultuur. Dat leidt tot conformiteit aan procedures en richtlijnen, wat softwareontwikkeling verstart en de agile waarden en principes compromitteert. Het gewenste eindresultaat blijft hierdoor uit. In dit artikel leggen we uit wat Agile op grote schaal inhoudt en langs welke dimensies er opgeschaald kan worden. Daarnaast introduceren we ‘subway mapping’ als lichtgewicht methode om afstemming te organiseren tussen diverse teams.
Vijf dimensies
Het opschalen van agile is de verandering waarbij organisaties de successen die behaald zijn met enkele individuele teams uit willen breiden naar grotere onderdelen van de organisatie. We onderscheiden vijf dimensies waarlangs we kunnen schalen: het aantal teams dat aan hetzelfde product werkt; het aantal producten dat agile ontwikkeld wordt; het aantal afdelingen, kantoren of locaties waar agile ontwikkeld wordt; de toepassing van de agile-waarden en -principes in de organisatie als geheel; en de volwassenheid in de agile-benadering Vaak starten organisaties met het opschalen van teams die aan een product werken. Uit het Dutch Agile Survey Report 2014 blijkt dat veel organisaties agile werken, maar dat de volwassenheid van de agile-implementatie vaak laag is. De keuze voor de naam ‘implementatie’ is al verdacht – waarden en principes kun je niet implementeren.
Er is een verschil tussen een ‘stand-up’ houden en de agile-principes en -waarden echt goed begrijpen. Er zijn verschillende raamwerken voor het inrichten van de organisatie. Maar als ze verkeerd worden toegepast, door bijvoorbeeld meer processen, meer rollen en meer coördinatie in te richten, kan de afstand tussen klant en teams juist groter worden. Het formeel toepassen van raamwerken leidt makkelijk tot een verstarrende ‘command and control’-praktijk. De successen van de indi viduele teams worden na het opschalen niet meer gehaald en men raakt teleurgesteld over de agile-transitie.
We introduceren ‘subway mapping’ als een lichtgewicht aanpak om uw agile-implementatie te schalen met behoud van de agile-waarden en -principes. Subway mapping richt zich op coör dinatie van de werkzaamheden van verschillende teams. Onze ervaring is dat organisaties die gaan opschalen juist hier als eerste tegenaan lopen. De gepresenteerde techniek is daarmee een relevante en laagdrempelige oplossing. Grote voordelen van subway mapping zijn de eenvoud en effecti viteit. Organisaties zullen weinig moeite hebben met het adopteren ervan. Het gebruik van de subway mapping stimuleert transparantie, overleg en samenwerking. Het stimuleert daarmee juist de toepassing van de agile-waarden en -principes.
 
Agile-waarden en -principes
De agile-waarden worden verwoord in het Agile Manifesto (www.agilemanifesto.org), dat wordt ondersteund door twaalf principes. Dat zijn de handvatten voor alle agile-implementaties. Ook bij agile op grote schaal bepalen deze principes het succes. Er zijn er echter een paar die bij het opschalen extra belangrijk zijn:
• Working software is the primary measure of progress. Opschalen maakt meten van voortgang aan de hand van werkende software nog belangrijker. Dat betekent dat er een gedegen oplossing moet komen voor het frequent integreren, testen en valideren van het product door stakeholders.
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Met één team is overleg met en terugkoppeling van je stakeholders eenvoudig. Met twintig teams is dat een heel ander verhaal. Veel organisaties kiezen ervoor om de teams rondom de systemen of componenten te organi seren. Dit komt voort uit het traditionele denken in functionele specialisatie. Een gevolg van deze keuze is helaas dat de nadruk komt te liggen op het produceren van software in plaats van het toevoegen van waarde. Waarde wordt alleen toege-voegd als de verschillende systemen samenwerken in de geïntegreerde keten. Bij het opschalen komt de organisatie voor de keuze te staan om feature-teams te creëren, die aanpassingen in grotere delen van de keten doorvoeren.
• Welcome changing requirements, even late in development. Aan het begin van een project is weinig bekend over het te ontwikkelen product. Speculaties over het probleem en de oplossingen zijn dan het grootst. Gedurende de ontwikkeling wordt echter continu feedback gegenereerd die aannames valideren. Dat levert nieuwe inzichten op die we terugvoeren in het te ontwikkelen product. Sterker nog, door het opschalen is het een nog grotere uitdaging om vooraf alles in te schat-ten. Reken dus op late inzichten en intensieve afstemming over de impact voor de verschillende teams bij opschalen.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. De grootste uitdaging in softwareontwikkeling is niet technologie maar communicatie en samenwerking. Verbetering van de onderlinge communicatie is geen sinecure binnen kleine teams. In een geschaalde omgeving waar veel teams vanuit verschillende locaties samenwerken is dit een serieuze uitdaging. Veelvuldig communiceren in beide richtingen, transparantie, en het beperken van overdrachtsmomenten (de teams vooral onderling laten communiceren) zijn kritieke succesfactoren.
Bij opschalen neemt de noodzaak voor communicatie en afstemming dus toe. Er zijn meer partijen betrokken, het product is groter en daarmee complexer. Hierdoor is overzicht houden moeilijker. Ook is de impact van de te verwachten wijzigingen groter. Werk moet worden opgepakt door verschillende teams, maar om waarde te kunnen leveren zal het werk ook geïntegreerd moeten worden en bij voorkeur worden gereleased. Om te integreren moeten de verschillende onderdelen op het juiste moment beschikbaar te zijn. Teams moeten daarom onderling afstemmen welke onderdelen ze wanneer opleveren. Voortschrijdend inzicht en tegenvallers zullen de roadmap beïnvloeden. Dit vraagt om een overkoepelend planningsoverleg waarbij plannen gemaakt en bijgesteld worden. In agile noemen we dit ‘roadmapping at scale’.
Roadmapping met de subway map
Stel dat je met zestien teams een webshop gaat ontwikkelen. Op deze schaal hebben mensen hun eigen specialistische kennis. Logisch want front-end webontwikkeling is een ander domein dan betaalprotocollen implementeren. Toch moeten de teams samenwerken, want het is immers één product.
Laten we zeggen dat we de domeinen ‘MyShop’, ‘Shopping’, ‘Ordering’ en ‘Payments’ hebben. Laten we ook aannemen dat we vier teams per domein hebben en dat in een overkoepelende releaseplanning onderstaande product-backlog is gemaakt. Een high-level overview van de product-backlog is hieronder weergegeven als een metrokaart (figuur 1) .
Figuur 1. Metrokaart voor een ‘scaled’ project dat een webshop implementeert
 
Een metrokaart geeft overzicht van de voortgang en afhankelijkheden van de verschillende domeinen. De verschillende metrolijnen representeren het werk van de teams. Stations op de lijn geven aan welke mijlpalen gedefinieerd zijn. De sub - way map is een weergave op businessniveau en doet geen uitspraak over de integratie en hettesten van de software. Bij elke ‘sprint’ wordt alle software van alle teams geïntegreerd en getest!
Per station kan, door de kleur van het station te veranderen, aangegeven worden wat de status van de trein is (figuur 2) . Wordt deze op tijd verwacht of is hij vertraagd? Is hij het station al gepasseerd dan is de mijlpaal gehaald. Er is een aantoonbaar geteste en werkende feature opgeleverd.
 
Figuur 2. Status van de mijlpalen
 
In ons voorbeeld hebben we per feature een station gedefinieerd. Elke feature bestaat uit verschillende requirements en er zijn mogelijk diverse sprints nodig om een feature te realiseren. De metrokaart maakt inzichtelijk welke teams aan de features werken en waar de afhankelijkheden zitten. Daar waar de metrolijnen elkaar kruisen, zijn er koppelstations, die staan voor de potentiële release-momenten. Als een metro vertraagd bij een voorliggend station, dient de andere metro te wachten voordat ze samen verder kunnen rijden. In het voorbeeld zijn dit de releasemomenten.
Release 1 is de minimale webshop waarmee de business zo snel mogelijk naar productie wil (figuur 3) . Als een team vertraging heeft, dient te worden nagedacht of dit consequenties heeft voor de integratie. Als de implementatie van bijvoorbeeld de productreviews tegenvalt, wat is dan de impact op de tweede release? In een traditioneel project zien we vaak dat de testperiode wordt ingekort, maar in een agileproject is testen deel van elke sprint. Het ligt daarom meer voor hand om te zoeken naar andere oplossingen, wat zijn de opties, wat zijn andere manieren om het releasedoel te realiseren? De metrokaart geeft geen antwoorden op deze vragen, maar het maakt eventuele problemen inzichtelijk en bespreekbaar. De meest efficiënte uitwisseling van informatie vind plaats door ‘face to face’-overleg. Dit overleg, in combinatie met een ‘praatplaat’, leidt ertoe dat men het over de dingen die tellen heeft: Hoe kunnen we de klant bedienen met waardevolle werkende software en inspelen op ontwikkelingen en veranderingen?
Figuur 3. Release-thema’s
 
Agile releasemanagement
Roadmapping staat niet op zichzelf; het heeft nauwe betrokkenheid met het release-management. Releasemanagement is nodig om het werk van verschillende teams te integreren tot een werkend product. Er zijn drie manieren van releasemanagement.
• Waardegedreven: Waarde toevoegen totdat de product owner vindt dat er voldoende waarde is toegevoegd en besluit tot release naar de eindklanten.
• Datumgedreven: De teams voegen zoveel mogelijk waarde toe binnen de beschikbare tijd. Op de afgesproken datum wordt het resultaat aan de eindklanten beschikbaar gesteld.
• Release-trein: Op reguliere momenten wordt beschikbare functionaliteit naar productie gebracht. De functionaliteit gaat mee met de trein. Wordt de trein gemist, dan wordt er gewacht tot de volgende trein.
De releasestrategie bepaalt dus hoe in het overkoepelend planningsoverleg de voortgang en afhankelijkheden tussen de verschillende teams worden gewogen. Het doel is om de ‘value stream’ van de organisatie te optimaliseren. Hierbij gelden de waarden en principes van agile zoals we die reeds benadrukten: de enige betrouwbare status van voortgang wordt gevormd door werkende, door stakeholders gevalideerde software. Tijdens het overleg wordt op basis van deze status het plan bijgesteld. Dit gebeurt in overleg met de product owners van de verschillende gebieden en dit leidt, zoals we in ons voorbeeld gezien hebben, tot een aanpassing van de prioriteit of inhoud van de features op de backlog.
 
Derk-Jan de Grood (derkjandegrood@valori.nl) werkt als testexpert en agile-coach bij Valori. Hij geeft Certified Agile Tester- en Scrum Master-trainingen en is auteur van onder andere ‘Agile in de Echte Wereld - Starten met Scrum’.
 
Cesario Ramos (cesario@agilix.nl) werkt als Leanen Agile product development coach en begeleidt organisaties in Agile-adoptie. Hij is professional coach, gecertificeerde Scrum-trainer, en de enige certified LeSS-trainer (Large Scrum Scrum) in Nederland. Hij is auteur van het boek ‘Emergent’.
 
Anko Tijman (anko.tijman@the-future-group.com) is freelance Agile- en DevOps-coach bij The Future Group. Hij is tevens examinator voor het Agile Consortium en co-auteur van het TestNet jubileumboek ‘Bepaal je koers’.
 
Referenties
Ramos C. (2014). EMERGENT - Lean & Agile Adoption for aninnovative workplace. Leanpub.
Progress reporting with the subway map (zie https://djdegrood.wordpress.com).
Dutch Agile Survey Report 2014 (2014). Xebia Agile Consulting.
 
 
 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag