Innoveer meer en ga sneller. Het lijkt een simpele richtlijn. Bijna elke organisatie wil nieuwe ideeën sneller op de markt brengen en geavanceerde technologische oplossingen in minder tijd implementeren. En, deze oplossingen moeten allemaal veilig, betrouwbaar, compliant en veerkrachtig zijn. De vraag is hoe, want voor traditionele organisaties is dit niet gemakkelijk.
Naast het gebruik van de cloud hebben organisaties ook goed presterende agile teams nodig die zich verantwoordelijk en bevoegd voelen. Om een goed presterende agile organisatie te worden, moet je anders naar je organisatiestructuur kijken en bereid zijn om je mindset en gedrag te veranderen. Bij ons begint dit met het concept van ‘Two-Pizza-teams’: teams die genoeg hebben aan twee pizza’s en meestal bestaan uit vijf tot tien personen. De sleutel om te versnellen, innovatiever te zijn en nieuwe geavanceerde technologieën te gebruiken, is om kleinere teams op te zetten die duidelijke verantwoordelijkheden hebben zodat ze waarde aan het bedrijf kunnen toevoegen.
Hoe traditionele organisatiemodellen wendbaarheid afremt
Organisaties zijn vaak jaren bezig geweest met het perfectioneren van een organisatiemodel voor IT-teams waarbij alle database-engineers samen in één team zitten, alle software-engineers in een ander en ga zo maar door. Zo’n organisatiemodel gebaseerd op vaardigheden richt zich op het beheer van technologie in plaats van het gebruiken van technologie voor innovatie en het behalen van een strategisch voordeel. Wat nodig is voor de agile organisaties van vandaag de dag.
Een model gebaseerd op legacy dwingt organisaties om projectteams op te zetten, waarbij het werk wordt verdeeld tussen verschillende teams. Dit model vereist meer coördinatie tussen teams om verwachtingen vast te stellen, werk te prioriteren en deadlines te synchroniseren. Dit is allemaal erg inefficiënt en zorgt vaak voor miscommunicatie, traagheid en teams kunnen gemakkelijk overbelast raken.
Wie is verantwoordelijk voor resultaten?
Teams gebaseerd op vaardigheden zijn niet alleen inefficiënt en onpraktisch. Ze creëren ook een barrière voor agility. Met zoveel expertise gecentraliseerd in deze teams, zou je verwachten dat succes onvermijdelijk is. Maar in werkelijkheid wordt het vrijwel onmogelijk om iemand verantwoordelijk te houden voor resultaten. In deze teams is iedereen op de een of andere manier verantwoordelijk voor resultaten en toch lijkt tegelijkertijd niemand verantwoordelijk te zijn.
Daarnaast speelt de grote omvang van deze teams in op een psychologisch fenomeen dat diffusie van verantwoordelijkheid wordt genoemd. Hoe meer mensen getuige zijn van een gebeurtenis, hoe kleiner de kans dat iemand actie onderneemt. Mensen gaan ervan uit dat iemand anders de verantwoordelijkheid op zich neemt. Dit gebeurt ook in deze teams; iedereen gaat ervan uit dat iemand anders het oplost, controleert of het veilig is, of ervoor zorgt dat het in productie kan gaan.
Wie kunnen we vertrouwen?
Ontwikkelaars hebben meestal gewoon tot doel om goede code te schrijven. Ze wantrouwend behandelen door het beheersen van risico’s via een hele reeks goedkeuringen en autorisaties verslechtert de productiviteit. Dit gebrek aan vertrouwen wordt verergerd door het gebrek aan cohesie en gedeelde doelen.
Het bedrijf en IT
De op vaardigheden gebaseerde organisatiestructuur, met zijn gefragmenteerde communicatielijnen en meerdere overdrachten, zorgt voor afstand tussen IT en de rest van de onderneming. Teams worden in een positie gebracht waarin ze vaak worden gevraagd om iets voor een klant te leveren dat ze niet begrijpen, noch begrijpen ze het probleem dat moet worden opgelost. Dit komt doordat we comfortabeler zijn geworden door technologie binnen handbereik te houden van de rest van de onderneming.
In een poging dit te ondervangen, worden grote programmabureaus gecreëerd en worden business technology liaisons (of business partners) ingehuurd om als kanaal tussen IT en de business te fungeren. Helaas zijn deze rollen vaak niet in staat meer te doen dan bestellingen op te nemen en de status te communiceren, wat leidt tot meer frustratie bij IT over wat ze moeten doen en mysterie in de rest van de onderneming over waar IT mee bezig is.
Dit alles maakt het werken met IT steeds moeilijker en leidt vaak tot schaduw-IT. Schaduw-IT ontstaat vaak niet omdat andere afdelingen hun eigen IT willen runnen, maar eerder omdat afdelingen gefrustreerd zijn door vertragingen, beperkte responsiviteit en gebrek aan transparantie van IT. Ze zoeken namelijk de weg van de minste weerstand om iets voor elkaar te krijgen.
Volgende stappen
Dit alles heeft de verantwoordelijkheid en aansprakelijkheid over teams verspreid en demotiveert teamleden, omdat er vaak geen direct verband is tussen resultaten en erkenning.
We hebben een betere aanpak nodig. Stel jezelf de volgende vragen:
- Wat voor beslissingen neem je als leider? Loop je vast in de details van een project?
- Zijn er teams die in het geheim projecten doen voor jou, de rest van de organisatie of elkaar?
- Als je project te laat is of een systeem niet werkt, zijn er dan meerdere leiders en teams nodig om het op te lossen? Zijn er evenveel teams nodig om samen te werken om nieuwe functionaliteit uit te brengen?
- Komt schaduw-IT veel voor binnen jouw organisatie?
Als je een van deze vragen met “ja” hebt beantwoord, moet je waarschijnlijk opnieuw nadenken over hoe je teams structureert. Het is waarschijnlijk dat ontwikkelaars niet bevoegd zijn om hun eigen beslissingen te nemen en niet worden aangemoedigd om verantwoordelijkheid te nemen voor hun werk.
Het goede nieuws is dat het niet zo hoeft te zijn. Het probleem identificeren is het halve werk: het is tijd om na te denken over hoe je het kunt oplossen.
