10 voorwaarden voor schaalbaarheid die je moet kennen voordat je opschaalt

Als je lang genoeg in de softwareontwikkelingsbranche werkt, heb je deze nachtmerrie waarschijnlijk meegemaakt:

1. De klant wordt in een onrealistisch kort tijdsbestek een groot aantal functies beloofd (waar niemand de moed heeft om bezwaar tegen te maken).
2. Later, wanneer de deadline gevaarlijk dichtbij komt, besluit iemand met macht om meer teams op het probleem te zetten om de deadline te halen.
3. Alles begint uit elkaar te vallen.

Komt dit bekend voor?

In dit artikel leg ik uit wat je moet doen om te voorkomen dat je opnieuw in die nachtmerriesituatie terechtkomt (of, als je het geluk hebt gehad dit nog niet mee te maken, om die situatie helemaal te voorkomen).

Mijn inzichten in dit artikel zijn afkomstig van het opschalen van softwareontwikkelingsteams, maar je kunt de fundamentele theorie toepassen op het opschalen van een bedrijf of het uitbreiden van een team in elke branche. Je zult dit zelfs nuttig vinden als je een van de kant-en-klare schaalbaarheidsraamwerken toepast—Large Scale Scrum (LeSS), Scrum@Scale, SAFe.

Dat komt doordat ik me richt op verschillende belangrijke aspecten van schaalbaarheid die in die methodologieën nooit worden genoemd—de fundamentele waarheid over de aard van opschalen die vaak wordt vergeten of genegeerd.

De fundamentele wet van opschalen

De fundamentele wet van opschalen is een empirische observatie van wat er in projecten gebeurt wanneer ze worden opgeschaald:

Opschalen versterkt het slechte en maakt het goede moeilijker.

Ik heb de formulering bedacht, maar ik ben noch de enige, noch de eerste die dit inzicht heeft geformuleerd.

Laten we met enkele voorbeelden van schaalbaarheid bekijken wat de wet in de praktijk betekent.

1. Voorbeeld: communicatie en schaalbaarheid

Het eerste en meest voor de hand liggende voorbeeld is communicatie. Het is algemeen bekend dat wanneer het aantal mensen in een project toeneemt, ook het aantal communicatiekanalen toeneemt. Als communicatiekanalen om te beginnen niet goed genoeg zijn, maakt opschalen het probleem erger.

Aan de andere kant zal opschalen, als de communicatiekanalen aanvankelijk goed zijn, enkele uitdagingen met zich meebrengen die niet alleen het gevolg zijn van het toegenomen aantal mensen, maar ook van hun geografische spreiding. Vaak worden nieuwe teams op verschillende locaties gevormd, waardoor veranderingen in communicatiekanalen nodig zijn—bijvoorbeeld de overstap van vergaderingen van aangezicht tot aangezicht naar videoconferenties of de vervanging van een whiteboard door een elektronisch hulpmiddel.

2. Voorbeeld: continue integratie/continue levering en schaalbaarheid

We zien de fundamentele wet van opschalen ook terug in pijplijnen voor continue integratie (CI) en continue levering (CD). Wanneer er maar één team is, zijn de zaken vrij eenvoudig.

Bij de overgang van één naar twee teams worden de CI- en CD-systemen ingewikkelder—meestal geldt dat wanneer er n teams zijn, het aantal CI-pijplijnen doorgaans n+1 bedraagt (één pijplijn per team, plus één voor integratie). Dit heeft duidelijke gevolgen voor het beschikbaar stellen van omgevingen en voor de coördinatie tussen teams.

3. Voorbeeld: feedbacklussen en schaalbaarheid

Een laatste voorbeeld: feedbacklussen. Grotere projecten hebben langere feedbacklussen. Daardoor wordt het veel moeilijker om het systeem iteratief te verfijnen, waardoor de kans groter wordt dat het verkeerde product wordt gebouwd.

Dit zijn slechts drie voorbeelden van enkele uitdagingen die door opschalen worden geïntroduceerd. Ik weet zeker dat je er nog veel meer kunt bedenken.

Laten we aannemen dat je bereid bent de bijbehorende afwegingen te accepteren. Het volgende wat je nodig hebt, is dat je project aan enkele belangrijke voorwaarden voldoet om de schaalbaarheid ervan te bewijzen.

10 voorwaarden voor opschalen

Of je nu wel of geen schaalbaar bedrijf, project of team hebt, hangt af van verschillende hieronder genoemde voorwaarden. Als je aan deze voorwaarden voldoet, beschik je over een hoge schaalbaarheid. Omgekeerd neemt de kans op mislukking dramatisch toe als aan een van deze voorwaarden niet wordt voldaan.

1. De aanwezigheid van duidelijke, gedeelde doelen

Dit zou vanzelfsprekend moeten zijn, maar naar mijn ervaring komt het ontbreken van duidelijke, gedeelde doelen buitengewoon vaak voor. Zonder deze doelen zullen de teams in verschillende richtingen trekken, waardoor het moeilijker wordt om iets nuttigs op te leveren.

2. Het gebruik van geschikte meetwaarden

Hoe groter het project, hoe belangrijker het is om de impact van de genomen beslissingen te kunnen meten. Heeft de toevoeging van een nieuw team bijvoorbeeld het vermogen van het project om resultaten te leveren verbeterd? Zetten we de teams zo zwaar onder druk dat de kwaliteit afneemt? Werken teams goed samen, of zitten ze elkaar in de weg?

Stay Ahead of What Deserves Your Attention

Get timely perspective on the shifts, decisions, and trade-offs shaping your role, plus practical resources you can put to work.

Create Free Account

Have an account? Log In

3. Een geschikte architectuur

Als de ‘vorm’ van het systeem niet overeenkomt met de structuur van de teams, zullen meer teams toevoegen de zaken alleen maar erger maken. Dit is een direct gevolg van de wet van Conway, een bekende empirische observatie die in de praktijk is bewezen.

4. Beschikbaarheid van management- en technische vaardigheden

Problemen die ontstaan door een gebrek aan vaardigheden zullen een versterkt negatief effect hebben naarmate het project groter wordt.

5. Goede communicatiekanalen

Hoe meer mensen erbij betrokken zijn, hoe meer communicatie er plaatsvindt. Succesvolle opschaling vereist gestroomlijnde communicatie.

6. Goede prioritering en planning

Een gebrek aan passende prioritering en planning is naar mijn ervaring een zeer veelvoorkomende factor bij het mislukken van projecten. Vooral wanneer er meer dan één team bij betrokken is, moeten prioriterings- en planningsactiviteiten rekening houden met het beperken van de gevolgen van vertragingen en een gebrek aan synchronisatie.

7. Goede inventarisatie en goed beheer van vereisten

Dit gaat hand in hand met prioritering en planning. Bovendien wordt het effect van onjuiste, verkeerd begrepen of onnodige vereisten versterkt naarmate het aantal teams groeit.

8. Werk van hoge kwaliteit

Hoe groter het project, hoe groter het negatieve effect van slechte kwaliteit. In sommige pathologische (en veelvoorkomende) scenario’s kunnen sommige fouten functies worden, omdat de terugkoppellussen om ze op te lossen zo lang kunnen zijn dat andere teams hun oplossingen al zo hebben ontworpen dat ze de fouten neutraliseren.

9. Beschikbaarheid van middelen

Meer teams hebben meer bureaus, computers, hulpmiddelen en omgevingen nodig.

10. Meedogenloze automatisering

Elke handmatige activiteit is een knelpunt waarvan de effecten erger worden naarmate het aantal mensen en teams toeneemt. Een (zeer veelvoorkomend) voorbeeld: handmatige testactiviteiten om er zeker van te zijn dat er geen regressies zijn geïntroduceerd vóór een productierelease. Naar mijn ervaring is dat een van de grootste knelpunten in elk project, maar vooral in projecten met meer dan één team.

Pas op voor voortijdige opschaling

Schaalbaarheid staat hoog op de agenda van startups en seriële ondernemers—en zij kunnen ons het een en ander leren over te vroeg opschalen.

Als je begint met opschalen voordat je echt aan de vereisten voor het succesvol opschalen van een bedrijf, team of organisatie hebt voldaan, krijg je wat de startupgemeenschap ‘voortijdige opschaling’ noemt.

Een eenvoudige definitie van voortijdige opschaling van serieel ondernemer Jim Pitkow:

Voortijdige opschaling: groeien in afwachting van de vraag in plaats van door de vraag gestuurde groei.

Een goede opschaling kost inderdaad tijd—en echte schaalbaarheid wordt gedreven door een daadwerkelijke behoefte aan schaalgrootte als gevolg van de vraag, niet door het kunstmatig opgelegde idee om simpelweg groter te worden en meer dingen sneller te doen.

De startupgemeenschap biedt enkele lessen die we kunnen meenemen naar onze teams en projecten wanneer we nadenken over de vraag of het tijd is om op te schalen. Hier zijn enkele statistieken uit het extra rapport van Startup Genome over voortijdige opschaling:

• Startups die op de juiste manier opschalen, doen er 76% langer over om op te schalen naar hun teamgrootte dan startups die voortijdig opschalen.
• 74% van de snelgroeiende internetstartups faalt door voortijdige opschaling.
• Startups die op de juiste manier opschalen, groeien ongeveer 20 keer sneller dan startups die voortijdig opschalen.

Als je geïnteresseerd bent in meer statistieken over ondernemerschap, bekijk dan ons onderzoek naar de meest ondernemende staten in Amerika.

Ben je echt klaar om op te schalen?

Als je project goed wordt geleid en aan de bovenstaande vereisten voldoet, zou je volgende vraag moeten zijn:

‘Aan hoeveel teams kunnen bijdragen die waarde toevoegen?’

We beantwoorden deze vraag in het volgende gedeelte.

Wat is de grens van schaalbaarheid? De wetten van Brooks en Amdahl

Het is algemeen bekend dat het toevoegen van meer mensen aan een softwareproject niet noodzakelijkerwijs leidt tot een hogere productiviteit.

In de meeste gevallen zal het toevoegen van meer mensen zelfs leiden tot een sterke productiviteitsdaling.

Fred Brooks deed deze observatie in zijn boek De mythische man-maand, wat bekend is geworden als de wet van Brooks:

“Het toevoegen van arbeidskrachten aan een vertraagd softwareproject zorgt ervoor dat het nog meer vertraging oploopt […] Het aantal maanden van een project hangt af van de sequentiële beperkingen. Het maximale aantal mensen hangt af van het aantal onafhankelijke subtaken. Op basis van deze twee hoeveelheden kunnen planningen worden afgeleid met minder mensen en meer maanden[…]. Het is echter niet mogelijk om haalbare planningen te maken met meer mensen en minder maanden.”

De tweede helft van het bovenstaande citaat is naar mijn mening het interessantst. Eigenlijk is het grotendeels de versie in gewone taal van de wet van Amdahl—een formule die de maximale theoretische versnelling van een gelijktijdig systeem geeft:

De wet van Amdahl

Versnelling = 1 / (s + p / n )

Waarbij:

s = percentage seriële taken

p = percentage parallelle taken

s + p = 1

n = aantal processoren (in ons geval: teams)

Een project met meerdere teams is in feite een soort gelijktijdig systeem waarin elk team een verwerkingseenheid is. In de praktijk stelt de wet van Amdahl dat de maximale hoeveelheid gelijktijdig werk wordt beperkt door de hoeveelheid serieel werk die moet worden uitgevoerd.

In gewone woorden betekent dit dat de zaken die in een bepaalde volgorde moeten worden uitgevoerd, beperkingen opleggen aan de hoeveelheid werk waaraan teams tegelijkertijd kunnen werken.

Wat is serieel werk in de context van softwareontwikkeling?

Je vraagt je misschien af welk soort werk serieel werk is dat gevolgen heeft voor softwareteams.

Hier zijn enkele voorbeelden (ik weet zeker dat je er nog veel meer kunt bedenken):

• Alle werkzaamheden aan integratie- en implementatiepijplijnen
• Het samenvoegen van softwarewijzigingen in code die door verschillende teams wordt gedeeld
• Elke vorm van synchronisatie—bijvoorbeeld een team dat afhankelijk is van opleveringen van een ander team voordat het verder kan werken
• Wachten op het beschikbaar stellen van middelen

De wet van Amdahl toepassen op het opschalen van teams

De onderstaande grafiek toont de gevolgen van de wet van Amdahl voor de productiviteit wanneer het aantal teams wordt opgeschaald.

We zien dat de productiviteit sublineair toeneemt naarmate het aantal teams stijgt—tot aan een piek, waarna de productiviteit weer afneemt.

Een illustratie van de wet van Amdahl: de doorvoer van opleveringen neemt toe met het aantal teams, maar slechts tot een bepaald punt—en dat is meestal niet wat managers hopen.

Als je maar één ding uit dit artikel onthoudt, laat het dan dit zijn:

Het vergroten van het aantal teams kan de doorvoer verhogen—maar slechts tot een bepaald punt.

Dus, wat is het ideale aantal teams voor een bepaald project?

Helaas zijn er geen vergelijkingen waarmee je vooraf het ideale aantal teams voor een bepaald project kunt berekenen. De enige manier is om een aantal projectstatistieken te gebruiken om zaken als productiviteit en kwaliteit te meten en te bekijken wat er gebeurt wanneer teams worden toegevoegd of verwijderd. Mijn aanbeveling is om klein te beginnen met één team van 3-6 mensen en alleen op te schalen wanneer en als dat nodig is.

Op een gegeven moment kom je er misschien achter dat je het maximale aantal teams al hebt bereikt, maar dat je project nog steeds niet aan zijn verplichtingen kan voldoen. Dan komen je vaardigheden op het gebied van prioritering en communicatie goed van pas, omdat je mogelijk moeilijke gesprekken met je klanten moet voeren.

Overwegingen rond de teamstructuur: functionaliteits- of componentteams?

Hoe hoort een nieuw team aan het project te werken? Stel jezelf om te beginnen de volgende twee vragen:

1. Zullen zij verantwoordelijk zijn voor het van begin tot eind ontwikkelen van voor klanten zichtbare functies, of voor het aanpassen van iets in het systeem om hun doel te bereiken?
2. Zullen zij verantwoordelijk zijn voor het werken aan een specifieke component die een deel van bepaalde voor gebruikers zichtbare functionaliteit biedt?

Als je #1 met ja hebt beantwoord, is het team een functieteam.

Als je #2 met ja hebt beantwoord, is het een componentteam.

Tips voor het kiezen van de juiste teamstructuur

Het kiezen van de juiste teamstructuur en teamorganisatie is erg belangrijk, maar niet eenvoudig. Momenteel lijken functieteams in de meeste situaties de voorkeursoptie te zijn. Die keuze is echter vaak gebaseerd op gewoonte of routine in plaats van op gegevens.

De realiteit is dat “het ervan afhangt”. Meer specifiek hangt het af van de architectuur van het systeem. Softwareprojecten volgen doorgaans wat bekendstaat als de wet van Conway—een empirische observatie van Mel Conway:

“Organisaties die systemen ontwerpen…zijn beperkt tot het produceren van ontwerpen die kopieën zijn van de communicatiestructuren van deze organisaties”

Met andere woorden: de “vorm” van de teamstructuur moet overeenkomen met de “vorm” van het systeem, anders zal het project met ernstige problemen te maken krijgen.

Daarom raad ik managers altijd aan om senior architecten en technische leiders te betrekken bij beslissingen over de teamstructuur—anders zijn managers in feite systeemontwerp aan het doen zonder zich daarvan bewust te zijn (en zonder over de juiste vaardigheden te beschikken). Dat kan op zijn beurt het risico op het mislukken van het project aanzienlijk vergroten.

Twee paradoxen van schaalbaarheid

Door mijn ervaring als consultant bij een aantal grootschalige projecten ben ik tot de conclusie gekomen dat projecten in de meeste gevallen om de verkeerde redenen opschalen.

Ik heb twee paradoxen bedacht die samenvatten wat ik in de praktijk heb gezien:

Eerste paradox van opschalen

De meeste projecten worden opgeschaald omdat ze niet voldoen aan de voorwaarden voor opschaling

Tweede paradox van opschalen

Projecten die aan de voorwaarden voor opschaling voldoen, hebben minder behoefte aan opschaling

De eerste paradox stelt dat projecten in de meeste situaties langzaam vorderen, simpelweg omdat ze niet goed worden beheerd.

De tweede stelt dat goed beheerde projecten minder behoefte aan schaalgrootte hebben, simpelweg omdat ze goed worden beheerd.

De productiefste projecten die ik heb gezien, hadden zelfs maar één of twee kleine teams en voldeden aan alle voorwaarden voor opschaling. Van alle grootschalige projecten waarbij ik betrokken ben geweest, heb ik er geen enkel gezien waarbij aan alle voorwaarden voor opschaling was voldaan. In feite hadden ze allemaal volop problemen bij het vervullen van een van die voorwaarden.

Als je betrokken bent bij een project dat problemen en vertragingen ondervindt, is de beste aanbeveling die ik kan geven: schaal de chaos af voordat je overweegt het project op te schalen.

Belangrijkste inzichten om je teams op de juiste manier op te schalen

Het opschalen van softwareteams is niet eenvoudig en moet uiterst zorgvuldig gebeuren. Voordat je vertrekt, volgen hier enkele laatste gedachten over het vinden van de meest effectieve manier om een softwareontwikkelingsteam op te schalen:

1. Als je werkt aan het vervullen van de voorwaarden voor schaalbaarheid, ontdek je misschien dat je het team klein kunt houden en alle problemen die met een grotere omvang gepaard gaan, kunt vermijden.
2. Aan de andere kant: als je project al groot is en met uitdagingen kampt, richt je dan eerst op het afbouwen van de chaos.

Dit zijn de eerste stappen die ik je aanraad te nemen nadat je dit artikel hebt gelezen:

1. Ontdek wat er in de praktijk gebeurt
2. Voer enkele meetgegevens in om de huidige situatie en de kwaliteit van de genomen beslissingen te kunnen beoordelen.