Goeiedag, ik ben Tom.

Weet jij hoe je kan detecteren dat je softwareteam niet goed functioneert? 

Sommige mensen hebben het gevoel dat ze geen vat hebben op hun softwareteam, maar niet goed weten of hun gevoel nu terecht is of niet. Doorheen de jaren heb ik een aantal rode vlaggen gezien die aangeven dat er moet ingegrepen worden op de werking van een softwareteam. Dit lijstje kan je helpen om je eigen softwareteam te evalueren.

Developers zien hun eigen fouten niet. 

Het softwareteam komt je heel trots vertellen "De nieuwe release is klaar! Feature X zit er nu in, en bug Y is opgelost!" Enthousiast start je de software op... en na 3 klikken denk je "waarom hebben ze dat nu gedaan? Zien ze nu niet dat dat niet juist is? En bug Y hebben ze opgelost op scherm A, maar niet op scherm B. Zien ze dan niet dat dat hetzelfde is?" 

Dikwijls schort er in dit geval iets in de manier van werken. Ik zie dit heel veel gebeuren wanneer de dag van een developer bestaat uit het "oppikken van ticketjes". Een problem owner (de persoon die het resultaat wil zien) ziet een ticketje als een onderdeel van een groter probleem, dat ie behapbaar wil maken voor een programmeur. Vooraleer dat ticketje bij de programmeur geraakt, is dat ticketje echter helemaal losgekoppeld van haar context, en de programmeur ziet alleen maar een lange, lange lijst met tickets waarvan ie er zoveel mogelijk moet gesloten zien te krijgen. De programmeur heeft helemaal geen incentive meer om verder te zoeken naar de context, of om het volledige plaatje in haar achterhoofd te houden. Maar jij, als problem owner, moet wél het hele plaatje terug bijeen brengen.

Zorg dat je programmeurs het hele beeld voor ogen houden.

Lange communicatiepaden

Jij, de problem owner, vertelt heel enthousiast aan de project manager waarom je een nieuwe feature nodig hebt. Je hebt er zelfs al over nagedacht hoe je die feature vorm wilt geven, waar die past in de software, en zelfs welke kleur van knop je daarvoor denkt te gebruiken. De project manager vertelt aan de designer hoe de feature vorm gegeven moet worden, waar die past in de software, en welke kleur knop die moet hebben. De designer vertelt aan de technical team lead waar de feature past in de software, en welke kleur knop ie daar best voor gebruikt. De technical team lead vertelt aan de developer dat ie een blauwe knop moet maken.

Is dit herkenbaar? Het doet wat denken aan het telefoonspelletje dat we vroeger in de jeugdbeweging speelden. De boodschap die op het einde aankwam, was helemaal anders dan de boodschap die in het begin verteld werd. Hoe langer het pad dat een communicatie moet volgen, hoe meer informatie er verloren gaat en hoe meer fouten er in het systeem sluipen.

Probeer de communicatiepaden zo kort mogelijk te houden.

Lange release cycles

Lange release cycles (de tijd die het duurt tussen wanneer jij een feature beschrijft, en de eerste keer wanneer je kan zien dat die feature geprogrammeerd is) zijn een probleem op zich, maar ze zijn vaak ook een indicatie dat er iets anders mis is.

Ze zijn een probleem op zich, omdat het voor jou als problem owner heel moeilijk is om te volgen waar je softwareteam mee bezig is als je de concrete resultaten niet kan zien. Als het weken duurt vóór je kan zien wat de programmeurs aan het doen zijn, zijn ze misschien al weken in de verkeerde richting aan het werken.

Lange release cycles zijn vaak ook een indicatie van een onderliggend probleem. Zo kan het zijn dat een release zelf heel veel tijd in beslag neemt, wat onnodig veel tijd vraagt van je softwareteam — tijd die ze beter aan andere dingen zouden kunnen besteden. Het kan ook zijn dat je softwareteam er niet in slaagt om intern te communiceren, waardoor ze alles regelen via tijdverslindende formele processen. Of je softwareteam denkt dat ze best alles in één keer bouwen zonder fouten. Met die benadering is een klein probleempje: in de bijna 35 jaar dat ik nu software schrijf en zie schrijven, heb ik nog nooit iemand van de eerste keer een foutloos programma zien schrijven. Het is dus belangrijk om heel vaak en heel snel software te releasen, zodat jij als product owner zo snel mogelijk de voortgang kan evalueren en eventueel bijsturen.

Dring aan op korte release cycles.

Deadlines worden niet gehaald

Wanneer je software team deadlines niet haalt, is dat niet noodzakelijk een probleem, zeker in het begin van een project. Maar als je softwareteam na verloop van tijd nog steeds geen deadlines haalt, is dat vaak een symptoom van een ander probleem. Het team overschat zichzelf steeds? Het team begrijpt niet waar het mee bezig is? Het duurt te lang om problemen die de kop opsteken, op te lossen? Het team wordt teveel door andere projecten onderbroken? Wat de oorzaak ook is, de reactie mag nooit zijn "ach ja, het is nu zo, laat ons maar verder werken zoals we bezig waren."

Deadlines zijn vaak arbitraire momenten in de tijd, en vaak maakt het niet écht uit of ze gehaald worden of niet. Maar als een softwareteam belooft om een deadline te halen, en ze slagen daar keer op keer niet in, zoek dan uit waarom dat zo is. 

Deadlines zijn een vorm van commitment; zorg dat ze ook zo gezien worden.

Truck factor van 1

De "truck factor" van een team is een redelijk plastisch uitgedrukte manier om te bepalen hoe kwetsbaar je team is. De redenering is als volgt: stel dat je team morgen de straat oversteekt, en wordt aangereden door een vrachtwagen. Vanaf hoeveel sterfgevallen moet je je softwareproject stopzetten? Dat aantal sterfgevallen noemen we de "truck factor".

Natuurlijk wens ik niemand toe dat ie door een vrachtwagen wordt overreden. Maar het is nu eenmaal zo dat mensen om één of andere reden vroeg of laat een team verlaten: hun partner vind een job in het buitenland, ze gaan met pensioen, ze krijgen promotie, ze krijgen kinderen, ... 

Je wil niet dat je team een truck factor heeft van 1. Dat wil zeggen dat je je software project zal falen als één team lid wegvalt. Zelfs in het geval er niemand ooit het team verlaat, wil dat ook zeggen dat het team niet functioneert als iemand vakantie neemt. Ik denk dat het onnodig is te zeggen dat dit niet efficiënt is.

Zorg dat je weet hoe je teamleden kan vervangen wanneer nodig.

Toxische teamleden

In sommige teams kom je ze nog tegen: de mensen waar eigenlijk niemand mee wil samenwerken. Als je ermee samenwerkt, wordt je afgesnauwd of vernederd. Als ze iets uitleggen, doen ze dat op zo'n manier dat je er toch niets van snapt, en je jezelf oerdom voelt. Het vreemde is dat die mensen in veel gevallen worden gezien als onmisbaar: ze weten zoveel van de software, en ze kunnen dingen die niemand anders kan. Ik zal je een geheim verklappen: die mensen worden alleen zo gezien omdat ze niet praten met hun collega's. Vaak hebben ze één stukje kennis dat ze angstvallig verborgen houden, om toch maar niet ontmaskerd te worden als domme nietsnutten. (Ter hunner verdediging: niet al deze mensen hebben slechte bedoelingen of een slecht karakter: vaak hebben ze last van het Impostor Syndrome, en doen ze toch maar alles wat in hun mogelijkheden ligt om niet ontmaskerd te worden.)

Wat ook de oorzaak is van dat gedrag: ik zie dat teams met een toxisch teamlid heel slecht functioneren. Goedbedoelde initiatieven worden door die ene persoon in de kiem gesmoord, om toch maar de status quo te blijven houden, hoe slecht die ook is voor alle betrokken partijen. Veel mensen durven die toxische persoon niet verwijderen uit het team, omdat ze denken dat die persoon truck factor 1 heeft.

Wanneer de beslissing dan toch genomen wordt om zonder die persoon verder te werken, merk ik dat het meestal wel meevalt. Die persoon is toch niet zo onmisbaar als ie zelf dacht, en al helemaal niet zo onmisbaar als de andere teamleden dachten. Het gat dat ie achterlaat wordt zeer snel opgevuld door de andere teamleden, die blij zijn dat ze eindelijk zelf kunnen laten zien tot wat ze in staat zijn.

Tolereer geen toxische teamleden.

Wat is jouw ervaring?

Ken jij nog symptomen die wijzen op een slecht functionerend team? Laat het me zeker weten, dan kan ik mijn lijstje verder aanvullen. Denk je zelf een slecht functionerend softwareteam te hebben, en kan je best wat hulp gebruiken om je situatie te verbeteren? Laat ons er eens over praten.