Brooks Law - aantal communicatielijnen

Wat is Brooks Law?

In Agile, Basics by PeterLeave a Comment

Leestijd: 6 min.

De Wet van Brooks (Brooks Law) is een principe dat beschrijft dat het toevoegen van mankracht aan een vertraagd softwareproject de oplevering nog later maakt. Het toevoegen van mensen aan een team maakt de oplevering dus langer i.p.v. korter. Dit is precies het tegenovergestelde wat men vaak denkt.

Wat heeft dat nu voor impact op agile werken? We weten toch dat teamgrootte bepalend is. Alle frameworks en agile methodes geven een ideale teamgrootte aan.

De achterliggende reden is iedereen wel bekend: toename complexiteit door communicatie. Maar hoe dit nu precies in elkaar zit, blijkt voor veel agile teams een vraag. Wist je overigens dat daar een rekenformule voor is om de ideale teamgrootte te onderbouwen? In dit artikel de Wet van Brooks.

Leiderschap dilemma bij achterstanden

Stel je nu eens voor dat je als leider een ontwikkelteam met 9 mensen aanstuurt dat achterloopt met een belangrijke activiteit. Beeld je eens in dat de hele organisatie naar je kijkt, want de belangen zijn groot.

Tot nu toe ben je succesvol geweest en onder jouw bezielende leiding ging eigenlijk alles goed. Trots was je toen je deze belangrijke opdracht kreeg, goed voor je carrièrepad. Die trots is inmiddels al lang verdwenen, de opdracht is een blok aan je been. Je maakt je inmiddels echte zorgen, want de achterstand wordt steeds groter. Opnieuw aankomen bij het topmanagement met lege handen lijkt je geen goed idee. Als leider weet je eigenlijk niet zo goed wat je moet doen.

Dan komt er een teamlid aanlopen en zegt: ‘met 4 man extra kunnen we het fixen’. Dan komt er echter een ander teamlid aanlopen en zegt: ‘met 3 man minder in het team gaan we de oorspronkelijke datum redden’.

De vraag is dus, wat doe jij als leider?

Vermoedelijk zal jouw reactie voor een belangrijk deel afhankelijk zijn van jouw omgeving. Wie jij bent en welke context er is. Daartoe worden twee omgevingen geschetst.

Politieke omgeving

In een politieke omgeving zal je kunnen kiezen voor het toevoegen van mensen. ‘Ik heb gehandeld, ik heb er alles aan gedaan, ik heb zelfs mensen toegevoegd’. Daarmee dek je je alvast in, want je positie staat onder druk.

Agile omgeving

In een agile omgeving, vraag je je minimaal af waarom het teamlid zo stellig beweert dat je het met minder mensen zou kunnen redden. Dat voelt onnatuurlijk of zelfs tegenstrijdig aan.

Als je de Wet van Brooks kent (en geloofd) sta je vermoedelijk open voor het agile teamlid. Je luistert naar de argumentatie van het teamlid en als de juiste woorden overtuigend worden gebracht ga je mee en verklein je het team.

Volgens de wet van Brooks is het aannemelijk dat zou moeten kiezen voor minder mensen, in ieder geval niet uitbreiden. Hoe kan dat nu? Dat staat in dit artikel.

Wie is Fred Brooks?

Fred Brooks is een auteur van het book Mythical Man-Month. In 1975, ver voordat men agile ging werken beschreef hij een fenomeen wat hij in zijn dagelijkse werk als IBM ontwikkelaar ervoer.

The Mythical Man-Month - Frederick Brooks - cover

Hij verwonderde zich over het feit dat er mensen werden toegevoegd bij achterlopende projecten, waarna het niet beter ging maar de opleveringsdatum zelfs nog verder naar achter schoof.

Brooks stelde in zijn boek dat het toevoegen van mensen aan samenwerkingsprojecten het project altijd later zou maken.

Dit was te wijten aan:

1. Inwerktijd om de nieuwe mensen op de hoogte te brengen

De stelling hierbij is dat het tijd kost om nieuwe members te trainen voordat ze op gelijke productie snelheid zijn, het trainen gaat ten koste van de beschikbare tijd van de al aanwezige ontwikkelaars.

2. De communicatieoverhead neemt exponentieel toe met het aantal mensen.

De stelling is dat het aantal overleggen en de verscheidenheid van overleggen expotioneel toeneemt.

Dat wist hij te onderbouwen o.b.v. zijn ruime ervaring en te bewijzen met een simpele rekenformule. Sindsdien heet dit fenomeen Brooks’ Law.

Brooks Law - personen, tijd en kosten

Brooks Law

Brooks stelt dat extra mensen toevoegen de complexiteit exponentieel kan vergroten. Maar, dat is afhankelijk of het een lineair of sequentieel proces betreft.

Zie de rollen die mensen innemen eens als knooppunten, elk knooppunt is verbonden met andere knooppunten. Tegenwoordig herken je deze beschrijving direct als een netwerk.

Brooks Law - aantal communicatielijnen

Bij Brooks’ Law gaat het alleen om samenwerkingsverbanden in het netwerk van het team, waarbij extra mensen (knooppunten) de complexiteit exponentieel vergroten.

Een simpel voorbeeld: als 1 teammember geheel zelfstandig 2 dossiers per dag kan verwerken, dan kunnen 5 zelfstandige members gezamenlijk 10 dossiers doen. Dit is een voorbeeld van parallel proces, dat kan overigens alleen als geen van de members een andere member nodig heeft om het werk af te ronden.

Bij een sequentieel (opvolgend) proces, kunnen stadia echter niet parallel lopen. Als de ene member iets doorgeeft aan de ander (bijvoorbeeld: kennis of een dossier), kan de ontvanger pas starten als het ‘binnen’ is. Er is dan sprake van afhankelijkheden tussen de members. Dit is in de meeste agile teams het geval.

In 1975 hanteerde Fred Brooks volgende voorbeeld: ‘het duurt negen maanden om een baby te maken, hoeveel vrouwen je ook op het project zet’. Dit bedoelde hij hopelijk niet vrouwonvriendelijk, hij hanteerde het slechts als bewijs dat sommige processtappen niet versneld kunnen worden. Zwangerschap is immers een voorbeeld van een sequentieel proces.

De formule van het aantal connecties

Het aantal connecties kan worden bepaald met behulp van de volgende formule:

Aantal connecties = N(N-1)/2

Waarbij N staat voor het aantal personen in het samenwerkingsverband. Een team of project met het aantal leden.

Uit deze berekening blijkt dat het na 9 personen het aantal connecties al vrij hoog begint te worden. En dat is nu precies de reden waarom Scrum als teamgrootte 6 personen +/- 3 hanteert. Onderstaande afbeelding toont dit.

Brooks Law - Formule connecties - grafiek

Bovenstaande formule zie je in meerdere wetenschappen en agile methodieken terug. Vrijwel altijd vertaald in het advies om de teamgrootte niet te groot te maken. Daar vindt altijd een uitgebreide verklaring plaats, maar bovenstaande grafiek zegt je eigenlijk al genoeg.

Het leiderschapsdillema reloaded

Terugkomend op de vraag die eerder gesteld was, ‘wat zou jouw reactie als leider zijn’ als de aangegeven opleverdatum niet wordt gehaald?

Vanzelfsprekend heb je juist gekozen? Het is immers jouw keuze, in jouw context! Stel nou eens dat je hebt gekozen om extra mensen toe te voegen. Je ziet helaas dat het project niet sneller gaat. Vanzelfsprekend vraag je aan het team waardoor dit komt:

Wat denken jullie dat de reden is?

Je hoort het vermoedelijk niet letterlijk, maar de strekking zal zijn dat de nieuwe leden nog niet voldoende productie leveren en dat hun begeleiding meer tijd kost dan verwacht.

Zou nu als je terugkijkt opnieuw extra leden toevoegen?

Dat is wederom de vraag voor de leider, maar eigenlijk veel meer voor het team. Heb jij als leider of team toen het probleem ontstond gezamenlijk wel een goede analyse gemaakt, wat was nu echt de oorzaak van de vertraging?

Hoe kijk je er tegenaan nu je Brooks Law kent?

Vanzelfsprekend werkte je al agile en heb je een weloverwogen beslissing genomen. Je bent gegaan voor minder leden, want je was op de hoogte van Brooks Law. Overigens was het antwoord ‘niet verminderen’ ook goed, als het volledige team hier absoluut niet in gelooft. Toch geeft het te denken als een team member het lef heeft om jou te benaderen met een heel andere gedachte, een gedachte die je herkent in Brooks Law. Ook het antwoord ‘niet uitbreiden’ was mogelijkerwijs ook een goede strategie geweest.

Vanzelfsprekend is door agile werken al veel veranderd, de situatie is anders dan in 1975. Toch zijn er ook nu al een paar aandachtspunten:

  • Je werkt agile om dit soort problemen vroegtijdig te herkennen, waarbij het agile team zelfstandig met oplossingen dient te komen. Als dit niet gebeurt, bijvoorbeeld door beperkte teamvolwassenheid, zal je als leider of coach tijdig het gesprek dienen aan te gaan.
  • Expertise van individuele leden is mede bepalend voor het succes van het team. Wat doe je dus aan opleidingen en trainingen? Wacht niet totdat het fout gaat! Lees het artikel: Wat is het 70:20:10 model?
  • Het team zal continues integration, test gedreven ontwikkeling en iteratieve ontwikkeling moeten toepassen om de communicatielijnen tussen de ontwikkelaars onderling aanzienlijk te verbeteren. Daarmee zorgen ze gelijkertijd ook voor een betere schaalbaarheid.
  • Niet voor niets hanteert agile werken een Sprint Planning waarbij frequente terugblikken, acties en de snelheid van het team besproken dient te worden.

Span of control

In de managementleer van voorgaande eeuw was voor een hiërarchische organisatie de Span of Control van een manager een belangrijke maatstaf. Dit staat voor het aantal aan te sturen personen. Daarvoor hanteerde men vaak ook maximaal 9 connecties voor. Ook toen wist men al dat communicatie en aantallen verbindingen beperkingen met zich mee kan brengen.

Als je dit verder trekt naar agile werken is het hanteren van een team ontwikkelaars groter dan 10 members eigenlijk al een onmogelijkheid.

Waarom? Volgens De wet van Brooks lukt het gewoonweg niet om alle interne connecties op orde te krijgen. Vanzelfsprekend zijn hier fantastische uitzonderingen te benoemen, als je echter inzoomt zal je regelmatig zien dat er sprake is van een groot lineair component in de samenwerking.

Je zult wellicht al hebben ervaren dat alle scalings methodieken veel aandacht besteden aan een goede communicatie strategie. Ook daar let men vooral op het aantal knooppunten. De Open Space Technology biedt daar bijvoorbeeld mooie aanknopingspunten voor.

Tot slot

De wet van Brooks zegt niet dat je geen mensen moet toevoegen aan een team bij vertragingen. Het zegt alleen dat je vertraging zult oplopen.

Een vertraging kan echter een bewuste keuze zijn als je jouw team versterkt met members die kwalitatief hoogstand werk zullen gaan leveren en/of een belangrijke rol in het team gaan innemen.

De keuze die je maakt om een team aan te passen is context afhankelijk, maar..

één deadline niet halen is in de meeste gevallen minder ernstig, dan een structureel probleem niet aan te pakken.

Mocht je nu ooit in een situatie terecht komen, waarbij je je afvraagt of je mensen moet toevoegen aan een team dat achterloopt op de planning. Dan is volgens Brooks de primaire vraag: ‘Is er sprake van een lineair of sequentieel proces?’ Het antwoord hierop bepaald sowieso de eerste mogelijkheden.

Met De wet van Brooks zal je als leider of coach een ander gesprek met je team kunnen hebben. Waarbij je vooral moet de waarom-vraag moet stellen. Hanteer bijvoorbeeld eens de 5w’s of maak bij een complexere situatie een Ishikawa Diagram. Voor teamleden is het ook goed om bijvoorbeeld eens stil te staan bij de benodigde overleg- of begeleidingstijd.

Leave a Comment