Hoe ik de werking van Twixl mee naar een hoger niveau mocht helpen tillen

Toen we nog naar familiefeesten of op café konden gaan, kreeg ik vaak dezelfde vraag. ‘Zeg Tom, wat doe je eigenlijk?’, klonk het.

Een simpele vraag met een niet zo eenvoudig antwoord. Op mijn homepage staat dat ik “groeiende techbedrijven help om hun softwareontwikkelingsproces op punt te zetten”, maar wat wil dat nu concreet zeggen? Ik kan het het best uitleggen door te vertellen over een bedrijf dat ik de afgelopen maanden geholpen heb: Twixl.

Twixl heeft al een mooi parcours afgelegd. Het softwarebedrijf, dat met Twixl Publisher een tool ontwikkelde waarmee uitgevers makkelijk native apps kunnen maken, timmert al een jaar of tien aan de weg. Hun klanten komen van over de hele wereld om hun technologie te gebruiken. Twixl maakte zich klaar voor een volgende groeispurt en voelde, zo gaat dat nu eenmaal, groeipijnen opduiken. Zo was niet iedereen in het team altijd even aligned. Het sales team was bijvoorbeeld gefrustreerd omdat ze vonden dat softwareontwikkeling steeds lang duurde. Het team dat de software ontwikkelde was dan weer ontevreden omdat het niet duidelijk was wat sales nu eigenlijk wou. En customer support wist niet altijd goed wat ‘Sales’ beloofd had en wat ‘Ontwikkeling’ gebouwd had. Het zijn problemen die wel vaker opduiken in bedrijven die op deze fase zijn aanbeland.

Daarom werd ik ingeschakeld om na te gaan hoe dit opgelost kon worden.

Veel werk verricht, maar weinig overzicht

Toen ik aan mijn opdracht begon vielen er meteen een paar dingen op. Er werden in Twixl veel zaken gedaan en ontwikkeld, maar er was te weinig focus op de volgorde waarin dat gebeurde. Er zaten veel nieuwe features ‘in de pijplijn’, maar vaker niet dan wel werden die afgewerkt.

Dat effect werd nog versterkt doordat er weinig algemene planning was van wie waaraan werkte. Elke developer wist uiteraard wel wat-ie aan het doen was, maar er was geen overzicht over welke taken er aangepakt moesten worden, welke er afgewerkt waren, en welke er verder opgevolgd moeten worden. In een klein bedrijf valt zoiets minder op, maar in een scaleup zorgt het voor veel tijdverlies - en dus weggesmeten geld.

Twixl bracht elke zes maanden een nieuwe versie van hun software uit. Dat betekende ook dat alle features bij elkaar kwamen in die nieuwe versie. Alle testen en de documentatie vonden plaats vlak voor die zesmaandelijkse deadline. Wanneer er in zo’n geval een paar tests de mist in gaan, komt er veel druk op de developers te liggen. Zij zijn op hun beurt gefrustreerd en vragen zich af waarom er niet eerder getest werd.

Zo hebben we de groeipijnen weggewerkt

Op basis van deze vaststellingen bespraken we samen een plan om dit te verbeteren.

We spraken af wie welke rol op zich zou nemen, en wat de verantwoordelijkheden van die rol waren. Zo maakten we de rol van de product manager die aangesteld zou worden ook expliciet: hij of zij beslist over de prioriteiten. Wat wordt er eerst gedaan en wat komt daarna?

Om zijn of haar rol behapbaar te maken en een overzicht te creëren, bouwden we een digitaal kanban bord, waarin (1) de developers een geprioriteerd overzicht krijgen van wat hen te doen staat, (2) de CTO een overzicht krijgt van waar de developers mee bezig zijn, (3) het testteam kan zien wat er klaar is om getest te worden, en (4) sales kan zien wat er afgewerkt is, zodat ze kunnen beginnen verkopen.

We sleutelden ook aan de overlegmomenten. Op de dagelijkse meeting is voortaan iedereen aanwezig, maar we zorgden er wel voor dat die niet langer duurde dan noodzakelijk. Wanneer er een puntje ter sprake komt dat maar enkele deelnemers aanbelangt, beslist men snel om dat achteraf, in een kleinere groep, verder te bespreken. Elke week is er een meer uitgebreide meeting, die meer focust op de lange termijn. Aan het begin van elke delivery cyclus bespreken we uitgebreid waar we ons in die cyclus op gaan concentreren. Over de delivery cycle gesproken: in plaats van om de zes maanden, levert Twixl nu elke 5 weken een nieuwe versie van hun product op.

Een nieuwe manier van werken die toekomstbestendig is

Wat zijn de gevolgen van dit plan? Eerst en vooral: de leden van het team begrijpen elkaar beter. Door de gestructureerde meetings weet iedereen beter wat ieders besognes zijn. Er zijn minder frustraties door misverstanden.

Door het kanban bord kan iedereen beter volgen waar de ander mee bezig is. De meetings die focussen op de iets langere termijn zorgen ervoor dat iedereen een helder beeld heeft van waar zowel het bedrijf als het product naartoe gaan. Hierdoor kan iedereen zijn/haar steentje bijdragen om die richting uit te gaan.

De kortere delivery cycle zorgt er dan weer voor dat het haalbaarder wordt om alles grondig te testen, waardoor er steeds minder lijken uit de kast vallen. Zij zorgt er ook voor dat Twixl sneller feedback krijgt van haar klanten. Zo kan het een beter product bouwen.

Een echte team effort

Natuurlijk is dit resultaat niet enkel mijn verdienste. Het hele team heeft zich achter het plan geschaard, en ieder draagt bij aan het succes van de veranderingen. Misschien zou het team uiteindelijk ook zonder mij tot deze oplossing geëvolueerd zou zijn.

Mijn bijdrage is vooral dat ik de situatie kon objectiveren, en het veranderingsproces kon versnellen. Als buitenstaander is het gemakkelijker de zaken objectief te bekijken, zonder de (emotionele) historie te moeten meenemen. Dit maakt een aantal discussies een pak gemakkelijker. Door mijn ervaring met andere bedrijven kon ik ervoor zorgen dat we bepaalde beslissingen gemakkelijker konden nemen. Het hele proces is sneller kunnen gaan omdat het bedrijf een aantal fouten niet meer moest maken. Zoals ik aan het begin al zei: ieder bedrijf kampt vroeg of laat met die groeipijnen, dus pak je ze best meteen aan samen met iemand die ze al meerdere keren heeft doorstaan. Zo maak je zonder veel kleerscheuren de volgende sprong met je bedrijf!

Wil jij ook de manier waarop je softwarebedrijf werkt eens onder de loep nemen? Contacteer me gauw, en we beginnen eraan!