De essentiële ingrediënten voor creëren van een lerende organisatie zijn een stevig fundament, een heldere product visie, het continu leveren van het product, het valideren van de geleverde waarde en de doelen en kaders voor zelforganiserende teams. In het vorige artikel hebben we gekeken op welke wijze we product ontwikkelteams konden splitsen, in dit artikel kijken we hoe meerdere product ontwikkelteams of een effectieve wijze kunnen samenwerken.
Als een ontwikkelteam voor een product te groot wordt, en we splitsen deze over de lijn van feature teams, dan hebben we twee gelijkwaardige product ontwikkelteams. Deze teams werken gezamenlijk aan het ontwikkelen of verbeteren van het product. Aangezien zij beiden gelijktijdig aan het product werken, betekent dat er in het voortbrengingsproces een aantal activiteiten moeten worden aangepast ten opzichte van het werken met één product ontwikkelteam. Dit blijken er in de praktijk een stuk minder te zijn dan je aanvankelijk zou vermoeden…
Als we een product ontwikkelteam niet splitsen over de as van product teams dan hoeft er in het gehele traject van visie tot product backlog niets te worden aangepast. Immers, er is geen extra producten bij zijn gekomen (of afgesplitst) dan betekent dat de huidige visie alsmede de huidige product backlog om die reden niet hoeft te worden aangepast. De huidige activiteiten veranderen in het traject tot en met de sprint planning dan ook niet.
Wanneer we praten over het opschalen naar meerdere feature teams die gezamenlijk werken aan één product, noemen we dat een cluster. Een cluster richt zich op één product, heeft één product owner en één product backlog. Een cluster is in zijn geheel verantwoordelijk voor het ontwikkelen en beheren van het product. De maximale omvang van een cluster is negen teams, maar het optimale aantal teams ligt eerder rond de vier tot vijf teams.
Sprint planning
Het werk dat uitgevoerd moet worden tijdens een sprint wordt gepland tijdens de sprint planning. Het maken van dit plan is een gezamenlijke inspanning van het gehele Scrum Team. In een geschaalde context verandert “het gehele Scrum Team” op zich niet, maar hebben we te maken met niet één maar meerdere feature teams (en eventueel meerdere Scrum Masters). Dit betekent dat niet alleen feature teams zelf moeten bepalen hoe zij bepaalde functionaliteit kunnen realiseren, ook of en in welke mate zij daarbij afhankelijk van elkaar zijn. De sprint planning bestaat uit twee essentiële delen. Ten eerste het bepalen van wat deze sprint kan worden gedaan. En ten tweede het bepalen hoe het gekozen werk gedaan kan worden. Beide zijn ook in een geschaalde context van groot belang. Daarnaast kennen we in een geschaalde context ook nog een derde deel: de wrap up.
1) Het bepalen van wat deze sprint kan worden gedaan
De product owner bespreekt vanuit de visie, de product canvas en / of de story map de gewenste outcome en impact die de komende sprint(s) door de teams moeten worden gerealiseerd. (Een afvaardiging van) de feature teams bepalen, in nauwe samenwerking met de product owner én elkaar, welk sprint doel elk feature team voor zichzelf definieert waarmee zij zoveel mogelijk invulling geven aan de beschreven outcome en impact van de product owner.
Het sprint doel is daarin een doelstelling die gedurende de Sprint bereikt zal worden middels het implementeren van de product backlog en geeft richting aan de feature teams met betrekking tot het waarom van het bouwen van het product increment. Aan de hand van de opgestelde sprint doelen besluiten de feature teams hoe zij de product backlog het best gezamenlijk kunnen implementeren en kiezen daarbij ieder hun initiële deel van het daarvoor benodigde werk.
2) Het bepalen hoe het gekozen werk gedaan kan worden
Hierna gaan de feature teams afzonderlijk van elkaar aan de slag met het ontwerpen van het systeem en het werk dat gedaan moet worden om het geselecteerde werk van de product backlog om te zetten in een werkend product increment. Het feature team plant daarbij de hoeveelheid werk die zij denkt te kunnen opleveren in de komende sprint. Aan het einde van dit deel van de sprint planning heeft het feature team het werk voor de eerste dagen van de sprint opgedeeld in onderdelen, vaak van één dag of kleiner.
Gedurende de periode dat de feature teams bezig zijn te bepalen hoe het gekozen werk gedaan kan worden, mag de product owner helpen om de geselecteerde product backlog items verder te verduidelijken en om afwegingen te maken. Wanneer eventuele afhankelijkheden naar voren lijken te komen met andere teams gaan de teams met elkaar in gesprek hoe zij de afhankelijkheden gedurende de sprint kunnen minimaliseren.
3) Het reduceren van afhankelijkheden tussen de feature teams
Hoewel een groot aantal van mogelijke risico’s gedurende de vorige fase van de sprint planning reeds zijn onderkent en gemitigeerd, kan het zijn dat de initiële sprint doelen en geselecteerde onderdelen van de product backlog toch zijn gewijzigd. Om voor zowel de product owner als alle feature teams een helder beeld te hebben hoe zij gezamenlijk de komende sprint de gewenste outcome en impact gaan bereiken, delen alle teams in de wrap up hun uiteindelijke sprint doelen en grove sprint planning.
Sprint realisatie
Als het goed is zijn de meeste afhankelijkheden tussen de feature teams in de sprint planning al geminimaliseerd. Dit betekent dat feature teams redelijk autonoom kunnen werken aan hun persoonlijke sprint doel. Toch blijkt in de praktijk dat er behoefte is aan afstemming tussen de feature teams. De twee belangrijkste samenwerkingsvormen hierbij zijn de dagelijkse synchronisatie van de teams en de continue integratie in het product.
Periodieke synchronisatie van de teams
Gedurende de sprint realisatie zijn de feature teams gefocust op het realiseren van hun eigen sprint doelen, maar zijn wel gezamenlijk met de andere teams in dezelfde omgeving actief. Dit betekent dat ook vanuit buiten het feature team dingen kunnen plaatsvinden die effect hebben op het product increment of het feature team. Het is daarom raadzaam om gedurende de sprint realisatie op periodieke momenten even kort met elkaar af te stemmen om te zien waar eventuele afhankelijkheden zich kunnen voordoen, hoe feature teams elkaar eventueel nog kunnen ondersteunen en / of eventuele problemen gezamenlijk kunnen worden onderkent.
Scrum of Scrums is één van de meest bekende technieken van dagelijkse synchronisatie tussen teams te organiseren, maar ook technieken als Daily Scrum Observers of periodieke interteam overleggen behoren tot de mogelijkheden.
Continue integratie in het product
Aangezien meerdere teams werken in dezelfde documentatie en codebase is het van groot belang dat de aanpassingen van één feature team niet conflicteren met aanpassingen van andere feature teams. Of nog erger, dat aanpassingen door elkaar worden overschreven. Vroeger was het integreren van verschillende stukken documentatie en code maar met de gedistribueerde / concurrent versiebeheersystemen van tegenwoordig is dat probleem een stuk eenvoudiger om aan te pakken.
Het belangrijkste is dat aanpassingen van de mainline klein blijven en zo snel als mogelijk, correct werkend, terug worden geplaatst in de mainline. Door kleine aanpassingen te doen is het gevaar op merge conflicten laag, en wanneer deze zich voordoen zijn de aanpassingen relatief eenvoudig op te lossen. Het adagium is dan ook om zo vaak te integreren als mogelijk, maar wel op dusdanige wijze dat het product increment als geheel goed en in optimale vorm blijft functioneren.
Om die reden is het ook essentieel dat ontwikkeltechnieken als Test Driven Development, test automatisering, feature toggles, etc. worden toegepast om ten alle tijden een werkend product increment in de mainline te houden. Immers, het “breken van de build” zorgt ervoor dat alle andere feature teams niet kunnen integreren met als gevolg een steeds verder toenemend merge risico.
Als continue integratie op een juiste manier wordt uitgevoerd betekent dit ook dat aan het eind van de sprint, geen aparte activiteiten hoeven worden ondernomen om alle aanpassingen aan het product increment nog te integreren met elkaar. Immers, ieder team heeft dat op elk moment gedurende de sprint al gedaan. We hebben ten alle tijden een “altijd klaar, nooit af” product increment tot onze beschikking.
Sprint review
Aan een goed georganiseerde sprint review worden bij het schalen naar meerdere teams geen andere activiteiten uitgevoerd. De product increment is gedurende de meeting nog steeds bezig om feedback van de gebruikers en stakeholders op te halen, alleen is er in de afgelopen sprint waarschijnlijk meer opgeleverd.
De grootste valkuil die we in de praktijk zien is dat de sprint review een stroom van de resultaten van de verschillende feature teams zijn. Dit treedt vooral op als de essentie van de sprint review niet goed wordt begrepen. Het is niet om de werkzaamheden van de feature teams allemaal te tonen, het is om feedback op te halen op die gebieden van de product waar we juist feedback van gebruikers en stakeholders over willen hebben. Het kan dus zijn dat een aantal specifieke dingen van een feature team gedurende de sprint review niet aan bod komen.
Sprint retrospectives
De sprint retrospectieven in een omgeving met meerdere feature teams zorgt voor een uitdaging. Immers, de product owner (en soms de scrum master) kunnen niet tegelijkertijd aanwezig zijn in de verschillende sprint retrospectives. Daarnaast ontstaan er in een geschaalde omgeving ook verbetermogelijkheden die niet zozeer in het team liggen, maar juist in de samenwerking tussen teams zelf. Vandaar dat in een geschaalde omgeving de sprint retrospectives worden opgebroken in twee delen.
In het eerste deel houden alle feature teams gelijktijdig en zelfstandig hun sprint retrospective. De product owner (en eventueel scrum master van meerdere teams) sluit elke sprint aan bij een ander team om ook zijn of haar rol binnen het feature team onderdeel van de discussie te maken. Wanneer dit niet gebeurt is er een redelijke kans dat er een ongewenste afstand gaat ontstaan tussen de product owner en de feature teams.
Na het afronden van de individuele sprint retrospectives vaardigen alle feature teams 1 – 2 collega’s af voor de overall sprint retrospective. In deze retrospective is minimaal 1 van de scrum masters van de feature teams aanwezig en de product owner. Vanuit de verschillende teams wordt feedback over de samenwerking tussen feature teams meegenomen naar de overall retrospective. De werking van deze retrospective is gelijk aan de individuele sprint retrospectives, maar focust zich op de onderlinge samenwerking tussen de feature teams en de product owner zelf.
En verder…
Naast eerder genoemde activiteiten verandert er in de basis eigenlijk vrij weinig met het opschalen van één naar meerdere feature teams. In latere artikelen kijken we nog naar specifieke technieken zoals communities of practice, thema’s als architectuur of beveiliging en het afhandelen van incidenten. Met de aanpassingen voor het opschalen naar meerdere feature teams ziet het model er inmiddels als volgt uit:
Jurjen de Groot is een gepassioneerde Scrum en Agile expert consultant en trainer die gelooft in de eenvoud van de essentie van Agile. Door zijn unieke stijl van coaching laat hij organisaties zien dat een Agile adoptie van onder in de organisatie naar boven verspreid, erg haalbaar is.
Marco de Jong is een ervaren en resultaatgerichte principal consultant op het gebied van Agile & Lean. Hij is een uitdagende coach en bevlogen trainer met een achtergrond in organisatie ontwikkeling, management en software development. Door zijn eigen stijl van coaching weet hij mensen te helpen het beste uit zichzelf en hun organisaties te halen.
