De belangrijkste vraag over agile schaling
We horen het van bijna elk groot bedrijf waarmee we samenwerken: "We hebben een agile scaling framework nodig." Wanneer 50 of meer developers moeten samenwerken, is het gebruik van een scaling framework inderdaad voordelig. Maar er blijft één vraag onbeantwoord. Een onuitgesproken, onbetwiste aanname hangt als een spookbeeld boven elke scaling-aanpak. Voordat we die vraag stellen, bekijken we eerst waarom deze vraag beantwoord moet worden.
Een complex product ontwikkelen
Complexe systemen zijn – al vanwege hun definitie – complex. Een veelvoorkomende aanname is dat Divide+Conquer (D+C) een goede aanpak is om complexe problemen op te lossen: we delen een groot probleem op in veel kleine deelproblemen, verdelen deze en voegen de oplossingen weer samen. Dat klinkt ook veelbelovend.
Een schalingsframework kun je dan inzetten om de effectiviteit van D+C te maximaliseren.
Laten we beginnen met de randvragen om zo tot de kernvraag te komen:
Hoe definieer je het probleem?
Wanneer je begint met de ontwikkeling van een groot product, heb je allereerst een behoefte – en je wilt een product bouwen dat in die behoefte voorziet. Het is eigen aan productontwikkeling dat de oplossing die aan de behoefte voldoet, nog niet bestaat.
Is het probleem überhaupt goed beschreven? Is al voldoende duidelijk waar de inspanningen naartoe gaan? Is het domein van de uitdaging al zo helder dat je D+C zinvol kunt toepassen?
Wat is echt het probleem?
Als je een productontwikkeling organiseert, ga je er vaak gewoon van uit dat de behoefte duidelijk is en de rest "gewoon werk" is.
Maar wat als zelfs de vraag waarop de planning was gebaseerd, al verkeerd was? Wat als het plan mislukt en je het verkeerde antwoord najaagt? Helpt het dan als er meer mensen aan de verkeerde dingen werken?
Waar zit het probleem eigenlijk?
De basisaanname van agile schaling: "Het hoofdprobleem is meer werk dan weinig mensen aankunnen." Zoals ook in een ander artikel beschreven, is het hoofdprobleem met veel werk dat veel werk nog meer werk veroorzaakt! Daarbij gaat het om niet-waardetoevoegende werkzaamheden zoals coördinatie, task-switching, meetings en dergelijke.
Heb je er al eens over nagedacht hoe groot het aandeel waardetoevoegend werk aan het product is ten opzichte van het aandeel niet-waardetoevoegend werk voor het bedienen van processen in jouw organisatie? Hoeveel tijd besteden je developers door de complexiteit van jullie structuren aan coördinatie? Ligt jullie focus op het leveren van producten of het volgen van processen? Wat gebeurt er met de overhead als je jullie processen uitbreidt? Wat gebeurt er met de waardetoevoegende ontwikkeltijd?
Is het probleem echt zo groot?
Bij agile schaling ga je er simpelweg van uit dat je veel mensen nodig hebt om het product te bouwen dat je van plan bent. De volgende vraag is dan hoe je die mensen optimaal organiseert.
Wist je dat Google in de eerste jaren door twee mensen werd ontwikkeld? En Facebook door één?
Is jouw product echt zo groot dat het Google en Facebook in de schaduw stelt? Ga je er echt biljoenen mee verdienen? Is jouw begrip en aanpak daadwerkelijk optimaal?
Helpt veel echt veel?
Het boek „The mythical man-month", ruim 40 jaar geleden geschreven door Frederick P. Brooks, heeft het idee „Hoe meer mensen aan een product werken, hoe sneller het klaar is" allang weerlegd. Toch geloven veel bedrijven tot op de dag van vandaag dat „Agile Scaling" de oplossing is voor de „Mythische Man-Maand". Zoals eerder genoemd, zijn geweldige producten door weinig mensen ontwikkeld – en meer mensen creëren weliswaar meer werk, maar geen hogere meerwaarde!
Zou je niet met minder ontwikkelaars en minder werk een betere oplossing kunnen vinden? Zou het echt langzamer gaan als er minder mensen bij betrokken zijn?
En zo komen we na zoveel vragen bij de kritische kernvraag:
Is "agile schaling" echt nodig?
Denk eens na over de volgende punten:
Hebben de developers 100% de beste kennis om een oplossing te leveren?
Beschikken ze over 100% de best mogelijke technologie om problemen op te lossen?
Focussen de developers zich voor 100% op het leveren van maximale meerwaarde?
Is elke activiteit voor 100% waardetoevoegend?
Is het geleverde werk voor 100% effectief?
Wanneer er meer mensen bijkomen, gaan deze percentages doorgaans niet omhoog. Ze dalen.
Als je deze percentages bij elkaar optelt, is het resultaat vaak schokkend. Misschien heb je 10 mensen die slechts 20% van hun potentieel kunnen benutten – terwijl 3 mensen die 80% van hun potentieel kunnen ontplooien, sneller vooruit zouden komen!
Als 100 ontwikkelaars beperkt zijn tot 5% van hun potentieel, zou misschien één enkel team effectiever zijn dan zij allemaal!
Heb je al alle mogelijkheden benut om met minder meer te bereiken?
Alleen wanneer al deze vragen met "Ja" beantwoord zijn – dan is het antwoord op de kernvraag ook "Ja". Daarvoor zul je je problemen – en niet je probleemoplossing – opschalen!
