Managementmythe van de maand: Agile Werken

Columns

Er is niets mis met ‘fan’ zijn van Agile werken, maar er is wel iets mis met de claim dat Agile werken meer succes oplevert dan traditionele vormen van projectmanagement. Die claim is de managementmythe van deze maand.

Wat is Agile werken?

Traditioneel projectmanagement betekent dat u een groot doel ver weg stelt.

Zo wil het team van Henk bijvoorbeeld een nieuw koekje op de markt brengen. Ze stellen als doel dat ze over een jaar 500.000 koekjes hebben verkocht en 150.000 euro winst hebben gemaakt. Anna’s team gaat Agile koekjes bakken. In een filmpje van de Scrum Company hoort u hoe dat werkt.

‘Ze maken geen uitgebreide plannen, maar gaan ontdekken wat het beste product kan worden’.

Anders gesteld: Anna’s team stelt geen grote doelen ver weg zoals bij Henk, maar gaat aan de slag en kij...

Branko Lastdrager
Er is vooralsnog geen enkel instrument, model, theorie of techniek die met 100% zekerheid tot succes leidt. Dus streep Agile in dit artikel door en zet er willekeurig model of gedachte voor in de plaats, zoals 'authentiek zijn', en je krijgt dezelfde conclusie.

Veel interessanter is dat blijkbaar velen van ons geneigd zijn deze open deur te vermijden, ontkennen of zelfs te bestrijden? Enkel omdat er ook zovelen een goede boterham aan verdienen? Of omdat ze de eigen claims oprecht onvoorwaardelijk geloven? Of is het onze behoefte aan zekerheid en risicomijding? Of juist van onze angst iets te missen, dat we ons met liefde laten overtuigen dat deze rimpelcrème echt helpt.

En hoe verhoudt dit zich tot bijvoorbeeld het placebo als ook het Hawnthorne effect? En daar is wel degelijk, heel degelijk onderzoek naar gedaan. De absurd dure pil (consultancy firma) stiekem gevuld met niet werkzame middelen (agile werken, etc.) die door een kundig arts (adviseur) worden voorgeschreven werkt in veel gevallen beter dan het werkelijke medicijn. Wat dat werkelijke medicijn (agile of aromatherapie) dan ook is?

Dat geeft de paradoxale situatie dat alle huidige succesformules, weliswaar niet met zekerheid kunnen claimen werkzaam te zijn, maar het placebo effect toch werkelijk een tastbaar effect geeft? Of zijn al die adviezen en formules wel degelijk werkzaam, is het echter enkel nog niet voldoende degelijk onderzocht en definitief bewezen?

Maar stel dat jij, en op den duur iedereen, het middel hebt dat gegarandeerd tot succes leidt. Het concept succes zou alle betekenis verliezen, aangezien iedereen en dus niemand succesvol zou zijn.

En nog erger, stel je voor dat je bij voorbaat al weet dat je succesvol bent, je de toekomst zogezegd al weet en tot verleden hebt gemaakt. Hoe lang zou het duren voordat je, uit intense verveling, gaat hopen dat er eens iets niet slaagt?

En laat het nu de wetenschap zijn die uit ervaring kan zeggen dat juist de vergissingen, de verkeerde methoden, de ongelukjes en gefaalde praktijkexperimenten vaak het grootste succes en de meest revolutionaire ontdekkingen in zich verborgen dragen. Of daar in ieder geval een cruciale rol in hebben.
Rik Pennartz
Lid sinds 2019
Agile werken heeft zich al lang bewezen in m.n. software ontwikkeling en voor dit soort projecten (software en systeem ontwikkeling) is het uitermate geschikt. De discussie ontstaat vaak door het feit dat veel mensen niet begrijpen voor welk type projecten agile het best werkt en voor welke projecten het minder goed of niet werkt. Voor agile werken moet het projectresultaat in kleine incrementen opgeleverd kunnen worden, die dus in een paar weken ontwikkeld kunnen worden én waarop we vaak feedback willen krijgen!
Gidion Peters
Beste Richard,

Mijn waardering voor je kritische blik op bewegingen in management- en organisatieland. Je eerdere kritiek op de Net Promotor Score vond ik persoonlijk heel waardevol. In dit artikel zitten echter een paar lacunes.

Omdat ik ook graag vanuit de empirie en met bewijsvoering werk, en het filmpje over agile van Scrum Company (waar ik werk) deel is van jouw stuk, doe ik graag een aantal correcties en aanvullingen.

Het is van belang om in het debat over agile, de scherpte te behouden. En wel op de volgende punten:
- Je claimt dat je in agile geen grote doelen ver weg stelt. Wat is daarvoor je bron? Je maakt geen uitgebreide plannen, maar grote doelen voor je project of organisatie(onderdelen) kun je zeker wel hebben wanneer je agile werkt. In Scrum en in modellen als SAFe kun je je grote doelen volop kwijt. En kun je er dus ook op evalueren.
- Je baseert het gebrek aan bewijs voor de winst die agile werken oplevert, op het gebrek aan validiteit van een specifiek rapport. Opvallend is dat beide wetenschappelijke kritieken op dat rapport die je aanhaalt gedateerd zijn (1 gaat over het eerste Standish rapport van 1994 (!), de volgende kritiek is uit 2008 en gaat ook terug tot 1994: tijden dat agile beperkt werd toegepast, daarnaast wordt nergens in de kritieken agile of Scrum genoemd.). Waaruit leid je, zonder verder onderzoek, af dat het Standish rapport van 2015 niet valide is? Het kan niet de quote zijn van Johnson die je aanhaalt, ook die komt uit 2008.
- Gelukkig vinden er meer onderzoeken plaats naar agile werken. Bijvoorbeeld Serrador & Pinto (2015): "Does Agile work? — A quantitative analysis of agile project success." Met als een van de conclusies: "There is a positive relationship between agile use and reported project success." Hier terug te vinden: http://www.sciencedirect.com/science/article/pii/S0263786315000071. Er zijn ook vele kwalitatieve analyses, surveys en scripties online te vinden, geen noodzaak om te cherrypicken. Op verzoek kan ik je een set toesturen.

Laten we dus van agile werken geen stroman maken, die we op basis van aannames over de werkwijze, en de validiteit van een specifiek onderzoek, neerzettten als 'religie'. Dat doet geen recht aan de vele, vele teams die met agile aantoonbaar succesvol zijn.

Groet!
Nico Viergever
Lid sinds 2019
Een prima artikel waarmee ik het in grote lijnen eens ben, zeker na de reactie van Branko.

Maar iets meer naar details kijkende, ben ik een groot tegenstander van het Agile dat momenteel wordt gepromoot door de IT-sector. Een grote reden is dat tijd en geld worden gefixeerd. Dat duidt op de Tayloriaanse denkwijze waar slechts op tijd en geld wordt gestuurd en waar alle andere variabelen zoals kwaliteit van veel minder belang zijn (zie: http://www.viergever.info/home-nl/blog/2016/april/waarom-falen-zoveel-projecten/). Dat wordt mij ook met regelmaat bevestigd door personen die aan de gebruikerskant zitten. Hun beleving van Agile door de IT-sector komt er meestal op neer dat er veel sneller en meer frequent wordt geleverd maar dat het veel langer duurt voor er eindelijk iets bruikbaars wordt geleverd. De Tayloriaanse denkwijze heeft als kenmerk dat flexibiliteit tot een minimum wordt beperkt. Het zogenaamde Agile is hierop gebaseerd en is dus verre van agile. Het is een “quick and dirty” aanpak.

Een ander vaak voorkomend probleem van de Agile aanpak is het gebrek aan integrale visie. Tijdens verhoren van de commissie Elias werd gesuggereerd dat de overheid geen grote projecten meer moest aanpakken maar slechts kleine overzichtelijke projecten moest uitvoeren. Dat klinkt logisch maar er is een grote tegenwerping. Wat is het meest gevaarlijke niet-nucleaire wapen waarover de VS beschikt? De clusterbom bestaat uit vele kleine bommen die los van elkaar zeer grote en langdurige schade aanrichten. Zo is het ook met vele kleine projecten zonder samenhang, zoals waarop met de Agile voor de hand ligt. Een echte projectaanpak met samenhang is daarom te prefereren.

Zelf zie ik het meeste in de basis van de PRINCE2 aanpak maar dan wel de echte aanpak voordat de IT-sector er een farce van maakte. Het grote verschil tussen deze aanpak en verreweg de meeste manieren om naar projecten te kijken, is dat PRINCE2 zich richt op de effecten die het resultaat moeten zijn van projecten terwijl andere aanpakken, inclusief Agile en SCRUM, alleen naar oplevering kijken. Dit laatste heeft als risico: Operatie succesvol, patiënt overleden. Kijk dus naar de lange termijn (Business Case) en reken daar op af; niet op de korte termijn oplevering van het project. Maar dat betekent wel dat een project niet langer door een (interne) leverancier maar door de klant gestuurd moet worden (dit is het gedeelte van PRINCE2 dat de IT-sector het liefst wegmoffelt want niet in hun belang). Maar goed opdrachtgeverschap blijkt nog altijd een enorm probleem en dat wordt door de Agile denkwijze helaas een nog groter probleem.
Patrick Van Alboom
Ik denk dat de redenering helemaal correct is wanneer het veranderingspad en het doel van de verandering volledig gekend is, m.a.w. wanneer het gaat om meer van hetzelfde (wat reeds gekend is). Dit is klassiek project management en werkt... maar niet voor alles. Wanneer het doel vaag is en het pad niet op voorhand gekend, maar gaandeweg ontdekt en genomen wordt... dan zijn benaderingen zoals Agile veel beter!
Als we niet incrementeel willen veranderen, maar een systeem structureel willen veranderen, dan hebben we andere benaderingen nodig. We weten immers dat het anders moet, maar niet of nog niet hoe. Dan werkt het maakbaarheidsidee van traditioneel verandermanagement niet. Dan is doen en meten en opvolgen veel meer eenzelfde act en een continue gebeuren. Er zit dus iets fundamenteels onvoorspelbaar in dergelijke transities.
By the way, traditioneel veranderbeheerd en projectmanagement kent dit ook wel. Denk bv. aan change requests of vragen die rijzen maar niet voorzien zijn in het plan. Uiteindelijk sturen dergelijke vragen het project in andere richtingen, soms zelfs zodanig dat op het einde van de rit er iets anders uit de bus is gekomen.
Marcel Rector
Lid sinds 2019
Weer eens een typisch geval van 'iedereen heeft gelijk, bekeken vanuit zijn/haar 'bubble'. Effecten op wetenschappelijke gronden meten van methodieken die alleen in een uitermate complexe wereld (dus bij lange na niet het ideale laboratorium experiment) plaatsvinden, is nauwelijks mogelijk. Het aantal verstorende elementen (alternatieve verklaringen) is dan 'per definitie' te groot om significante effecten te meten en op causale verbanden gefundeerde conclusies te trekken.

Maar ja, hoe verkoop je een dienst/product als je niet (wetenschappelijk) hard kan maken dat het effect heeft, of liever, hard kan maken dat het een beter effect heeft dan een concurrerend product of dienst? Dan roep je de hulp van marketeers in! Die hebben daarvoor bijzonder creatieve oplossingen, denk aan de 'wetenschappelijke claims' in de reclamewereld.

We weten dat het veel gebakken lucht is, maar mensen hebben een oerdrift die deze rationele kennis overstijgt: reductie van onzekerheid (overlevingsdrang). We willen graag een 'garantie' dat iets positief werkt. En we willen houvast (een methodiek) om ons handelen structuur te geven en daarmee 'fouten' en onzekerheden vermijden.

Het ontstaan van steeds weer nieuwe methodieken (vaak met een hoog 'oude wijn' gehalte) is dan een logische consequentie. Al sinds er ICT bestaat (ter illustratie), wordt er geklaagd over 'falende projecten'. Dus als er dan een nieuwe werkwijze wordt geboden, die claimt dat het 'vanaf nu' beter gaat, dan is de overstap snel gemaakt. Een oneindig proces, juist omdat het decor van ICT projecten meestal een uitermate complexe werkelijkheid is. Die kun je enigszins beheersen door de processen van A naar B te stroomlijnen (met een methodiek). Uiteindelijk hangt het succes van de methodieken af van de mensen(!) die ze gebruiken. Een positieve 'just do it' houding van alle stakeholders kan niet vervangen worden door welke methodiek dan ook. Het begint altijd met het verandervermogen en de veranderbereidheid, een PM-methodiek kan binnen die context het leven veraangenamen.

Kortom: luister vooral ook naar je onderbuikgevoel en vertrouw op je gezonde verstand. En toets geregeld of alle neuzen nog dezelfde kant uit staan. Teambuilding heet dat. Wetenschappelijk wel goed onderzocht en bewezen effectief!
Nico Viergever
Lid sinds 2019
Het een sluit het ander niet uit, Patrick. Agile is niet bepaald een nieuwe manier om met grote onzekerheden om te gaan.
Ook echte aanpakken voor projectmanagement praten over plannen, herplannen en omgaan met grotere onzekerheden. Kijk bijvoorbeeld hier eens naar (engelstalig): http://www.viergever.info/home-en/whitepapers/2015/december/prince2-waterfall/
Marjan
Toch jammer dat je verhaal alleen maar aantoont dat een van de onderzoeken die beweren dat agile werken meer succes oplevert, niet deugt. Bepaald geen sterke onderbouwing van je eigen "De claim dat Agile Werken meer succes oplevert klopt niet" uitspraak. Geldt hooguit voor de claim in het aangehaalde onderzoek.

Mis, zoals wel vaker, onderbouwing van de bredere implicaties van je uitspraak.

Jammer ook dat je niet op zoek bent gegaan naar degelijker onderzoek dat de claim kracht bijzet of juist ontkracht. Anderzijds, heb ik je wel vaker zien schrijven dat je ander onderzoek gezocht maar niet gevonden hebt, maar daar geen reproduceerbaar verslag van zien doen.

Click-bait.

Wel effectief. Ik tuinde er ook in. :)
Hanneke Jaques
Lid sinds 2019
“Geeft Agile werken meer succes dan traditioneel projectmanagement?”

In vind het een vreemde vraag…. Naar mijn mening is succes nooit afhankelijk van een gekozen methode, model of (organisatie)structuur, maar van de mensen die het laten werken.

Je kunt inderdaad geen objectief vergelijkbare projectsituaties creëren waarin alles (mensen, omstandigheden, budget, etc.) hetzelfde is, behalve de gekozen methode. Maar dat moet je ook niet willen. Juist de omstandigheden en de mensen zijn belangrijke bepalende factoren bij het maken van de keuze voor een methode. Afhankelijk van de omstandigheden kan op een bepaald moment de ene keuze namelijk wel logischer zijn dan de andere.

De onvoorspelbaarheid van deze tijd en behoefte aan feedback van klanten of andere belangrijke betrokkenen zijn twee van de redenen waarom vandaag de dag vaak gekozen wordt voor Agile.
Dat kan heel valide zijn, maar kies niet voor Agile, omdat iedereen het doet.
Houd anderzijds ook niet vast aan traditionele methoden, omdat je het altijd al zo gedaan hebt.

Beoordeel de situatie, neem alle relevante factoren mee in de afweging en maak dan een keuze voor de best passende methode. Sluit op voorhand niet uit dat je voor verschillende projecten, andere keuzes maakt.

Als je de beschikking hebt over hele goede traditionele projectmanagers, en ontwikkelaars die nog niet rijp zijn om zelforganiserende teams te vormen, maar liever traditioneel aangestuurd worden, zou ik niet zomaar overgaan naar Agile.

Niet elke goede projectmanager is namelijk ook een goede Scrum Master of Product Owner. Al wordt hier in de praktijk, bij het verdelen van de rollen, nog steeds soms vanuit gegaan.
Laatst hoorde ik van een hele afdeling HR consultants die allemaal de opleiding Scrum Master met goed gevolg hadden afgerond. Daar verbaas ik me echt over. Ik acht de kans heel klein dat het allemaal goede Scrum Masters worden of zijn. Een rol moet passen bij je talenten. Voor een Scrum Master moet er iets van een dienend leider in ‘je genen’ zitten. En de kans dat dat voor allemaal geldt, lijkt mij heel klein. Dat betekent dat deze mensen het risico lopen ‘op kracht’ deze rol te gaan vervullen. Terwijl we met talentmanagement juist proberen medewerkers ‘in hun kracht’ te krijgen.

Dus als je kiest voor Agile werken, doe het dan niet, omdat je verwacht dat het je zomaar meer succes oplevert. Het vraagt om slimme, onderbouwde keuzes en een gedegen, zorgvuldige voorbereiding, zeker voor en met de medewerkers die het moeten gaan doen.

Ik werd een keer gewezen op een quote, die wordt toegeschreven aan Deepak Chopra:
“If you focus on success, you’ll have stress. But if you pursue excellence, success will be guaranteed.”

Mijn associatie in dit verband: Ongeacht de keuze die je maakt, neem de consequenties en streef ernaar het heel goed te doen. Zorg dat alle betrokkenen voorbereid zijn op een manier die past bij de gemaakte keuze, dat er reële verwachtingen zijn, dat er helder gecommuniceerd wordt met alle betrokkenen en dat je de ontwikkelteams slim hebt samengesteld. Dat wil zeggen: passend voor het doel, passend bij de gekozen methode, gebaseerd op talent, gericht op optimale samenwerking.

En vergeet vooral niet dat Succes = Kwaliteit x Acceptatie. Geen wetenschappelijke formule, maar vanuit het perspectief van een ‘klant’ zeker waar. En die acceptatie of waardering voor de gerealiseerde oplossing is niet gegarandeerd door de keuze voor een bepaalde (projectmanagement)methode.
Robert Ilbrink
In Agile staat het grotere doel wel degelijk voorop, maar is niet strak gedefinieerd in een lijvig requirements document. Met een traditionele aanpak definieer je heel scherp de doelen vooraf. Die doelen kun je dan netjes afvinken en een succes noemen. In mijn wereld is er plaats voor allebei, afhankelijk van het type project, de situatie en de medewerkers.

Bij Agile stel je je doelen steeds bij op basis van de feedback na iedere sprint. Hierdoor is het eindresultaat meestal iets anders dan bij de traditionele aanpak. Dit geeft de indruk dat Agile "soft" is. Eigenlijk heeft Agile iets weg van "snelle natuurlijke selectie" en "survival of the fittest".

Het (software)eindproduct bij de traditionele aanpak moet, nadat het door de user acceptance test is gekomen en opgeleverd is, vaak nog maandenlang daarna aangepast worden juist omdat het precies volgens het requirements document is ontwikkeld, maar daardoor zelden werkelijk aansluit bij de behoeften van de gebruikers en omdat de behoeften door de tijd heen vaak zijn voortgeschreden. Soms zie je bij de traditionele werkwijze ongunstige beslissingen, die tijdens een Agile sprint al vroeg naar voren zouden zijn gekomen en zo vermeden. Omdat het hele kaartenhuis in maanden tijd is opgebouwd rond die ongunstige beslissingen is aanpassing daarna bijna onmogelijk. Het resultaat is een project wat volgens de "meetlat" succesvol is, maar wat niet werkelijk aansluit bij de eindgebruikers.

En ja, natuurlijk kan een Agile team niet in isolatie werken en heb je het grotere integratiedoel nodig b.v. onder leiding van een Enterprise Architect. Deze manier van Agile ontwikkelen is mooi gedemonstreerd door Saab bij de ontwikkeling van hun Grippen gevechtsvliegtuig. Dit vliegtuig is (relatief) goedkoop en zelfs volgens Amerikaanse piloten, beter dan hun eigen Amerikaanse vliegtuigen.

In andere woorden het is bijna onmogelijk om de traditionele manier van werken te vergelijken met een Agile aanpak. Het neerzetten van een grote fabricagehal lijkt mij niet meteen een voorbeeld wat je met Agile aanpakt. Saab laat echter zien dat het ontwikkelen van een vliegtuig op basis van Agile prima gaat, zolang er goed op de integratie en samenwerking gelet wordt en er geen silo's ontstaan.

De Agile aanpak geeft vrijheid om in te spelen op het voortschrijdend inzicht en is daarmee minder voorspelbaar wat de uitkomst betreft. Ik vind het voorbeeld met de koekjes juist heel treffend. Bij de traditionele aanpak worden er marktstudies gedaan en grootse plannen gemaakt waarna er miljoenen in het project gedumpt worden. Bij een Agile aanpak begin je klein, test je de respons van de klanten en pas je de volgende stap in het project daarop aan. Het gevolg kan zijn dat je met Agile iets heel anders gaat produceren dan koekjes. Als je dat ziet als het falen van het koekjes project...

... Dan is een Agile aanpak inderdaad niet succesvol!

Meer over Scrum - Agile