U heeft het vanuit de directiekamer ongetwijfeld gemerkt: er wordt lekker agile gewerkt binnen uw organisatie. Breed samengestelde teams die snel zichtbare resultaten opleveren. En dat gebeurt niet langer alleen op de IT afdeling, maar ook bij uw juristen, inkopers en winkelpersoneel. Laat maar lekker van onderop groeien, denkt u misschien. Sluit mooi aan bij de tijdsgeest en de onvoorspelbare omgeving waarin we opereren. Maar dat is verkeerd gedacht: zonder een goed raamwerk zou dit plantje uw organisatie wel eens volledig kunnen overwoekeren.
Laat ik vooropstellen, er zijn veel voordelen verbonden aan agile werken: autonome teams die in nauwe samenwerking met de klant producten ontwikkelen. Het kan bijdragen aan de wendbaarheid van uw organisatie en aan het werkplezier van uw medewerkers. Het probleem is alleen dat bij dit soort initiatieven de aandacht veel te lang exclusief op de teams gericht is: trainingen, coaching, staand vergaderen, kekke huisvesting, noem maar op. Maar een organisatie is natuurlijk meer dan een verzameling teams met een gebouw eromheen.
Visie, raamwerk, organisatieontwerp
Er komt een moment dat de doelen en inspanningen van de agile teams optellen tot iets wat de directie aangaat. Als de teams steeds meer de plek zijn waar het werk écht gebeurt in uw organisatie, is het uw verantwoordelijkheid om een raamwerk te ontwerpen. Een raamwerk dat ervoor zorgt dat de teams niet alle kanten op woekeren, maar gezamenlijk producten en diensten blijven voortbrengen waarop uw klanten zitten te wachten.
De ervaring leert dat een dergelijk raamwerk er niet vanzelf komt. Sterker nog, ik zie het steeds vaker gebeuren dat het topmanagement volledig overvallen wordt door de impact die agile werken heeft op de besluitvorming in de directiekamer. En dan is het soms al te laat en moeten initiatieven worden afgeremd of zelfs stilgelegd, hetgeen natuurlijk funest is voor de energie bij medewerkers. Terwijl eigenlijk met het vooraf nadenken over een aantal eenvoudige vragen veel ellende kan worden voorkomen.
Want als we het erover eens zijn dat een organisatie meer is dan een verzameling teams met een gebouw eromheen, dan is de logische vervolgvraag: wat is dan dat ‘meer’? De organisatiekundige literatuur leert ons dat dit minimaal gaat over het gezamenlijk najagen van doelen. Aangezien agile teams zich per definitie richten op een klein onderdeel van de organisatiedoelen – die focus is juist wat de teams zo effectief maakt – ligt het borgen van die overkoepelende doelen ergens buiten of boven deze teams. En dan is het naïef om te denken dat de teams er onderling wel uitkomen. Zeker in de strijd om schaarse middelen zal het ieder voor zich zijn.
Alle autonomie en zelforganisatie in de teams ten spijt, is daar toch echt de directie aan zet met het top-down ontwerpen van het juiste raamwerk.
Exploratie versus exploitatie
Dan nog een laatste waarschuwing vanuit de wetenschap. De Amerikaanse socioloog James G. March – ons eind vorig jaar helaas ontvallen - sprak begin jaren negentig over de noodzakelijke balans die elke organisatie zal moeten bewerkstelligen tussen twee uitersten: exploratie en exploitatie. Exploratie gaat over zoeken en experimenteren, terwijl exploitatie gaat over efficiency en voorspelbaarheid. Als we dit gedachtegoed vertalen naar de huidige tijd is het duidelijk dat agile teams zich uitstekend lenen voor het eerste, maar veel minder goed voor het laatste. Maar ook exploiteren zal in elke organisatie nodig zijn, al is het maar omdat met exploreren alleen geen geld kan worden verdiend. Ook die nuchtere blik op de reikwijdte van agile werken wordt verwacht vanuit de directiekamer.
Agile werken: geen hype
Ik denk niet dat het werken met agile teams een hype is. Het sluit wel degelijk aan bij de tijdsgeest en bij de onvoorspelbaarheid van de omgeving waarin veel organisaties acteren. Maar het is belangrijk niet uit het oog te verliezen dat een aantal belangrijke inzichten uit de organisatiekunde nog steeds van toepassing zijn. Ook in deze tijden van digitale disruptie. Nu het zaadje van deze nieuwe manier van werken de afgelopen jaren in de teams binnen uw organisatie geplant is, bent u nu als directie aan zet om de groei in goede banen te leiden.
Kom met uw praktijkervaringen op het terrein van managen en organiseren
Deel uw kennis, schrijf 3 columns of artikelen en ontvang een gratis pro-abonnement (twv €200)
Word een pro!
SCHRIJF MEE >>
Key concept van zowat alle Agile methodieken die mij bekend zijn gaat er nu juist om om diegene die richtingbepalend zijn (uiteindelijk directie/management) via een specialist/verantwoordelijke op het gebied van prioriteitstelling in relatie tot de organisatiestrategieen, behoeften, etc.. teams te laten sturen op de beoogde waardecreatie (noem het product owner, visionair, etc..). Hoe de teams dat verder doen is aan de teams zelf (zij zijn immers de absolute kenners en kunners op het inhoudelijke vlak). Maar wat absoluut vaststaat is welke waarde (top down geprioriteerd) een organisatie uit de agile ontwikkelprocessen wil halen. Het laatste dat dient te gebeuren is een top-down opgelegd raamwerk dat daar nog eens paal en perk aan gaat stellen. Laat die teams het lekker zelf uitzoeken, als je dat vertrouwen niet kunt schenken aan je teams/medewerkers kun je maar beter stoppen met Agile. En natuurlijk zijn er diverse cross-cutting concerns in een organisatie, zoals resourcing en het hele copafijth palet, maar ik ben geen situatie tegengekomen waar de bestaande bedrijfsvoering niet zonder een paar werkafspraken op de Agile werkwijzen aan te sluiten viel.
Als laatste nog even over exploratie versus exploitatie; wat je ziet gebeuren is dat er tegenwoordig steeds meer ook elementen van Lean onder Agile geschaard worden. Zo worden traditionele exploitatie klussen (beheer, call centers, ticketing, etc.) steeds vaker middels kanban en soortgelijke methodieken uitgevoerd. De achterliggende ideeen komen grotendeels overeen: continue meten en bijstellen voor optimale waardecreatie.
En is de scheiding tussen aansturing en exploitatie wel zo dwingend topdown? We weten van Tannenbaum toch al lang dat slimme managers ook goed kunnen sturen door de juiste en beargumenteerde vragen te stellen aan die verbeterteams? Maak je het wat minder streng dan kan je zeggen dat er twee elementen bij horen: a) een dialoogconstructie en b) er moet altijd wel spanning op staan vanuit de directie. En wellicht is er ook nog iets anders aan de hand. Een paar maanden geleden hoorde ik Thijs Homan zeggen: "zelfstandige teams? Dat is het nieuwe topdown." Je hebt zodoende zowel het fenomeen te veel sturing als juist te weinig. Een modern gestructureerde dialoog waar ook spanning op staat. Is dat niet het geval dan kan je gelijk krijgen zoals bij Hollands Kroon is gebleken.
Overigens geldt dit ook voor 'pure' ICT=projecten, voorbeeld: als de onderliggende gegevensbestanden vervuilt zijn of de infrastructuur rammelt, blijf je daar met je scrum resultaat last van houden. De verleiding tot het op korte termijn scoren ontslaat je niet van de plicht ook de wat minder populaire zaken te onderhouden. Vergelijk: je wordt niet populair van het vervangen van de riolering, maar het is wel nodig.