Yammer: Traditionele structuur van ontwikkelbedrijven is dood

Kris Gale, Vice President of Engineering bij Yammer, beweert dat kleine teams de sleutel zijn tot snelle productontwikkeling in grotere bedrijven. Hij onderzoekt de fijne kneepjes van het opbouwen van organisaties in productontwikkeling en legt uit hoe het bewust nemen van beslissingen tijdens een groeifase ervoor kan zorgen dat de dingen die een start-up uniek en bijzonder maken, niet verloren gaan. Uiteindelijk is het de taak van een technisch directeur om na te denken over hoe softwareontwikkeling georganiseerd en geoptimaliseerd kan worden.

Kleinere teams leveren sneller op

In het begin hanteerde het Yammer-team een vrij eenvoudige aanpak. De focus lag vooral op het product zelf en er werd niet veel nagedacht over de personeelsbezetting tijdens de groei van de organisatie. Naarmate het bedrijf bleef groeien, merkten ze echter dat de marginale productiviteitswinst bij elke nieuwe ontwikkelaar steeds kleiner werd door de toenemende overhead.

Tegelijkertijd werd het de rest van de wereld duidelijk dat Yammer bezig was iets groots te bouwen. Overal probeerden start-ups het product te kopiëren, en zelfs grote bedrijven brachten concurrerende producten op de markt. Bij Yammer was men zich ervan bewust dat er maar één marktdominant bedrijf kon zijn – en dat dat een ander zou zijn als ze niet wendbaar genoeg waren. Moderne webapplicaties moeten wendbaar en aanpasbaar zijn.

Om sneller te kunnen opleveren, nam Yammer de aanpak over om met kleine teams te werken. Maar dat betekent meer dan alleen een bedrijf in kleine teams opdelen. Als deze teams op welke manier dan ook beperkt worden bij het implementeren van code, zijn ze nutteloos. Ze moeten de vrijheid hebben om ook buiten de organisatie dingen gedaan te krijgen.

Specialisatie in kleine teams

Helemaal in het begin werden nieuwe features bij Yammer op basis van specialisatie verdeeld onder de drie ontwikkelaars. Dat ging er niet al te streng aan toe. Als er dus veel werk met Rails was, kon Gale een handje helpen, ook al was Rails niet zijn sterkste kant. Het doel moet zijn om vergelijkbare groepen te creëren die klein en gespecialiseerd zijn, maar geen pure silo's vormen, want verschillende problemen vereisen verschillende competenties (en verschillende ervaringen).

Seriële processen & grote technologiebedrijven

Deze aanpak werkte echt goed met drie ontwikkelaars. Maar toen het Yammer-team groter werd, bewoog men richting een meer traditioneel model voor organisaties in softwareontwikkeling, met een opdeling naar vakgebied. Er was dus een back-end-team, een front-end-team, een mobile-team enzovoort. Tegen het einde van 2010 werkten er niet meer slechts drie ontwikkelaars aan features, maar ongeveer 30. Maar waren ze ook tien keer sneller? Nee.

Volgens de wet van Amdahl over de parallelle uitvoering van programma's wordt de snelheidswinst van een programma bij het gebruik van meerdere processoren vooral beperkt door het sequentiële deel van het probleem [omdat de uitvoeringstijd daarvan niet door parallellisatie verminderd kan worden]. Voorbeeld: als je een programma hebt waarvan je slechts de helft kunt parallelliseren, zou je de snelheid zelfs met 100 processoren maar kunnen verdubbelen. Met nog eens 100 processoren zou dat niet veel veranderen. De tijd voor het seriële deel van de totale inspanning blijft dus altijd gelijk.

Mensen gaan er onterecht van uit dat bij softwareontwikkeling code wordt geschreven op basis van specificaties – maar dat klopt niet. De technische beslissingen zijn ook heel belangrijk – en niemand kan een ontwikkelbedrijf bouwen als hij dat gelooft.

Bij een typische middelgrote tot grote softwareontwikkelingsorganisatie heb je misschien een front-end-team, een back-end-team en eventueel een middleware-team. Deze teams hebben hun eigen codebase en een eigen manager die rapporteert aan een leidinggevende. Het punt is dat de organisatie en de architectuur van de code bij elkaar moeten passen.

Voordat leidinggevenden werk kunnen verdelen en delegeren, moeten ze eerst beslissen wat er precies gebouwd moet worden. Dan komen zulke vragen op: "Waar gaat het back-end-team aan werken?" en "Hoe sluit dat aan op het front-end-team?"

Als het werk echter, zoals net beschreven, vanuit de hogere managementlagen wordt ingedeeld en gedelegeerd, gaat het mis. Denk er eens over na. Want als degene die de code moet implementeren een probleem vindt in de specificaties, moet hij of zij een verbetervoorstel helemaal naar boven in de managementlaag indienen, dat vervolgens weer naar beneden moet worden doorgegeven. Dit proces vertraagt een product en brengt het uiteindelijk tot stilstand. Bovendien zien de ontwikkelaars in andere delen van de organisatie dit als een verstoring, omdat ze niet nauw samenwerken met de ontwikkelaar die de wijziging heeft voorgesteld. Ze begrijpen simpelweg de reden voor de wijziging niet.

Dat wilde men bij Yammer niet.

Het management zou geen ontwikkelbeslissingen moeten nemen

Je moet altijd mensen aannemen die beter en slimmer zijn dan jijzelf. Als je dat advies opvolgt, zou je dan niet juist die mensen beslissingen moeten toevertrouwen die je anders zelf had moeten nemen? Uiteindelijk is het de taak van de technisch leider om een organisatie op te bouwen en te bevorderen. Je zult je waarschijnlijk sneller dan gedacht niet meer alleen op het schrijven van code moeten richten, maar je focus op de organisatie zelf moeten leggen.

Ik denk niet dat je een product moet bouwen. Ik denk dat je een organisatie moet bouwen die een product bouwt.

Wees uiterst voorzichtig met het vertrouwen van managers bij ontwikkelbeslissingen. Eigenlijk zou je al deze beslissingen naar beneden moeten doorgeven aan de mensen die ze ook daadwerkelijk moeten uitvoeren. Het is een duidelijk alarmsignaal als managers de enigen zijn die beslissingen nemen voor meer dan 30 – 40 mensen.

Hoe moet je dan features bouwen?

Als er bij Yammer een feature wordt gebouwd, moet altijd een van de drie belangrijkste metrics verbeterd worden:

• Viraliteit
• Engagement
• Monetisatie

In principe wil men bij Yammer features bouwen die klanten aantrekken, vasthouden en die door hen worden gekocht. Ook al zien jouw belangrijkste kengetallen er anders uit, je zou ook zeker moeten beginnen met het communiceren van een aantal hoofddoelen door de hele organisatie. Anders kun je niet alle medewerkers van je bedrijf in staat stellen om goede beslissingen te nemen.

In traditionele organisaties schrijven projectmanagers specificaties op basis van hun ideeën. Bij Yammer is dat anders. In plaats van een starre specificatie te schrijven over wat er gebouwd moet worden, wordt een specificatie gezien als startpunt voor een cross-functioneel team, dat de specificatie vervolgens kan uitwerken. Als de specificatie al te lang is of er te veel wordt voorgeschreven, moet je oppassen. De betrokken ontwikkelaars moeten de beslissingen voor een feature kunnen begrijpen, zodat ze de code op de meest efficiënte en effectieve manier kunnen implementeren.

De "twee-en-tien"-regel

De belangrijkste vuistregel bij Yammer luidt: twee tot tien mensen, twee tot tien weken. Er zijn dus eigenlijk geen projecten die groter of ingewikkelder zijn. Er is een niet-lineair verband tussen de complexiteit van een project en de afsluitende integratiefase aan het eind. Bij alles wat langer dan tien weken duurt, wordt de duur van de afsluitende fase onevenredig lang.

Als je je aan deze regel houdt, dwingt het je bovendien om vaker te releasen, aannames te testen en je niet te veel bezig te houden met fouten. Het lijkt op de Lean Startup-aanpak en als je het wilt uitproberen, moet je het in je bedrijf vastleggen.

Je moet een gevoel van urgentie ontwikkelen. Zeer lange projecten zijn vaak de oorzaak dat ontwikkelaars het eigenlijke doel uit het oog verliezen. Het is net als bij wandelen. Als je vertrekt, zit je nog vol energie, verheug je je op de wandeling en kom je behoorlijk snel vooruit. Na verloop van tijd wordt je lichaam echter moe en kun je niet meer zien waar je begonnen bent of waar je naartoe gaat. Als je op dat punt bent aangekomen, heb je een sterke wil nodig om jezelf te motiveren om door te gaan. Helaas hebben veel organisaties hun ontwikkelaars bij de meeste taken precies in deze middenfase geplaatst.

Tegen het einde van de wandeling kun je echter weer je doel zien en de motivatie keert terug. Met elke stap komt het doel een beetje dichterbij. Het is belangrijk dat je ontwikkelaars zich in deze fase bevinden, waar ze hun voortgang kunnen meten en visualiseren. Alleen zo kun je urgentie en werkmotivatie op peil houden.

Code Ownership

Wees voorzichtig met Code Ownership – als mensen hun eigen codebase hebben, kan dat veel verkeerde prikkels creëren die je moet vermijden. Bij Yammer is de organisatie opgedeeld in vakgebieden. Ontwikkelaars zijn immers echt slim en gemotiveerd en als ze zich kunnen oriënteren op het bedrijfsdoel, kunnen ze verbazingwekkende dingen presteren (en dat zelfs volledig zelfstandig).

Vaststellen hoe een werkend team eruitziet

Voordat er een productteam voor een feature wordt samengesteld, wordt de specificatie goed bekeken. Preciezer gezegd probeert men de inspanning voor het feature in te schatten.

Neem Product X. Het is een denkbeeldig feature dat de viraliteit verhoogt door het mogelijk te maken om vrienden uit te nodigen tijdens het aanmeldproces. Bij dit voorbeeld ligt de nadruk op het front-end, wat betekent dat je mogelijk twee mensen nodig hebt voor de gebruikersinterface. En omdat je waarschijnlijk ook iets in het aanmeldproces moet aanpassen, heb je zeker ook iemand uit het Rails-team nodig om de code daarvoor te schrijven.

Zodra het productteam het eens is geworden over een prioriteit voor het project, hoef je alleen nog maar te wachten tot de ontwikkelaars beschikbaar zijn (in dit geval twee voor het front-end en één voor Rails). Bij Yammer is er een groot whiteboard met een raster, dat „Big Board" wordt genoemd. Aan de ene kant worden de projecten opgesomd, aan de andere kant alle ontwikkelaars die aan features werken. Uiteraard kan een ontwikkelaar tegelijkertijd maar aan één project werken. Het Big Board zorgt bovendien voor goede transparantie van de prioriteiten. Alles wat tijdens de ontwikkeling wordt gedaan, wordt daar vermeld en zo kan de directeur op elk moment een blik werpen en vaststellen: "Hier werken de ontwikkelaars dus aan."

Als het je lukt om de focus voor een enkel project te waarborgen, zal je bedrijf al aanzienlijk sneller worden. Het is verbazingwekkend dat niemand dit in zijn organisatie als voorwaarde stelt – terwijl in feite iedereen weet hoe duur een contextswitch is. Met absolute focus bouw je één ding, lever je het op en kun je je daarna op iets anders richten.

Maar wie lost dan de bugs op?

Als iedereen aan features werkt, wie lost dan de bugs op? Bij Yammer zijn er gewoon meerdere cross-functionele teams. Je neemt een paar mensen uit het Rails-team, het front-end-team en het mobile-team enz. en zegt tegen hen: "Jullie taak is om de bugs op te lossen en onze lijst af te werken." Dat is slechts een tijdelijke aangelegenheid (zoals alle projectgerichte groepen) en de mensen wisselen elkaar daarbij af. Deze organisatiestructuur maakt het mogelijk om voor de support te zorgen zonder de ontwikkeling van features te beïnvloeden.

Bovendien ontstaat er zo geen tweederangsklasse van ontwikkelaars. Hier worden niet gewoon een paar junior-ontwikkelaars neergezet om bugs te fixen; senior-ontwikkelaars worden eveneens betrokken. En dat is bewust zo, want als bugs opgelost moeten worden, wil je ze niet afdekken, maar de oorzaak aanpakken. Meer ervaren mensen moet het toegestaan zijn om indien nodig de code te refactoren. Dit systeem leidt bovendien tot een feedbackloop tussen degenen die de features bouwen en degenen die de bugs oplossen. Als je de frequentie en het type bugs kent, is dat waardevolle informatie voor beslissingen die de productontwikkeling vooruit kunnen helpen.

Deze tekst is afkomstig uit de blog van First Round en is door ons naar het Nederlands vertaald.