Patronen in verandering

Het moet sneller

We komen veel organisaties tegen die bezig zijn met de vraag hoe ze sneller meer waardevolle producten en diensten kunnen leveren. Het startpunt is een organisatie die niet op snelheid ingericht is maar op waarden als efficiency of beheersbaarheid. Je ziet dan afdelingen die zich bezighouden met een specifieke bedrijfsfunctie. Veranderingen en niet-reguliere vraagstukken worden projectmatig aangepakt met tijdelijke teams die de uitdaging hebben om de veranderingen te laten landen in een lijnorganisatie. Een lijnorganisatie die met de uitvoering van het jaarplan bezig is, en niet staat te juichen als daar de volgende verstoring doorheen komt.

Een organisatie die zo ingericht is, heeft het moeilijk als de omgeving dynamischer wordt. Een verandering in producten of diensten vergt een nieuw project dat pas na een gedegen vooronderzoek opgestart kan worden en dat een doorlooptijd kent van vele maanden. Vanuit de lijnorganisatie zelf is het vrijwel onmogelijk om substantiële veranderingen door te voeren, want je bent maar verantwoordelijk voor een deel van het product of de dienst.

Agile!

Agility of wendbaarheid op zijn Nederlands, vraagt dat je snel in kunt spelen op voor jou relevante dynamiek. Dat je je product en / of dienstverlening aan kunt passen als dat nodig is of waar dat kansen biedt. Dit betekent dat je de dynamiek moet herkennen, moet weten wat een passend antwoord is, en dan in staat moet zijn om dat antwoord snel te geven - als organisatie.

In het klein is er veel ervaring opgedaan met inspelen op dynamische vraagstukken, door het werken met agile ontwikkelmethoden. In alle organisaties waar wij mee werken, zijn er teams die iets “agile-achtigs” doen. Je vindt ze vooral binnen IT maar ook steeds meer daarbuiten. Wat maakt dat deze methoden helpen om in te spelen op dynamiek is onderwerp van een ander artikel.

Vanuit de goede ervaringen met agile ontwikkelen, ontstaat de behoefte om dit op grotere schaal toe te passen om op die manier een antwoord te vinden op de uitdaging om organisatiebreed sneller in te kunnen spelen op veranderingen. Maar dit is nog niet zo eenvoudig. Wat werkt op het niveau van een team, werkt nog niet zomaar op het niveau van meerdere teams, laat staan op het niveau van een hele organisatie.

Schalen

Gelukkig zijn er meer plekken waar ze hierover nagedacht hebben. Er zijn al de nodige best practices (of: frameworks) van het schalen van agile werken waaruit je kunt putten - zie ook de links onderaan dit artikel. In de praktijk komen wij vooral Scaled Agile Framework (SAFe) tegen en in mindere mate Scrum@Scale en Large Scale Scrum (LeSS). Ook de matrixstructuur van Spotify wordt veel als voorbeeld aangehaald.  

Voor ons vormen deze modellen en implementaties inspiratiebronnen. Ze bevatten structuuroplossingen die de samenwerking tussen grotere groepen medewerkers ondersteunen met zo min mogelijk coördinatie.

Welk model een goede inspiratiebron vormt, hangt af van het vraagstuk - waar zijn we naartoe onderweg en waar staan we nu? Er zijn zelfs situaties waarbij een inspiratiebron nu heel erg helpt maar gaandeweg overboord gegooid moet worden. Dit zien wij bijvoorbeeld bij SAFe - een model met veel lagen, rollen en besturingsproducten. Dit sluit goed aan bij een organisatie die bureaucratische kenmerken heeft. Het SAFe model geeft ruimte aan teams die op basis van agile werkprincipes samenwerken aan een product of dienst, terwijl ook de rollen en verantwoordelijkheden uit de “oude” organisatie een plek krijgen. Zo krijgt het verhogen van wendbaarheid op grotere schaal (meerdere teams) een goede kans.  

Zo kunnen modellen dus ook een onderdeel van de veranderstrategie zijn. Wendbaarheid betekent namelijk in onze ogen ook dat de vorm waarin we samenwerken continue aan gesleutel onderhevig is. Er is geen “end state”.

Lokaal en eenduidig 

Aan de slag gaan met schaling is balanceren tussen ruimte laten (“waarom is hier niet al over nagedacht?”) en structuren bieden (“dat gaat hier dus echt niet werken”). We zijn met zijn allen een organisatie waarin we met elkaar iets te doen hebben. Dit betekent dat we minimaal een set aan uitgangspunten hebben hoe we ons werk organiseren. Daar bovenop kunnen we keuzes maken in hoofdstructuur, rollen, ceremonies, werkmethoden, etc. 

Een “hele systeem”-blik is bij het kiezen van de uitgangspunten een vereiste: wat is er nodig en waar moeten we vooral afscheid van nemen als je niet alleen individuele teams maar een hele organisatie wendbaar wilt laten zijn.

Belangrijk om hierbij te beseffen is dat wendbaarheid lokale oplossingen vraagt die lokaal – bij ieder team en in de samenwerking tussen teams – moeten worden vormgegeven. Wendbaarheid vraagt ruimte. Die ruimte staat altijd op spanning met de behoefte om de manier van werken binnen een organisatie te standaardiseren. 

Minder structuur bieden is mogelijk als de bedoeling helder is – zowel op het niveau van het werk wat we te doen hebben als de manier waarop we dat werk doen. Professionals zijn prima in staat om vanuit die bedoeling te bepalen wat hen te doen staan en hoe dat te organiseren.

Doorbreken van patronen

Dit vraagt van managers dat ze een andere rol gaan vervullen. Het organiseren van werk komt bij het team te liggen. Management kan helpen bij de groei van het team richting zelforganisatie en bij het oplossen van obstakels die buiten het bereik van de teams liggen.

Nieuwe manieren van samenwerking vormgeven betekent vaak ook oude patronen doorbreken. Patronen tussen management en medewerker, tussen verschillende bloedgroepen (specialismen, vroegere afdelingen). Deze patronen zijn ingesleten over een lange periode en meestal niet zichtbaar voor de mensen die er een rol in spelen. Hoe je patronen bespreekbaar kunt maken komen we in een volgende post op terug.

Verder lezen over schalingsmodellen van agile werkprincipes?

Large Scale Scrum (LeSS) - https://less.works/

Scaled Agile Framework (SAFe) - http://www.scaledagileframework.com/

Scrum@Scale - https://www.scrumatscale.com/

Disciplined Agile Delivery (DAD) - http://www.disciplinedagiledelivery.com/agility-at-scale/large-agile-teams/

Nexus - https://www.scrum.org/resources/nexus-guide

Grows Method - http://growsmethod.com/

In onze verandertrajecten zien we regelmatig de negatieve effecten van inputsturing. Input is bij kenniswerk makkelijker te meten en de meeste meetsystemen zijn rondom input opgezet: hoeveel uren hebben we aan welk werk besteed? Onder de aanname dat input en output direct aan elkaar gerelateerd zijn, gaan we sturen op bezettingsgraad (zorgen dat iedereen goed volgepland is, want dan leveren we maximaal), gaan we schuiven met codes (uitnutting moet kloppen met budget, want dan zijn we voorspelbaar), gaan we gemaakte uren relateren aan voortgang (aantal bestede uren zeggen iets over voortgang), etc.

Het is geen rocket science om in te zien dat hier een hoop aannames worden gedaan die in veel gevallen niet opgaan. Helaas blijven deze meetsystemen en meetmethoden in stand. Deels vanuit gewoonte maar deels ook vanuit onbekendheid - onbekendheid met dat het anders kan en hoe je dat dan doet.

In dit kader het ik met interesse “Leiding geven zonder cijfers” gelezen van Filip Vandendriessche en Han Looten. In het boek wordt outputsturing uitgelegd en worden de verschillen met inputsturing helder uiteengezet. Vervolgens gaan de auteurs in op wat er komt kijken als je outputsturing als leidend principe in je organisatie toepast - voor manager en medewerker.

Het boek is lichte kost en vooral goed te lezen als beeldvorming - wat is dat nou, die outputsturing? - en een handreiking om de discussie over input- en outputsturing in je organisatie aan te zwengelen.

Na het bespreken van de vraagtekens bij Agile werken zoals je dat in de praktijk tegenkomt en de schoonheid die er in potentie in zit (zie voorgaande blog posts), is het tijd voor een antwoord – hoe moet het dan? En zo volgde ons 7 stappenplan – een instant bestseller. Ware het niet dat stappenplannen eerder een onderdeel zijn van het probleem, dan van de oplossing. Toch is er op basis van de besproken vraagtekens en verandertheorie en –praktijk wel iets te zeggen.

De obstakels en valkuilen overziend is onze eerste conclusie dat Agile weliswaar veelbelovend is en in veel opzichten antwoorden heeft voor de klassieke problemen die in IT-organisaties voorkomen, maar dat de impact sterk afhangt hoe Agile wordt begrepen, hoe het wordt geïntroduceerd en met welke scope. Met de ideeën van complex responsive processes (Stacey, 2003) in het achterhoofd is het belangrijk om ook de rol van de veranderaar/begeleider niet te overschatten.

Agile op een Agile manier

Al reflecterend op onze ervaringen met de introductie van Agile werken zie ik dat Agile antwoorden kan bieden als het proces waarmee Agile wordt geïntroduceerd zelf Agile wordt vormgegeven. Waarin voor mij de Agile principes “individuals and interactions” en “responding to change” eruit springen.

Voor mij roepen individuen, interacties en inspelen op verandering een beeld op van dansen met elkaar. Als we dat goed doen zijn we terug bij de schoonheid die ik zoek. Overigens zie ik die schoonheid niet in zomaar iedere dans. Voor mij is het hier de Argentijnse Tango die we gaan aanschouwen. De Argentijnse Tango kent basisfiguren maar geen patronen. De danspatronen ontstaan in interactie tussen de dansers.

Vrijheid en duidelijkheid

In Agile werken als dansen, speelt het begrip participatie als gezamenlijk bewegen in elkaars nabijheid (Brohm & Muijnen, 2010/2) een centrale rol. Dit vereist bewegingsvrijheid maar zoals eerder betoogd is vrijheid ook niet alles. Op een Agile wijze Agile werken introduceren betekent dan ook niet dat er geen kaders zijn. Vanuit de dansmetafoor zijn er basisfiguren en het helpt als alle deelnemers die kennen. Daarnaast is het bij het leren belangrijk dat je feedback krijgt op hoe je danst, van je danspartner, van je leraar en die meedogenloze spiegels aan de muur. In een stap naar meer Agile werken is het niet anders. Er zijn basisprincipes en methoden die prima helpen om de samenwerking op gang te brengen of te verbeteren. Hierbij spelen korte feedback loops een belangrijke rol en is er zeker een plek voor meten en rapporteren – voor zover dit bedoeld is om het eigen werk te verbeteren.

Het werken met deze basisprincipes vereist balanceren omdat “volgens het boekje”-werken op de loer ligt. Hiermee bewegen we weg van de lokale werkelijkheid en van met elkaar dansen. Het lerende karakter kan echter onderstreept worden door weg te blijven van de standaard termen – door bijvoorbeeld wel een aantal Scrum methoden te kiezen en hiermee een houvast te geven maar deze methoden andere namen te geven (zo blijkt er meer ruimte om kritisch na te blijven denken als je iemand “flow master” noemt, ook al doet hij verdacht veel dingen die een – in vele boekjes tot in detail gedefinieerde - “Scrum master” doet). Hiermee kan de verandering niet in een specifiek Agile hokje worden geplaatst en blijft er meer ruimte om de toekomst met elkaar te construeren.

In het construeren is het belangrijk om de verschillende hiërarchische niveaus te betrekken. Zoals eerder betoogd verandert Agile werken iets aan machtsverhoudingen in een organisatie. Als niet vanaf het begin de belangen van alle betrokkenen aanwezig zijn bij het vormgeven van de samenwerking, zal er weinig vertrouwen zijn bij die “laag” die met de uitkomsten wordt geconfronteerd. Om goed te kunnen dansen, om te kunnen en willen participeren, is vertrouwen belangrijk. Dit is een flinke opgave als je start in een situatie waar het vertrouwen laag is.

De vraag hoe je dit met elkaar vormgeeft zou centraal moeten staan in de verandering. Hanson (1976) geeft suggesties hoe het werkveld van de manager en de professional ten opzichte van elkaar ingericht zouden moeten worden. Hierin klinkt echter een geest uit het verleden door. Volgens mij is hier niet één antwoord goed maar is de dialoog belangrijk.

Waar dit geldt voor verschillende niveaus binnen de IT organisatie, geldt het ook voor de IT organisatie en haar klant(en). Agile erkent dat om echt te kunnen dansen in een omgeving waar veel onzekerheid is over de vraag van de klant, het belangrijk is dat die klant ook participeert. Dit is in veel organisaties een grote verandering omdat er veelal gewerkt wordt met een demand / supply model waarin IT als leverancier wordt gezien door de “business” (de non-IT afdelingen), die je via een loket of afgevaardigde “belangenbehartiger” benadert. Het niet meenemen van de klant leidt ertoe dat het dansfeest regelmatig wordt verstoord – de muziek gaat uit of er wordt ineens een ander nummer opgezet.

Dit betekent dat Agile werken een organisatieverandering is die niet beperkt is tot de IT afdeling. Dit betekent ook iets voor hoe een dergelijk verandertraject wordt gepositioneerd – wie is de opdrachtgever, wie doen er mee aan de analyse, wie zijn er betrokken bij de verandering? Bij het beantwoorden van deze vragen is een keten-blik nodig: wie gaan er straks mee de dansvloer op?

Het laatste dat ik in het kader van vrijheid en duidelijkheid zou willen stellen is dat het introduceren van teamwerk en het beleggen van verantwoordelijkheden bij teams vereist dat er aandacht is voor het ontwikkelen van teams. Agile heeft geen antwoorden op teamdynamiek. Het feit dat mensen dagelijks bij elkaar staan bij een bord en dat ze iedere drie weken reflecteren op het werk dat ze hebben gedaan, maakt niet dat ze als team stappen maken. Juiste het werken aan de “zachte waarden” is cruciaal om ervoor te zorgen dat er werkelijk samen gedanst wordt, in plaats van dansen naar de pijpen van een nieuw (meet)systeem.

Betekenisvol

Participatie in het dansen vereist dat de veranderingen, het verandertraject en de eventuele begeleider(s) aansluiten op de lokale werkelijkheid. Een werkelijkheid die steeds geherdefinieerd wordt en zo verandert. Het proces is een deling en herijking van betekenissen – over hoe het nu gaat, wat we voor ogen hebben en welke stappen we moeten nemen. We zetten stappen en evalueren de uitkomsten, om zo ons pad weer bij te stellen. Het veranderen zelf is dan ook geen van buitenaf opgelegd verandertraject maar ontstaat vanuit de groep mensen die met elkaar aan het dansen slaat. Veranderingen verlopen op deze manier kleinschalig (binnen een groep van met elkaar samenwerkende mensen). Dit kan best tegelijk op meerdere plekken in een organisatie gebeuren, maar in hun wezen zijn dit verschillende veranderingen.

Goed begrijpen hoe het nu gaat – als basis om te begrijpen wat er nodig is – betekent ook het begrijpen van de patronen waarin iedereen nu gevangen zit. De overtuigingen die schuil gaan achter die conflicten staan het dansen in de weg. Ze blokkeren mensen om een stap te zetten naar de dansvloer en ze blokkeren mensen in hun bewegingen op de dansvloer. Voor ons betekent dit dat het zoeken naar en bespreekbaar maken van patronen een centraal punt moet zijn bij iedere verandering richting schoonheid - hierover meer in een volgende blog post. Het vinden en onderzoeken van de heersende patronen is een zoektocht die de in een verandering betrokken medewerkers en begeleider(s) samen maken. 

In voorgaande blog posts hebben we mechanismen gedeeld die de kracht van Agile in de praktijk beperken. Toch heeft de Agile-beweging wel het nodige in huis om de kwaliteit van het (samen)werk(en), de kwaliteit en omvang van het geleverde en de flexibiliteit te vergroten. Het contrast is het grootst als je Agile plaatst naast de principes van bureaucratische organisaties waarbinnen mensen als productie-eenheden worden beschouwd, zoals treffend betoogd wordt door Kuipers et al (2012): De kern van onze kritiek op "het bureaucratisch model" is dat zij in complexe en dynamische omstandigheden haar doelstelling van beheersbaarheid van grote sociale systeem door complexiteitsreductie niet bereikt maar - ironisch genoeg - juist het tegendeel in de hand werkt. Als men mensen tot dingen wil reduceren loopt men, afgezien van het moreel ethische aspect, tegen twee in bedrijfskundig opzicht ernstige problemen aan. Het eerste probleem is dat mensen zich niet laten reduceren tot dingen. Pogingen dat wel te doen gaan gepaard met vele disfuncties die te maken hebben met de kwaliteit van de arbeid. Het tweede probleem is dat de bureaucratie de complexiteit van de organisatie probeert te reduceren door mensen als eenvoudige dingen te behandelen. Dit kan alleen door de complexiteit van de structuur van de organisatie drastisch te vergroten.

Al heel lang wordt dit tegengeluid in de wereld gezet vanuit de sociotechniek. De moderne sociotechniek zet een aantal organisatieprincipes tegenover dit bureaucratische model en – zoals we zo zullen zien – blijkt Agile daar goed aan te voldoen. Bedenk daarbij wel dat Agile een label is voor een breed scala aan verschillende manieren van werken (binnen met name IT). De uitgangspunten zijn op hoofdlijnen dezelfde – ze volgen allemaal het Agile Manifesto - maar iedere Agile vorm heeft zijn eigen receptenboek met een voorgeschreven structuur, werkprocedures en besturing (Larman, 2004). Het ene receptenboek is wat dikker dan het andere. Veel van de inspiratie voor Agile komt uit de hoek van productontwikkeling (Takeuchi & Nonaka, 1995) en uit het Lean gedachtegoed (Womack & Jones, 1996). In haar praktische uitwerking (meestal Scrum of een afgeleide versie) komt Agile bekend voor als je het projecteert op de principes van de moderne sociotechniek. Wat in ieder geval terugkomt:

Parallelliseren en homogeniseren van werkstromen

Taakgroepen (teams als eenheden)

Zelfcoördinatie (regeltaken in het team)

Ondersteunende informatie- en planningssystemen

 In Agile implementaties (zoals Scrum) komen deze principes als volgt terug: het werk wordt georganiseerd in vaste multi-skilled teams die bij voorkeur werken voor een vaste groep klanten (1,2). Deze teams nemen niet alleen de uitvoering maar ook een groot deel van de coördinatie van het werk voor hun rekening (3). De regelruimte binnen de operatie neemt hierdoor toe. Met behulp van een set aan processen die de samenwerking met de buitenwereld en binnen het team faciliteren, ondersteunende middelen (4) en korte feedback loops neemt ook de regelcapaciteit toe. Door afspraken over hoe teams met elkaar samenwerken in een keten en over ketens heen wordt de regelbehoefte verkleind. Systeem-dynamisch (met Ashby’s Law in het achterhoofd) een mooie oplossing om gecontroleerde wendbaarheid te krijgen.

Naast gecontroleerde flexibiliteit levert deze organisatie-inrichting nog meer voordelen. Door als een team een hele taak op je te nemen krijgt het werk meer betekenis. In plaats van dat jij een ultiem ontwerpdocument schrijft, of een stukje software codeert, ben jij samen met je teamleden bezig om een product voor een klant te realiseren (in sociotechnische termen neemt de kwaliteit van de arbeid toe). Door dit werk in zo kort mogelijke iteraties te doen ontstaan korte feedback loops die nodig zijn om snel te kunnen leren en de wijze van werken bij te kunnen stellen. In Agile wordt hier aandacht aan besteed door na iedere iteratie een zogenaamde “retrospective” te houden met het hele team. Blokkerende zaken binnen en buiten het team komen zo op tafel. Of dit in de praktijk zo uitpakt hangt van nogal wat zaken af (zie de eerder beschreven mechanismen).

Parallel aan de Agile beweging binnen IT zie je vergelijkbare bewegingen in andere organisatiedomeinen – deels ongetwijfeld geïnspireerd door het succes van Agile binnen IT. ING gaat daarin zo ver dat ze Agile met al haar terminologie (zoals “squad” voor een team) organisatie-breed heeft doorgevoerd. Stephen Denning (2010) heeft de principes vertaald naar wat hij “Radical Management” noemt – een manier om de hele organisatie op een Agile wijze te besturen.

Er zijn – zeker daar waar Agile principes organisatiebreed worden toegepast - duidelijk parallelen te herkennen in de ontwikkeling van organisaties richting het stadium van “levend organisme” zoals beschreven door Frédéric Laloux (2014, zie onderstaande figuur voor de ontwikkelstadia die hij herkent). Een voorbeeld dat door Laloux wordt aangehaald is het Nederlandse BuurtZorg. Je kunt het hem zelf hier horen vertellen.

Met Agile bewegen we naar een implicieter coördinatiemechanisme dan de klassieke interne controle binnen de bureaucratie. Dit coördinatiemechanisme is gebaseerd op participatie van de medewerkers. Zoals Brohm en Muijen (2010/1) het verwoorden: Participatie gaat uit van vrijwilligheid van de werker om te doen wat niet geëist wordt, om uit te voeren zonder supervisie, om te handelen op basis van eigen inzicht en motivatie. Het gaat uit van vertrouwen tussen verschillende partijen, zodat er niet uitsluitend wordt gehandeld uit eigenbelang, maar ook vanuit gezamenlijk belang.

…Waarom werkt dat agile toch niet altijd en overal? Ik herken een paar mechanismen die ik graag zou willen delen in de komende blog posts…

In een poging om helderheid te krijgen over de manier van werken, blijkt het prettig om terug te grijpen op voorbeelden (“best practices”). Hier is het goede nieuws dat er in het geval van Agile meerdere smaakjes met hun eigen receptenboek zijn. De meest toegepaste methode heet Scrum en komt met een beschrijving van processen, rollen en werkmethoden tot op het niveau van welke meetings nodig zijn met welke frequentie en welke agenda. Een fijn gevoel in een verandering waar er al zoveel onzeker is. Voor zover het om rechttoe rechtaan keuzes gaat, is het volgen van deze recepten een manier om snel stappen te zetten.

In de praktijk blijkt dit echter een oplossing met een vervelende bijwerking: we stoppen met kritisch denken. Dit werkt twee kanten uit: er worden principes geïntroduceerd die niet nodig zijn en geen werkbare oplossing bieden voor de situatie, of er ontstaat veel weerstand wanneer iets juist niet volgens het boekje gaat (“we doen hier weer ‘Scrum in name only’” – met de ondertoon dat het dús niet gaat werken). Het denken in deze recepten is daarnaast een steunpilaar onder het denken in grootscheepse “uitroltrajecten”. Als er een recept te volgen is, dan kan het toch niet moeilijk zijn om dat met iedereen even in een plenaire sessie te doen. Hiermee ligt Agile als nietsbetekenende hype op de loer.

Een voor mij veelzeggende reactie vanaf de werkvloer op Agile als weinig betekende hype is te vinden op de website programming mo-fo (de domeinnaam doet al het nodige vermoeden). In nogal expliciete taal geven de makers – software programmeurs – aan dat Agile in welke vorm dan ook alleen maar de volgende hype is die het echte werk in de weg staat: “We are a community of mo-fo programmers who have been humiliated by software development methodologies for years. […] We must destroy these methodologies that get in the way of...Programming, Mo-fo.” Ze geven een ontnuchterend beeld hoe het Agile Manifesto er voor de programmeur in de praktijk uitziet.

…Waarom werkt dat agile toch niet altijd en overal? Ik herken een paar mechanismen die ik graag zou willen delen in de komende blog posts…

Professionals zijn ook maar mensen (sic), en hebben de behoefte om te weten of ze goed bezig zijn gegeven het doel dat ze proberen te realiseren. Binnen de meeste Agile-aanpakken is in deze behoefte goed voorzien met standaard meeteenheden, manieren en frequenties van meten en rapporteren. Al deze informatie is bedoeld voor het team en gericht op het realiseren van zoveel mogelijk kwalitatief goede software. Als dit goed ingericht is, kan een team al lerende steeds beter voorspelbaar leveren en over tijd ook steeds meer.

So far, so good. In een klassieke hiërarchische organisatie zijn er echter veel meer metertjes die gevolgd worden en die de juiste waarde moeten krijgen. Dit legt een druk op teams om veel meer informatie te geven en met veel meer zekerheid dan mogelijk is. Daarnaast worden er op verschillende niveaus en plekken in de organisatie afspraken gemaakt over leveringen die gevolgen hebben voor de operationele teams – zonder dat deze daar bij betrokken zijn. De Agile werkwijze ondersteunt in zo’n geval enkel het opbouwen van een panopticum: het team levert de informatie op basis waarvan het management meer druk kan uitoefenen op het team richting commitments waar het team geen invloed op heeft. Door de grotere transparantie kan het management vanaf het bureau sturing geven aan de hele operatie op basis van zijn dashboard. Er zijn nieuwe begrippen geïntroduceerd (squads, scrum master, etc.), het team is aangepast, er zijn nieuwe procedures in werking getreden en nieuwe middelen in gebruik genomen (een flowbord met gele briefjes) – maar voor de gemiddelde medewerker is er niets veranderd.

Geconfronteerd met een management dat Agile gebruikt om grip te krijgen op de uitvoering en zo beter te kunnen sturen op resultaten waar de medewerkers in de uitvoering geen stem in hebben gehad, zie ik geen schoonheid ontstaan. In de theorie en praktijk zie ik dan één van de volgende twee dingen gebeuren:

Het team beweegt mee. Wat bedoeld was als basis voor een lerende organisatie wordt een dashboard van een panopticum. Het team laat zich vastpinnen op meeteenheden die initieel bedoeld zijn als richting. Inschattingen worden commitments. In de praktijk valt het werk nogal eens tegen en blijkt het heel moeilijk om “nee” te zeggen wanneer er extra werk met hoge prioriteit wordt aangeboden. In dit soort gevallen wordt de werkdruk regelmatig zeer hoog – vooral rondom voor de organisatie belangrijke oplevermomenten. Het gevolg is stress-gerelateerde uitval.

…Waarom werkt dat agile toch niet altijd en overal? Ik herken een paar mechanismen die ik graag zou willen delen in de komende blog posts…

Aan de ene kant is er in organisaties een oerconflict (zie mechanisme #2) waarin managers proberen medewerkers te laten doen wat ze willen terwijl aan de andere kant professionals proberen om sturing en beheersing te vermijden. Zo bezien lijkt een beweging naar meer autonomie een beweging die tot gejuich zou moeten leiden bij de professionals. In de praktijk zie ik echter regelmatig dat dit niet de reactie van de professionals is. De beweging naar meer autonomie wordt ontvangen met weerstand vanuit een onzekerheid wat er nu verwacht wordt, wie er dan wel de knopen gaat doorhakken - waar is de baas en waar zijn de piketpaaltjes?

Professor Hans Doorewaard (Radboud Universiteit) refereerde hier ooit aan tijdens één van zijn colleges door te wijzen op het "aangename van de kooi". Hij gebruikte daarbij het beeld van Sisyphus die de goden tegen zich in het harnas wist te jagen.

Sisyphus werd veroordeeld tot het omhoog rollen van een grote steen tegen een heuvel. Iedere keer als de steen bijna boven is, rolt hij weer naar beneden en zo is Sisyphus tot het einde der tijden bezig met deze nutteloze bezigheid. Hans Doorewaard gaf aan dat je Sisyphus ook kunt zien als een tevreden mens met een duidelijke opgave en elke keer als hij boven op de heuvel staat bewondert hij het uitzicht en loopt met zijn handen op zijn rug fluitend naar beneden. Sisyphus is zonder hoop maar dit is iets anders dan dat hij hopeloos is. Professor Doorewaard is ongetwijfeld door Camus (1955) op dit pad gezet:

I leave Sisyphus at the foot of the mountain. One always finds one's burden again. But Sisyphus teaches the higher fidelity that negates the gods and raises rocks. He too concludes that all is well. This universe henceforth without a master seems to him neither sterile nor futile. Each atom of that stone, each mineral flake of that night-filled mountain, in itself, forms a world. The struggle itself toward the heights is enough to fill a man's heart. One must imagine Sisyphus happy

. Overigens legt Camus zelf de link tussen het absurde van de opdracht die Sisyphus heeft en het werkzame leven:

The workman of today works every day in his life at the same tasks, and this fate is no less absurd. But it is tragic only at the rare moments when it becomes conscious.

De ruimte die ontstaat, de vrijheid om de kooi te verlaten – of in Camus’ termen de “consciousness” die ontstaat, is klaarblijkelijk niet alleen maar winst:

Vrijheid garandeert geen zekerheid, het leidt tot een hoop mentale pijn. In de praktijk betekent het blootstelling aan ambivalentie. (Enzensberger 1989). Dit is een onzekerheid die bovenop de angst en onzekerheid komt die verandering in algemene zin oproept. 

Zoals Stacey (2003) het verwoordt:

…Waarom werkt dat agile toch niet altijd en overal? Ik herken een paar mechanismen die ik graag zou willen delen in de komende blog posts…

Een belangrijk element in het Agile werken is het zelfsturende of zelf-coördinerende team. Dit is het element dat het sterkste botst met de modus operandi in bureaucratieën.

De Caluwe en Vermaak (2014) beschrijven 5 vaste faalfactoren bij zelfsturing:

1. De taak van het team is niet autonoom genoeg 2. De doelen zijn veel te ambitieus 3. Het team is een geïsoleerd experiment in een ouderwets werkende organisatie 4. De baas laat het team niet met rust 5. Zelfsturing wordt vooral met de mond beleden

Het weerbarstige karakter van de bureaucratieën waarin ik werk, leidt vooral tot punt 3, 4 en 5 en heeft alles te maken met de machtsverhoudingen die onder druk komen te staan bij de implementatie van zelfsturing. Het is een overgang van positioneel naar transactioneel organiseren (Wierdsma, 2009): Bij positioneel organiseren is kenmerkend dat de top zich verantwoordelijk voelt voor het geheel en verwacht dat de medewerkers zich bekommeren om hun eigen deel. Maar als klantvragen meer gaan verschillen en snelheid van handelen gewenst is, dan worden de beperkingen van het positionele organiseren zichtbaar. Het teruggrijpen op regels en hiërarchie werkt dan te traag en te beperkend. Samenwerking tussen medewerkers bepaalt nu het succes. Positioneel organiseren richt zich op posities en deelbelangen. Bij transactioneel organiseren daarentegen is er op alle niveaus een oriëntatie op het leveren van bijdragen aan de transactie met de klant.

Kloosterboer (2015) noemt dit een ontstekingsbron: Dit lastige dilemma is ook te zien als afgeleide van het universele streven naar coördinatie en beheersing vanuit de leidinggevende positie en de al even universele drang naar autonomie en handelingsvrijheid vanuit het niveau daaronder. Deze ontsteking zit ingebakken in alle verticale relaties. Of het nu gaat om een raad van bestuur en hun directeuren, of om een teamleider en zijn medewerkers.

…Waarom werkt dat agile toch niet altijd en overal? Ik herken een paar mechanismen die ik graag zou willen delen in de komende blog posts…

Wat me opvalt als ik kijk naar Agile implementaties, is dat er veel gekozen wordt voor een groot veranderprogramma waarbij sprake is van het uitrollen van een methode in plaats van veranderen met mensen. Er zijn grote agile implementatiepartijen die vaste recepten hebben om Agile te brengen. Ze bieden ook trainingen van twee dagen om de cultuur mee te kunnen veranderen bij de implementatie – want die cultuur kan nog wel eens lastig zijn. 

De taal is blauw[1]. Dit is niet zo heel erg verwonderlijk als je naar het profiel van de gemiddelde IT-er kijkt (van professional tot en met manager) en als je je beseft dat het rationele nu de overhand heeft. De leidende overtuiging is dat de organisatie maakbaar is en dat Agile prima recepten biedt die je kunt implementeren.

Het is wel wat opmerkelijk als je bedenkt dat twee van de vier centrale uitgangspunten van Agile zijn:

Individuals and interactions over processes and tools

Responding to change over following a plan

Er is veel geschreven over de beperkte maakbaarheid van organisaties en over het emergente karakter van veranderingen. Homan beschrijft het mooi in Etcetera-Principe (2013). Hij maakt hierbij een bricolage van verschillende theorieën zoals de complexiteitstheorie, fractals en Complex Responsive Processes om aan te tonen dat planmatig veranderen een kansloze exercitie is. Vroemen stelt dat “veranderen van organisaties” in dit licht nogal aanmatigend is, en dat beïnvloeding het beste is waar we op kunnen hopen (Vroemen, 2005). 

Door wel top down een verandering door te voeren ontstaat er vooral weerstand. Deze weerstand is bij professionals niet altijd even goed zichtbaar maar toch desastreus voor de (samen)werking van/binnen de organisatie. (IT) Professionals zul je minder snel met spandoeken bij het hoofdkantoor zien staan. Zij hebben daarentegen door hun rol – die vraagt om creatief inspelen op niet-standaard situaties in het werk – iedere dag de mogelijkheid om iets niet op te pakken of niet te fixen, waardoor processen niet meer lopen zonder dat iemand daar op aan te spreken is. Deze manier van weerstand leveren staat bekend als pocket veto (ook wel: passive aggressive resistance). In een veranderproces betekent dit dat het bewijs dat de nieuwe ideeën niet werken snel geleverd is.

De wereld van IT-ontwikkeling staat al heel lang bekend om haar onbetrouwbaarheid. Software projecten worden al zo lang iedereen zich kan herinneren te laat geleverd en tegen hogere kosten dan begroot. Vaak is er bij de oplevering ook nog het nodige op te merken over de inhoud van hetgeen geleverd is.

Lange tijd wordt de oplossing gezocht in betere voorbereiding, meer plannen, betere risicoanalyse, strakkere faseovergangen in projecten, met andere woorden het verzwaren van de watervalmethode waarmee IT-projecten werden uitgevoerd. In de grotere organisaties heeft dit geleid tot formele processen en procedures met duidelijk gekaderde verantwoordelijkheden vertaald naar aparte afdelingen of teams. Een arbeidsdeling die prima past binnen de Tayloriaanse principes van organiseren.

Helaas blijkt dit verzwaren niet te helpen. Eén van de standaardwerken waarin de problemen van softwareontwikkeling worden beschreven is The Mythical Man-Month van Frederick Brooks. Brooks schreef de eerste druk van dit boek in 1975 maar moet in de 20-jarige jubileumuitgave concluderen dat er weinig veranderd is (Brooks, 1995) en dat geldt weer 20 jaar later nog steeds. De problemen zijn hardnekkig.

Op zoek naar antwoorden en met een schuin oog kijkend naar de glorieuze voorbeelden van succesvolle IT-bedrijven zoals Google, Amazon en Spotify is de laatste jaren agile omarmd als de panacee. Agile zorgt voor wendbare IT-organisaties en voorspelbare IT-levering tegen lage kosten, zo lijkt het.

Ik voel me aangetrokken tot twee facetten rondom de Agile beweging die ervoor zorgen dat de belofte niet ingelost wordt: het niet lukken van implementaties en de negatieve consequenties als het wel lukt. Het verschil op de werkvloer is niet per se groot maar in het eerste geval zal iedereen erkennen dat de verandering niet geslaagd is, terwijl in het tweede geval een deel van de organisatie zal verkondigen dat ze heel agile is.

Hierbij spelen veel factoren een rol maar ik herken een paar mechanismen die ik graag zou willen delen in de komende blog posts:

Het uitrollen van een methode als manier om te veranderen

Zelfsturing en het oerconflict

Het prettige van de status quo

Leven in een panopticum

In een aantal blog posts zou ik stil willen staan bij de potentie van agile werken en vooral bij de vraag waarom die potentie er vaak niet uitgehaald wordt. 

Ik baseer me hierbij op ervaringen in organisaties waarin mijn teamleden en ik aan de slag zijn (geweest) met uiteenlopende verandervraagstukken.