Clusters: intense samenwerking

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:

Schermafbeelding 2020-10-16 om 20.18.51.png

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.

De mitose van ontwikkelteams

Inmiddels zijn we in gegaan op alle essentiële ingrediënten voor creëren van een lerende organisatie. We hebben de volledige basis gelegd om te kunnen gaan schalen vanaf een enkelvoudig product ontwikkelteam naar een complete product ontwikkelorganisatie, waarbij de impact van het schalen zelf geminimaliseerd wordt. Deze essentiële ingrediënten zijn een stevige fundering, 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 dit artikel kijken we hoe we het aantal teams langzaam kunnen opschalen zonder een enorme toename in complexiteit.

Hoe meer waarde één team in één iteratie weet op te leveren, hoe groter de kans is dat de organisatie nog méér waarde door dit team geleverd wordt. Hoewel dit op zich een goede indicatie is dat het team aan de juiste zaken werkt, drukt dit de product owner en het ontwikkelteam wel in een interessante positieve (of negatieve) spiraal. Hoe harder zij werken om hun output (en daarmee de outcome en impact) te verbeteren, hoe méér de organisatie naar output (en daarmee outcome en impact) gaat vragen. Als de organisatie de keuze maakt om extra middelen ter beschikking te stellen, rijst al snel de vraag. Wat nu?

Meer lezen over “De mitose van ontwikkelteams”

Wat doen managers nou eigenlijk?

In het vorige artikel hebben we gekeken naar wat managers nu eigenlijk doen om ontwikkelteams goed te ondersteunen en op welke wijze dat zij het beste kunnen uitvoeren. In dit artikel gaan we dieper in op de rol van het management en kijken we naar de belangrijkste aandachtsgebieden voor deze managers. 

Vraag aan een gemiddeld ontwikkelteam wat hun managers de hele dag doen en verbaas je niet over het resultaat. Als je al meer krijgt dan een blanco blik en duidelijke vraagtekens boven hun hoofd, dan is het vaak een opmerkingen op basis waarvan eenvoudig een satirische karikatuur kan worden gemaakt. Maar, en zo blijkt uit onze trainingen op het gebied van agile leiderschap,   ondanks het feit dat zij wel ongeveer kunnen vertellen waar ze de hele dag druk mee zij (als ze dat al kunnen), weet het merendeel ook niet precies wat ze zouden moeten doen om de teams te ondersteunen. 

Meer lezen over “Wat doen managers nou eigenlijk?”

Wat verwachten we van managers?

Vanuit het primaire voortbrengingsproces, ook wel de primaire flow genaamd, zijn we middels de gestelde visie en doelen en binnen de grenzen van de gestelde kaders inmiddels aangekomen bij de secundaire flow van het voortbrengingsproces: het management en de ondersteuning. In dit artikel gaan we kijken naar wat managers nu eigenlijk doen om ontwikkelteams goed te ondersteunen en op welke wijze dat zij het beste kunnen uitvoeren. 

Hoe vaak hoor je niet dat in een omgeving met een hoge mate van agility geen ruimte is meer voor managers? Dat door de hoge mate van zelforganisatie binnen ontwikkelteams de verantwoordelijkheden en taakstelling van managers overbodig is geworden? Dat in de primaire rollen van Scrum alle management taken onder zijn gebracht? Hoewel vanuit een theoretische of bijna filosofisch standpunt hier een heel pleidooi over kunt houden, denk ik dat in de praktijk deze houding enorme schade aanricht aan de wijze waarop organisaties worden geleidt en vorm gegeven.

Meer lezen over “Wat verwachten we van managers?”

Compliancy: kaders binnen kaders

In het vorige artikel zijn we in gegaan op de essentiële ingrediënten voor het creëren van alignment en autonomie van teams in de organisatie: doelen en kaders. In dit artikel kijken we hoe de kaders werken om de alignment en autonomie van teams te ondersteunen.

Ondanks de hoge mate van autonomy, mastery en purpose zijn Scrum teams geen vorm van anarchy. Bij high performing agile en Scrum teams is de noodzakelijke combinatie van een duidelijke doel en heldere kaders zichtbaar. Het is wel essentieel hier niet in door te slaan, teveel doelen en kaders leidt tot een lethargische houding van het Scrum team. In deze blogpost gaan we in op de rol van heldere kaders binnen een lerende organisatie.

Compliance is het begrip waarmee wordt aangeduid dat een persoon of organisatie werkt in overeenstemming met de geldende wet- en regelgeving. Het gaat over het nakomen van overeengekomen normen of het zich er naar schikken. Helaas wordt in de wereld van agility vaak sceptisch gekeken naar de aanwezigheid van kaders en richtlijnen, terwijl een juiste toepassing hiervan essentieel is voor zowel de organisatie als haar ontwikkelteams. Waarom eigenlijk?

Meer lezen over “Compliancy: kaders binnen kaders”