Vijf teams en geen raamwerk

Wat er precies ontbreekt

Een organisatie heeft vijf teams die aan één product werken, en wil geen raamwerk erboven. De vraag die daarbij hoort gaat zelden over schalen; ze gaat over wat er op dit moment misgaat. Het lesmateriaal over schalen begint met precies die inventarisatie, en noemt vier problemen die ontstaan zodra meer dan één team aan één product werkt.

Het eerste is afhankelijkheid tussen teams: team A haalt zijn sprintdoel niet omdat team B een API nog niet heeft opgeleverd. Het tweede is gedeelde architectuur, want elk team dat zijn eigen technische keuzes maakt produceert op termijn een systeem dat niet meer samenhangt. Het derde gaat over strategie en backlog, en dat is een mandaatvraag: een product owner kan de backlog van één team prioriteren; niemand in dat model heeft het mandaat om te zeggen dat een initiatief acht teams raakt en daarom boven al het andere werk moet staan. Het vierde is cadans zonder synchronisatie. Als elk team zijn eigen ritme kiest, ontstaat er nooit een gezamenlijk ijkpunt waarop de organisatie kan zien wat er over alle teams heen is opgeleverd.

Dan volgt de zin die dit hele stuk draagt. "Dit zijn geen tekortkomingen van Scrum. Scrum lost het probleem op waarvoor het is ontworpen." Wat er ontbreekt is coördinatie over teams heen, en dat is nooit de opgave van een teamraamwerk geweest.

Dat onderscheid bepaalt waar je gaat zoeken. Wie denkt dat scrum tekortschiet, zoekt iets dat scrum vervangt. Wie ziet dat er een laag ontbreekt, zoekt het kleinste dat die laag invult.

Eerst de afhankelijkheid weghalen

Voordat er iets wordt ingericht, staat er in datzelfde materiaal een stap die daaraan voorafgaat. Het ontwerpprincipe bij het indelen van teams luidt: minimaliseer afhankelijkheden tussen teams door teams zoveel mogelijk end-to-end verantwoordelijk te maken voor een herkenbaar stuk van de waardestroom, en gebruik gedeelde of specialistische teams alleen waar specialistische kennis of een gedeelde voorziening dat vereist.

Het voorbeeld dat erbij staat is concreet. Waar er een team "Aanmelden" en een team "Mutaties" zijn die voortdurend op elkaar moeten wachten, komen er twee teams die samen de volledige mutatiestroom end-to-end kunnen opleveren. Een afhankelijkheid die op die manier verdwijnt, hoeft daarna door geen enkel mechanisme meer te worden gecoördineerd.

Twee dingen horen erbij. Het eerste is dat dit een ontwerpprincipe is en geen gemeten uitkomst. Dat een end-to-end ingedeeld team minder op anderen wacht, is de redenering achter de indeling; in dit materiaal is het nergens nagerekend. Het tweede staat er zelf bij. Zo'n herindeling raakt mensen die gewend waren tot een ander team te behoren, en is daarmee zelf een verandertraject dat om dezelfde zorgvuldigheid vraagt als de invoering die erop zou volgen. Wie vijf teams opnieuw indeelt om coördinatie te besparen, koopt daar een tweede veranderopgave voor terug.

Vier mechanismen, en wat elk ervan beantwoordt

Wat een verzameling teams tot één trein maakt zijn volgens het lesmateriaal vier gedeelde mechanismen: een gedeelde cadans, gezamenlijke planning, gedeelde events, en één gezamenlijke backlog boven de teambacklogs. Ze staan daar beschreven als onderdelen van één geheel. Ze zijn ook los te installeren, en dan wordt per mechanisme de vraag welke afhankelijkheid hem rechtvaardigt.

Een cursus uit een andere hoek van het vak levert daarvoor de indeling. Die onderscheidt drie soorten afhankelijkheid tussen gelijktijdig lopende initiatieven: technische afhankelijkheid, waarbij het ene iets oplevert dat het andere nodig heeft; capaciteitsafhankelijkheid, waarbij twee initiatieven dezelfde schaarse mensen nodig hebben zonder dat er een technische relatie tussen ze bestaat; en volgtijdelijke afhankelijkheid, waarbij het resultaat van het ene er moet zijn voordat het andere kan beginnen. Die cursus gaat over programmamanagement en noemt geen enkel agile-raamwerk. Dat de twee hier naast elkaar staan komt van deze kennisbank.

Zonder gelijk ritme werkt de rest niet, en daarom komt de gedeelde cadans eerst. Het principe staat in het lesmateriaal in twee helften: een vast, voorspelbaar ritme maakt onzekerheid hanteerbaar, en synchronisatie zorgt dat teams die van elkaar afhankelijk zijn op hetzelfde moment plannen. Die tweede helft is de rechtvaardiging. Sla je de cadans over, dan bestaat er geen moment waarop vijf teams tegelijk naar dezelfde horizon kijken, en moet elk mechanisme daarna dat moment alsnog zelf organiseren.

De gezamenlijke planning beantwoordt de technische en de volgtijdelijke afhankelijkheid, en hier staat de enige plaats in het materiaal waar concreet wordt wat er misgaat zonder. Tijdens het gezamenlijke planningsevent presenteert elk team zijn concept-plan aan de rest, en daar komt naar boven dat team Facturatie ervan uitging dat een koppeling van team Mutaties al in de eerste iteratie klaar zou zijn, terwijl team Mutaties die pas in iteratie drie had gepland. Zonder dat moment komt dat verschil aan het licht op de dag dat een team stilvalt. Het hulpmiddel dat erbij hoort is een gedeeld bord met een tijdlijn per team en de afhankelijkheden ertussen zichtbaar gemaakt, en dat hulpmiddel kost een vel papier.

Het vierde probleem uit de inventarisatie, het ontbrekende ijkpunt, wordt beantwoord door de gedeelde events. Een demonstratie van de geïntegreerde oplevering over alle teams heen is het moment waarop zichtbaar wordt of het werk van vijf teams optelt tot iets dat werkt. De programmacursus komt langs een heel andere weg op dezelfde behoefte uit en noemt het een geaggregeerd beeld van voortgang, bruikbaar zonder in de details van elk onderdeel te verzanden. Het tweede gedeelde event, de gezamenlijke terugblik over alle teams heen, is de plaats waar de coördinatie zelf wordt bijgesteld.

De gezamenlijke backlog komt als laatste en is de zwaarste. Hij beantwoordt de mandaatvraag uit het derde probleem, en hij is ook de plaats waar capaciteitsafhankelijkheid wordt beslecht: twee teams die dezelfde schaarse specialist nodig hebben, hebben iemand nodig die kiest wie voorgaat. De programmacursus zegt daarvan dat expliciete prioritering hier nodig is, en dat die meestal bij het bestuur van het geheel ligt. Wie deze vierde overslaat, houdt vijf backlogs over die elk op zichzelf goed geprioriteerd zijn, en geen plaats waar de keuze tussen twee ervan valt.

Wat opvalt is wat er niet bij zit. Van de vier problemen uit de inventarisatie wordt de gedeelde architectuur door geen van deze vier mechanismen geraakt. Het lesmateriaal beantwoordt die met een rol en niet met een gedeeld ritueel: iemand die de technische samenhang over teams heen bewaakt en vooruitloopt op wat de teams nu bouwen. Dat probleem is met de vier mechanismen dus niet geregeld.

Wie de knoop doorhakt

Elk van die mechanismen brengt knopen aan het licht die het zelf niet doorhakt. Het gedeelde bord laat zien dat twee teams elkaars werk in dezelfde week nodig hebben; het zegt niet wie er wijkt.

Het lesmateriaal belegt dat op twee plaatsen. Er is een rol die afhankelijkheden en risico's tussen teams signaleert en helpt oplossen en die de cadans bewaakt, met de uitdrukkelijke toevoeging dat die rol geen hiërarchische macht over de teams heeft; het gezag komt uit faciliteren en coachen. Het besluit zelf valt ergens anders. Na de eerste dag van het planningsevent bespreekt het leiderschap van de trein de knelpunten die uit de concept-plannen naar boven kwamen, en bereidt het de aanpassingen in omvang of prioriteit voor die de volgende dag aan alle teams worden teruggekoppeld. Signaleren en beslissen liggen daarmee bij verschillende mensen.

De programmacursus komt zonder enig agile-raamwerk op dezelfde vorm uit. Een kwestie die in één initiatief ontstaat maar andere raakt, kan niet door de verantwoordelijke van dat ene initiatief worden afgehandeld; die gaat naar het niveau dat de impact over de volle breedte kan overzien en waar nodig tussen initiatieven kan prioriteren. Hoe vaak dat gebeurt ligt vast in een governancecadans: een vaste vergadering voor de hoofdlijnen, met frequentere reviews op afhankelijkheden en risico's daartussen.

Diezelfde cursus levert ook de ijking. "Een programma waarin iedereen overal over mag beslissen, is net zo problematisch als een programma waarin niemand iets mag beslissen zonder de sponsoring group erbij te halen." Elders staat hetzelfde van de andere kant: wie eindverantwoordelijk is voor het geheel, bemoeit zich niet met wat op het niveau eronder al hoort te worden beslist.

Dat is de vorm van de tolerantiegrens waar op deze site eerder over is geschreven. Binnen die grens beslissen de mensen die het werk hebben gedaan en die ermee moeten werken zelf; wat erbuiten valt gaat omhoog. Waar die grens bij vijf teams precies loopt, staat in geen van beide cursussen.

Wat er wegvalt als de laag er niet is

Er is één toets in dat materiaal die de hele vraag beslecht, en hij staat er als instructie vooraf. "Toets, voordat je een programma inricht: zou het weghalen van de programmalaag een van de beoogde baten onmogelijk maken? Zo nee, dan is het geen programma maar een verzameling projecten."

Er hoort een oordeel bij dat de cursus er zelf aan verbindt. Een programma optuigen voor projecten die net zo goed onafhankelijk van elkaar zouden kunnen slagen, is volgens dat materiaal zelf een vorm van slechte tailoring, omdat het bestuurslagen toevoegt zonder dat daar een bestuurbaar, gedeeld doel tegenover staat.

Die toets is per mechanisme te stellen, en dat is wat dit artikel ervan maakt. De vraag is niet of er een raamwerk nodig is, maar welke baat wegvalt zodra deze ene laag er niet is. Haal de gezamenlijke planning weg, en de afhankelijkheid tussen twee teams komt aan het licht op de dag dat er een team stilvalt. Haal de gezamenlijke backlog weg, en er is niemand die kan zeggen welk van twee teams de schaarse specialist krijgt. Is die zin voor een mechanisme niet af te maken, dan is dat mechanisme daar niet nodig.

De toets kan ook de andere kant op uitvallen, en dat is wat hem bruikbaar maakt. Bij vijf teams die elk hun eigen klant bedienen en elkaars werk niet nodig hebben, is het antwoord dat zo'n laag slechte tailoring is. Dat blijft het antwoord wanneer de klant erom vraagt, wanneer het budget rond is, en wanneer degene die de laag zou inrichten daarvoor betaald zou worden.

Wat er met het raamwerk is

Er hoort een belang bij de beweringen hierboven, en dat gaat voorop. Ik leid op in het raamwerk dat hier uit elkaar is gehaald, en ik heb daar inkomen uit. Dat maakt elke uitspraak erover in twee richtingen verdacht: relativeren leest als koketterie, verdedigen leest als eigenbelang. Er is geen voorzichtiger formulering die daaraan ontsnapt, en neutraliteit veinzen zou het erger maken, want de bronregel onder elk artikel op deze site wijst naar hetzelfde lesmateriaal.

Met dat belang op tafel blijft de bewering staan, met de reikwijdte erbij. Ik heb dit raamwerk dertig delen diep van binnenuit gelezen, en geen enkel ander op dat niveau. Dat maakt mij bruikbaar om te zeggen welk coördinatieprobleem het beschrijft en met welk mechanisme het dat beantwoordt, en ongeschikt om te zeggen of iets anders hetzelfde probleem beter oplost. Die vraag staat in dit stuk daarom niet.

Wat er verder over te zeggen valt is kort. Het materiaal beschrijft mechanismen en onderbouwt ze met een redenering, en het bevat in dertig delen geen enkele meting waaruit blijkt dat een organisatie die ze invoert er beter van wordt. De aanbeveling tot terughoudendheid staat er bovendien zelf in: het noemt het een veelgemaakte fout om bij de eerste schaalvraag meteen naar de volledige configuratie te grijpen, en adviseert klein te beginnen.

Wie de vier mechanismen los installeert, met per stuk een afhankelijkheid die hem rechtvaardigt, houdt iets over dat op een trein lijkt zonder de naam en zonder de certificering. Dat is geen bezwaar, en het is ook geen omweg naar de aanbeveling om het raamwerk dan maar in zijn geheel te nemen. Het is wat er gebeurt wanneer je per laag vraagt welke baat wegvalt als hij er niet is: je komt uit bij de mechanismen die dat materiaal al beschreven had, en bij de vraag welke ervan je op dit moment kunt rechtvaardigen.

Waar dit ophoudt

Waar het omslagpunt ligt, in aantal teams of in aantal afhankelijkheden, beantwoordt dit artikel niet.

Het materiaal geeft één maatvoering, en dat is die van de trein zelf: vijf tot twaalf teams, elk vijf tot elf mensen. Dat is de bandbreedte waarbinnen die structuur is beschreven. Het materiaal leidt daar geen drempel uit af, en nergens in dertig delen staat bij welk aantal teams of bij welk aantal afhankelijkheden losse mechanismen niet meer volstaan.

Het geval van dit artikel zit bovendien op de ondergrens van die bandbreedte. Vijf teams is het kleinste aantal waarvoor die structuur is beschreven, en daarmee het geval waarin de vraag of je haar in haar geheel nodig hebt het scherpst staat. Een getal daarvoor verzinnen zou stelliger zijn dan de bron, en op deze site zijn al uitspraken teruggedraaid die stelliger waren dan hun bron.

De toets uit de programmacursus werkt wel zonder drempel, want die vraagt niet hoeveel teams er zijn maar welke baat er wegvalt. Wie hem per mechanisme stelt, heeft geen getal nodig om te beginnen. Die werkwijze zegt nog steeds niet waar het omslagpunt ligt.

Dat antwoord brengt iemand mee die een organisatie op die grens heeft zien zitten. Wie dat heeft meegemaakt kan erbij zetten wat er als eerste ging schuiven: het aantal teams, het aantal afhankelijkheden, of iets anders dan die twee. Het onderwerp bij dit artikel staat daarvoor open.