De tien mythes van Agile werken

Agile werken is in de afgelopen jaren buitengewoon populair geworden. Dat is niet zo gek, want de belofte dat je met een Agile organisatie goed bent toegerust voor de steeds complexere en sneller veranderende wereld is natuurlijk ook wel erg aantrekkelijk. Dit enthousiasme heeft ertoe geleid dat Agile soms bijna als een religie wordt omarmd, met de principes als de twaalf geboden van Agile en de zeventien ondertekenaars van het Agile Manifesto als apostelen. 

En net als bij religies is er discussie over wat het ware geloof is. Hier zie je een strijd tussen de preciezen en rekkelijken. De Agile-puristen houden sterk vast aan de letter van de Agile-principes; afwijkingen worden al snel bestempeld als ‘Niet Agile’. Daartegenover staan de Agile-pragmatici, die meer kijken wat in de praktijk werkt.

In die praktijk zien we dat veel organisaties ervaren dat Agile implementeren veel minder gemakkelijk is dan gedacht. De verleiding is groot om, wanneer Agile niet direct het resultaat oplevert dat je verwacht, terug te vallen op ‘oude’ gewoonten. Dat is jammer, want Agile is een hele krachtige werkwijze. In De 10 mythes van Agile werken hebben we daarom gezocht naar pragmatische oplossingen die gebaseerd zijn op de principes en de kracht van Agile. 

Agile als filosofie, organisatie of werkwijze

Er zijn drie niveaus gedefinieerd waarop je naar Agile kunt kijken.

Alle drie niveaus hebben een andere manier waarop ze ingrijpen op menselijk gedrag. Allereerst kun je Agile beschouwen als een filosofie, een cultuur of een mindset. Het gaat hier om het richtinggevende gedachtegoed achter Agile zoals geformuleerd in de vier waarden van het Agile Manifesto die je als leidraad in je gedrag kunt hanteren bij je manier van werken:

• Mensen en hun onderlinge interactie boven processen en hulpmiddelen
• Werkende software boven allesomvattende documentatie
• Samenwerking met de klant boven contractonderhandelingen.
• Inspelen op verandering boven het volgen van een plan.

Van een heel ander detailniveau zijn de werkwijzen zoals Scrum en Kanban die vaak met Agile werken worden geïntroduceerd. Met concepten als sprints, backlogs, stand ups en visual management wordt concreet handen en voeten gegeven aan Agile werken. Deze laag stuurt daarmee heel direct op gedrag. 

Tussen de high level filosofie en de praktische werkwijze is een tussenlaag die de verbinding vormt tussen deze twee: de organisatie. Bij het begrip organisatie wordt vaak als eerste gedacht aan de organisatiestructuur, maar het gaat hier ook over het beleid en de processen die nodig zijn om de individuele teams te laten functioneren. Deze laag is bij wijze van spreken het cement tussen de stenen en gaat over hoe mensen met elkaar samenwerken. 

Als je denkt vanuit het drielagenmodel Filosofie–Organisatie–Werkwijze, is onze ervaring dat bij grotere organisaties niet zozeer de filosofie achter Agile of de werkwijzen in de squads (zoals bijvoorbeeld Scrum) het ingewikkeld maken, maar vooral het ‘organisatie’-niveau. Je hebt namelijk altijd te maken met afhankelijkheden die vaak niet alleen groter in aantal worden, maar ook complexer naarmate organisaties in omvang toenemen.

Daarom gaan we hier vooral in op dit ‘organisatie’-niveau met drie mythes.

Drie mythes

1. ‘Squads kunnen onafhankelijk opereren’
   Als het gaat om Agile werken, wordt vrijwel zonder uitzondering de autonomie van het team benadrukt. Squads zijn zelf verantwoordelijk voor de ontwikkeling en vernieuwing van hun producten en kennen een hoge mate van zelfsturing.

   Autonome teams zijn zoals gezegd één van de pijlers van het Agile werken. Maar hoe autonoom kunnen teams daadwerkelijk werken in grotere organisaties? In de praktijk valt dit nogal eens tegen. Dit leidt tot problemen bij het opleveren van resultaten en tot veel frustratie bij in principe gemotiveerde medewerkers.
   Onze voorkeursrichting is om zo veel mogelijk afhankelijkheden te beperken. Het is echter een illusie om te denken dat in organisaties afhankelijkheden volledig te voorkomen zijn.

2. ‘De Product Owner bepaalt de prioriteit’
   De Product Owner is degene die in de Agile/Scrum methodiek de backlog, de werklijst van de squad, beheert en prioriteert. Of nog beter gezegd: ‘rangschikt’, want soms zijn er dingen die je eerst moet doen om items die hoge prioriteit hebben, te kunnen realiseren. Daarmee vervult de Product Owner een belangrijke rol binnen de squad, aangezien hij bepaalt wat het team oplevert en in welke volgorde. De vraag daarbij is hoe de Product Owner deze prioritering aanpakt.

   Bij de introductie van de Agile werkwijze in een organisatie wordt in het enthousiasme vaak de autonomie van de squads benadrukt. En aangezien de Product Owner de backlog prioriteert, lijkt het alsof hij helemaal zelfstandig kan bepalen wat er moet gebeuren. Daarom hadden we deze mythe ook wel ‘Zijn managers nog wel nodig?’ kunnen noemen, want als Product Owners de prioritering bepalen en de teams autonoom zijn, wat is dan nog de rol van een manager? Zeker in grotere organisaties, waar het uiteindelijke resultaat de optelsom is van het werk van een groot aantal squads, is het belangrijk dat de prioriteiten goed op elkaar afgestemd worden. In de praktijk blijkt dan ook dat volledig onafhankelijke prioritering door Product Owners een mythe is. Sterker nog: onze ervaring is dat er, na een eerste fase in de implementatie van Agile werken waarbij er een sterke roep om autonomie is, vanuit de organisatie juist gevraagd wordt om een duidelijke prioritering.

3. “Teams halen altijd het maximale uit zichzelf”
   Een impliciete aanname bij de introductie van Agile is dat teams altijd intrinsiek gemotiveerd zijn. Maar is dit ook zo?

   We hebben gemerkt dat motivatie iets is waaraan bewust gewerkt moet worden, ook al biedt Agile werken in autonome teams een goede basis. Er zijn grote verschillen tussen teams en vanwege het belang van het onderwerp is het interessant om te kijken wat hierbij de belangrijke factoren zijn. Allereerst maken we een onderscheid tussen de fase van het samenstellen van het team en de fase waarin het team al aan het werk is. Daarnaast gaan we in op de intrinsieke motivatie van Agile teams en de bijzondere rol van de Product Owner bij het motiveren van teams door het stellen van heldere prioriteiten en de feedback op de resultaten van de stakeholders met het team te delen.

Bonusmythe ‘Agile werkt alleen als je fysiek bij elkaar zit’

In de periode van de pandemie werd een andere mythe duidelijk. Agile is geïntroduceerd met veel vormen van samenwerking die zich bij uitstek lenen voor face-2-face werken, zoals stand up, refinement-sessie, demo en retrospective. Het leek er daarmee op dat Agile het best zou werken als je fysiek bij elkaar zit.  

In de afgelopen periode is echter gebleken dat Agile werken zich ook uitstekend leent voor werken op afstand. Sterker nog, onderzoek toont aan dat organisaties die de overgang naar Agile al hadden gemaakt beter in staat waren om zich snel aan te passen aan de pandemie. Achteraf gezien is dat eigenlijk ook niet gek. Het snel kunnen aanpassen is nu precies een belangrijk kenmerk van Agile werken. Met name het autonome karakter van de werkwijze, het zelf op basis van begrip van de strategie van de organisatie de juiste prioriteiten kunnen stellen, en een business- en IT architectuur die autonomie ondersteunt, vergemakkelijken het werken op afstand. 

Tegelijkertijd stellen we vast dat om goed op afstand Agile te kunnen werken er wel aanpassingen noodzakelijk zijn, onder andere in het gebruik van technische middelen en de manier waarop Agile coaches werken.

Agile the only way?

Door het enthousiasme over Agile, zie je dat op heel veel plaatsen Agile werken wordt ingevoerd. De vraag die daardoor steeds relevanter wordt, is of het verstandig is om Agile overal te implementeren. In de mythe ‘Agile is the only way’ stellen we dat dit geen zwart – wit discussie is. Of Agile de beste manier van werken is, is afhankelijk van diverse factoren zoals de markt, het probleem dat opgelost moet worden, autonomie en motivatie. Maar ook de bedrijfscultuur en zelfs nationale cultuur spelen een rol.

We verzetten ons dan ook tegen de gedachte dat onder het mom van ‘dat is niet Agile’ je op een heel specifieke manier invulling moet geven aan Agile, alsof het een precies omschreven methode is. Onze overtuiging is dat Agile op basis van haar principes juist uitnodigt tot een eigen invulling en niet tot het star volgen van een ‘Agile methode’, waarvan het nog maar de vraag is of die überhaupt bestaat. 

Agile gaat daarom voor ons veel meer over leren. Dat is de ook de reden dat we ervoor gekozen hebben niet met een how to- verhaal te komen maar de boodschap in de vorm van mythes brengen. We benadrukken daarmee dat het belangrijker is dat je zelf invulling geeft aan Agile dan dat je het precies ‘volgens het boekje’ doet.