Negatieve snelheid: hoe verhoog je de complexiteitslimiet

De complexiteitslimiet bereiken lijkt misschien onvermijdelijk, maar er zijn een aantal indicaties dat teams hun limiet bijna hebben bereikt. Ik moet ook zeggen dat er geen absolute statistiek is die je vertelt hoe dicht je bij de complexiteitslimiet zit, maar deze indicaties kunnen je helpen om vast te stellen hoe dichtbij je bij de limiet zit.

De duidelijkste indicatie dat een team de complexiteitslimiet heeft bereikt, is wanneer ze meer tijd besteden aan het omgaan met organisatorische complexiteit dan aan het oplossen van lastige problemen waarop ze zich zouden moeten concentreren. De statistieken over de doorlooptijd van DORA voor wijzigingen (snelheid) en het uitvalpercentage van wijzigingen (kwaliteit) laten zien of teams na verloop van tijd langzamer of sneller werken. Hoewel er nog andere factoren van invloed zijn op deze statistieken, zijn ze een goede indicatie voor de effectiviteit van het team.

De tevredenheid van ontwikkelaars is een andere indicatie van met hoeveel organisatorische complexiteit softwareteams te maken krijgen. Ontwikkelaars besteden hun tijd graag aan het oplossen van lastige problemen, maar ze hebben ook een hekel aan overbodige taken waar ze last van hebben. Een lage tevredenheid van ontwikkelaars is een goede aanwijzing dat de organisatorische complexiteit een issue is voor je softwareteam.

Wanneer bedrijven zich realiseren dat hun teams omkomen in de complexiteit, starten ze vaak een 'vereenvoudigingsproject', met als doel hun organisatie te vereenvoudigen. Vereenvoudiging is om twee redenen een slechte strategie; de complexiteit neemt sneller toe dan organisatie hun omgeving kunnen vereenvoudigen, en deze 'vereenvoudigingsprojecten' worden uitgevoerd in precies dezelfde complexe omgeving die ze willen vereenvoudigen.

Vereenvoudiging begint vaak met het verminderen van het aantal toepassingen door waar mogelijk buiten gebruik te stellen of te consolideren. Om een toepassing buiten gebruik te stellen, moet het team inzicht hebben in alle upstream en downstream afhankelijkheden, wie de toepassing gebruikt, hoe de functionaliteit moet worden vervangen, waar en hoe de gegevens worden gearchiveerd of gemigreerd, en nog veel meer problemen oplossen die met dit werk gepaard gaan. Helaas wordt de aanzienlijke inzet die vereist is om dit te doen niet beloond met een even aanzienlijke vermindering van de complexiteit. Het aantal toepassingen dat een bedrijf buiten gebruik kan stellen zonder dat dit gevolgen heeft voor de kernactiviteiten of de gebruikerservaring is beperkt, maar het aantal nieuwe softwarecomponenten dat ingenieurs aan kunnen maken is niet beperkt.. In de 12 maanden die nodig zijn om één toepassing buiten gebruik te stellen, zijn er waarschijnlijk honderden nieuwe microservices aangemaakt. Aangezien een gezonde technologische omgeving na verloop van tijd groeit, is het niet praktisch om de omgeving te beperken tot een vast aantal toepassingen of softwarecomponenten om de complexiteit te verminderen.

Vereenvoudigingsprojecten bestaan vaak uit het aanpassen van de organisatiestructuur om de communicatiestroom minder ingewikkeld te maken. De minst ingewikkelde organisatiestructuren hebben grote hiërarchische teams en alle medewerkers bevinden zich op dezelfde locatie. De meest ingewikkelde organisatiestructuren hebben kleine, verspreide en autonome teams. Uit de wet van Conway blijkt dat grote hiërarchische teams waarschijnlijk monolithische toepassingen produceren, terwijl kleine verspreide teams waarschijnlijk toepassingen produceren met behulp van modulaire architecturen zoals microservices. Snelle productie van hoogwaardige software wordt mogelijk gemaakt door modulaire architectuurpatronen, zoals een microservice-architectuur, wat betekent dat de complexere organisatiestructuur eerder tot succes leidt. Hoewel het 'vereenvoudigen' van de organisatiestructuur het begrijpelijker maakt, werkt dat contraproductief voor het uiteindelijke doel van het vereenvoudigingsproject.

Vereenvoudiging is belangrijk en de moeite waard, maar kan het beste worden ingebouwd als continue verbetering voor softwareteams (en teams bestaande uit teams) in plaats van als een eenmalige activiteit. Vereenvoudiging kan het bereiken van de complexiteitslimiet uitstellen, maar brengt een organisatie niet terug naar de vrijheden die een startende omgeving geniet.

Om softwareteams effectiever te maken, moeten organisaties de complexiteitslimiet verhogen. De complexiteitslimiet verhogen betekent in wezen dat elk team zich kan aanpassen aan organisatorische complexiteit, voordat dit invloed heeft op de werktevredenheid en kwaliteit en snelheid waarmee het team software produceert.

Platformontwikkeling is een belangrijk concept in de zoektocht om de complexiteitslimiet voor een organisatie te verhogen. Teams voor sterke platformontwikkeling richten zich op het verminderen van de cognitieve belasting van softwareteams door organisatorische complexiteit uit hun dagelijkse werk te filteren. Mits correct geïmplementeerd, stelt platformontwikkeling teams in staat om de meeste inspanningen om lastige problemen op te lossen weer in evenwicht te brengen, waarbij minder tijd wordt besteed aan organisatorische complexiteit.