Van één naar vijf developers: wat verandert er per stap

Groei één developer tegelijk en neem de volgende pas als de vorige zelfstandig draait. Met twee developers heb je reviewregels nodig, bij drie moet iemand het werk verdelen en bij vier of vijf heb je een lead nodig die dagelijks technische keuzes maakt. Sla je zo'n stap over, dan merk je dat aan wachtrijen en aan code die niemand meer overziet.

Ik ga uit van een team op afstand, zoals wij dat met developers in Servië opzetten. Het meeste geldt ook op kantoor.

Eén developer: alles loopt via jou

Met één developer ben jij de productowner, de reviewer en de vraagbaak. Dat werkt zolang jij er bent. Ga je twee weken op vakantie, dan staat het werk stil of gaat de developer gokken.

Het risico in deze fase is kennis die alleen in jouw hoofd en dat van de developer zit. Gebruik deze periode om de basis op te schrijven: hoe draai je het project lokaal, hoe deploy je, wie heeft toegang tot wat? Een goed ingerichte eerste twee weken helpen daarbij, zie een remote developer onboarden.

Geef de eerste developer een duidelijk afgebakend deel van het product. Dan zie je snel of het werkt, en heeft die persoon iets waar hij eigenaar van is.

Wanneer je de tweede developer neemt

Neem de tweede developer als de eerste zelfstandig tickets oppakt en oplevert zonder dat jij elke dag hoeft bij te sturen, en als er werk klaarligt waarvoor alleen nog handen nodig zijn. Ligt het werk stil omdat jij niet aan specificeren toekomt, dan maakt een tweede developer dat probleem groter.

Met twee developers kan de een het werk van de ander reviewen, en is er een back-up als iemand ziek is of vrij heeft. Nu krijg je problemen die je eerder niet had: twee stijlen in één codebase, merge conflicts, discussie over naamgeving. Leg daarom vast hoe je reviewt, hoe groot een pull request mag zijn en wat de linter en de tests automatisch afvangen. Erik schreef daar meer over in code review op afstand.

Drie developers: iemand moet het werk verdelen

Met drie mensen lopen er meerdere dingen tegelijk, en prioriteren wordt een taak op zich. Wie pakt wat op? Wat gaat voor als er een bug in productie zit?

Bij deze stap gaan vooral de tickets mis die tot nu toe in jouw hoofd zaten. Twee developers konden nog bij jou navragen wat je bedoelde. Doen drie developers dat, dan kost het je een groot deel van je dag. Schrijf tickets daarom zo dat iemand zonder jou kan beginnen, met context en acceptatiecriteria. Een korte stand-up per dag laat zien wie waar vastzit.

Plan in deze fase ook een vaste refinement, een keer per week. Dan ligt er werk voor de komende twee weken klaar en hoeft niemand te wachten.

Vier of vijf developers: je hebt een lead nodig

Het aantal lijnen tussen mensen groeit sneller dan het team. Tussen twee mensen is er één lijn, tussen drie zijn het er drie en tussen vijf al tien. Tel jezelf mee, en bij vijf developers zijn het er vijftien.

Rond vier of vijf developers is dat te veel om naast je andere werk te dragen. Dan heb je iemand nodig die dagelijks technische keuzes maakt, de belangrijkste reviews doet en nieuwe mensen inwerkt. Dat kan een van de developers zijn die daar klaar voor is, of een fractional CTO die een paar dagen per maand meedenkt en de lead begeleidt. Hoe je die rollen verdeelt, staat in fractional CTO en remote team: wie doet wat.

Zonder lead neemt het team beslissingen die nergens staan. Twee developers lossen hetzelfde probleem op twee manieren op, en de architectuur loopt langzaam uit elkaar. Benoem de lead daarom voordat de vijfde developer start.

Wat je per stap vastlegt

• Bij één developer: hoe je de omgeving opzet, hoe je deployt en hoe je toegang regelt.
• Bij twee: reviewregels, de maximale grootte van een pull request, linting en tests in de pipeline.
• Bij drie: een vast format voor tickets, een definition of ready en een wekelijkse refinement.
• Bij vier of vijf: wie de lead is, welke beslissingen die zelf neemt en waar architectuurbeslissingen worden opgeschreven.

Elk document hoeft maar een pagina te zijn. Het moet vooral bestaan voordat de volgende developer begint, zodat die het kan lezen in plaats van het aan jou te vragen.

Hoe snel je kunt groeien

Mijn advies is om elke nieuwe developer een paar weken zelfstandig te laten draaien voordat de volgende begint. Dan zie je per stap wat er breekt, en los je het op terwijl het nog klein is. Twee mensen tegelijk laten starten kan, als er al een lead is die het inwerken op zich neemt.

Bij ons lopen contracten per maand. Je kunt dus per maand een developer toevoegen of afschalen, en je kiest zelf wie er in je team komt. De eerste twee weken zijn een proef: werkt het niet, dan betaal je niets. Wat een remote developer kost, staat op de pagina over een remote team opbouwen.

Wanneer je beter nog niet groeit

Soms moet je eerst je proces repareren. Je herkent het aan pull requests die dagen blijven liggen, aan minder dan een week werk dat klaarligt, of aan bugs die terugkomen terwijl ze al eens waren opgelost. Of je merkt het aan jezelf, omdat je elke dag uren kwijt bent aan vragen beantwoorden.

In die gevallen helpt een extra developer niet. Los eerst het knelpunt op, met betere tickets, kleinere pull requests of een lead, en groei daarna pas verder.