De afgelopen 10 jaar heeft Agile een enorme vlucht genomen, met name onder ICT-ers en meer recentelijk ook daarbuiten in andere (meestal creatieve) sectoren zoals productontwikkeling, innovatie en sommige sectoren van onderzoek. Als je nog niet weet wat Agile is, lees dan eerst de link ter introductie.
Agile (of een van de stromingen daarbinnen zoals XP, Scrum, Chystal clear, e.a.) zou je een van de weinige daadwerkelijke ‘innovaties’ kunnen noemen die plaats heeft gevonden binnen het werkveld van projectmanagement de afgelopen 10 jaar. Het ‘oude’ projectmanagement had zijn wortels in het ingenieursdenken dat op zijn beurt weer wortels had in het scientific management. Scientific management is ontstaan tijdens de grote industrialisatie begin vorige eeuw. De essentie was dat al het werk op te delen was in simpele gespecialiseerde taken waarbij je dan vervolgens ging meten hoe lang elke (deel-)taak duurde waardoor beheersing en planning zoveel beter ging en bovendien de productiviteit toenam. Charlie Chaplin heeft er een prachtige film over gemaakt.
Agile en Scrum is ontstaan in de ‘creatieve industrie’ en biedt een oplossing voor hoe om te gaan met snel en vaak veranderende werkzaamheden, doelen en taken in een project. Het biedt een methode om het creatieve (denk-)werk te organiseren zonder een alwetende autoritaire projectleider (die natuurlijk vaak ook niet weet hoe het moet).
Passen de oude principes goed bij werk dat gedetermineerd is (vast resultaat, vaste manier van werken), Agile en Scrum lijkt goed te werken bij veranderlijk werk (denkwerk!). Vandaar dat je in meer traditionele sectoren als de bouw of ‘oude’ industrie nog meer het ‘oude’ projectmanagement tegenkomt. Bij sectoren waar veel denkwerk plaatsvindt zoals bij programmeurs en productontwikkelaars is Agile (meestal) meer op zijn plaats.
De voordelen van Agile
De aanhangers van agile beloven in hun verbeterde werkwijze onder andere: minder kosten bij het (tussentijds) veranderen van projectdoelen en/of projectresultaten, minder stress en meer werkplezier bij het projectteam (minder overwerken, minder strijd, meer ‘flow’), betere planningen en besluitvorming, het mobiliseren van meer kennis in teams, sneller resultaat door direct te gaan bouwen en te leveren, minder overhead door minder documenteren en andere voordelen ten opzichte van de traditionele projectmanagement aanpak. Het is nogal wat. Maar hoe goed houden de beloftes zich in de praktijk? Na een periode van ruim 10 jaar waarin Agile en met name Scrum hun weg hebben gevonden binnen veel organisaties tijd voor een evaluatie misschien?
De nadelen van Agile
Zonder de pretentie te hebben hier een volledige bespreking van voor- en nadelen van Agile te doen wil ik een probleem van Agile bespreken dat we vaak zijn tegengekomen bij organisaties waar we mee werkten:
Het eerste kenmerk van Agile is het opknippen van het werk in kleine iteraties: timeboxes of ‘sprints’ (scrum benaming). In zo’n timebox van meestal maar een week of 3 moet een deel van het projectresultaat opgeleverd worden, bijvoorbeeld een werkende database of een prototype van een nieuwe robot. Inclusief het testen en de beoordeling door de klant van het geleverde. Het grote voordeel hiervan zou zijn dat je fouten sneller opspoort en dat je makkelijker kan wijzigen. In het traditionele projectmanagement model maak je eerst een (uitgebreid) ontwerp en test je pas aan het einde van het project of dat wat in het design document staat daadwerkelijk gemaakt is (meer uitleg is hier te lezen).
De grafieken van de kosten zoals die te vinden zijn in (bijna alle) boekjes over Agile of Scrum zien er ongeveer zo uit:
Wat je in deze grafiek ziet is dat de kosten van een wijziging in een project toenemen, naarmate de tijd van het project is verstreken. Logisch, als je een huis bouwt en je besluit in de fase van oplevering dat je toch maar een garage onder je nieuwe huis wil, dan kan dat wel maar is dat aanzienlijk duurder dan wanneer je dat vooraf bedacht had.
Doordat Agile met korte iteraties werkt (waarna iedereen weer nadenkt wat de handigste volgende stap is voor verder te gaan) is de schade van een verkeerde keuze kleiner. De grafiek uit de Agile en Scrum boekjes ziet er zo uit:
Er zijn wel kosten bij een verandering, maar omdat alles incrementeel groeit, ‘gooi’ je (in theorie) niet zoveel werk weg. Misschien is slechts 1 sprint (iteratie) verloren gegaan, maar dat is dan alles. Omdat je veel eerder test en levert, worden fouten en verkeerde beslissingen (in theorie) ook eerder opgemerkt.
Alhoewel we bovenstaand beeld wel herkennen (meestal), dat men gemakkelijker (goedkoper) kan wijzigen, komen we ook wel de situatie tegen dat een scrum team niet (genoeg) vooruit heeft gedacht. In een bepaald geval bleek na een iteratie of 7 dat de architectuur die stapsgewijs ontstaan was in het Agile project in zijn geheel niet voldeed bij de gewenste uitbreiding van functionaliteiten.
Saillant detail was bovendien dat die functionaliteiten al bij het begin van het project bekend waren en gecommuniceerd was aan de groep. Deze besloot echter niet te lang na te denken over een toekomstbestendige opbouw van de software en onder het mom van ‘we doen geen design, want we zijn agile’ liep het project helemaal vast na 7 iteraties (6 maanden werk !).
De wijziging die toen nodig was, was net zo kostbaar of misschien nog wel kostbaarder dan een wijziging in de ‘oude stijl’ projectmanagement methodes. De grafiek die ik erbij zou kunnen tekenen en die je niet in agile boekjes tegenkomt zou er zo uitzien:
Bedenkingen bij agile
Het bovenstaande geval is slechts een van meer bedenkingen die we hebben bij Agile/Scrum. Zonder het enthousiasme voor de methodiek te verliezen (we zijn echt wel enthousiast anders geven we geen opleidingen in Agile en Scrum) zijn er best een hoop bedenkingen, bezwaren en vragen, bijvoorbeeld:
- Hoe zit het met opschalen van Agile projecten? Ondanks initiatieven zoalsSAFe, LeSS, Agility Path.DAD en ScrumPLOP om agile te gebruiken voor grotere projecten, blijft het definitieve antwoord hoe dit moet uit. De vele geschaalde Agile methoden lijken nog in een ontwikkelfase en het is (anno 2018) nog in hoge mate experimenteel.
- Hoe zit het met het combineren agile teams met minder ‘agile’ werkers als interface designers, content producers, nazorgers (handleidingen schrijven), marketeers, e.a.?
- Hoe komt het dat bij de Agile teams die we bezoeken, de methode vrijwel altijd maar deels wordt toegepast?
- Als Agile zo’n goede methode is voor teamwerk, hoe komt het dan dat veel Agile teams meer een groep individuen lijken dan echt samenwerkende teams?
- Waarom zo’n grote weerstand tegen vooruit denken of het maken van (deel-) ontwerpen?
- Waarom hoef je geen documentatie te maken bij de te ontwikkelen software?
- Wat doet een Scrum master de hele dag als hij alleen maar zijn Agile team hoeft te coachen en waarom is het een volledige MT functie (volgens de officiële Scrum richtlijnen)?
- Welk argument is er tegen om (delen) van het project toch procesmatig aan te pakken?
Agile = religie
Ik ga nog een keer herhalen dat ik enthousiast ben over agile, anders lijkt het door de kritische toon van dit stuk misschien dat dit niet zo is. Extreme programming, Scrum en Agile in algemene zin zijn ontstaan als antwoord op veel misstanden in met name ICT projecten. Het is ook echt bedacht door programmeurs zelf. Misstanden die elke projectwerker wel kent: een planning moeten forceren “want het moet af voor een bepaalde datum”, projectleiders die geen regel code kunnen schrijven of lezen en waarvan helemaal niet duidelijk is wat hun toegevoegde waarde is aan het project, moeten overwerken om er vervolgens achter te komen dat elders in de keten het project weer maanden stil komt te liggen, klanten die niet weten wat ze willen en/of geen beslissingen (durven) nemen, specificaties die almaar uitbreiden en wijzigen (‘kan je dan ff ook nog….”), te veel projecten tegelijk door elkaar moeten doen (“want het moet allemaal gebeuren”) en tenslotte veelvoorkomend: sales heeft iets verkocht dat de techneuten helemaal niet kunnen maken (of in ieder geval niet binnen de beloofde termijn). Niet voor niets constateerde de automatiseringsgids in een enquête dat 44% van de (IT) projectmedewerkers tekenen had van chronische uitputting.
Verschoven macht
Agile heeft zeker een antwoord op een aantal van de typische projectproblemen, maar het heeft ook een aantal bezwaren (of op zijn minst vraagtekens). Het gesprek daarover of het onderzoek daarnaar binnen organisaties blijkt lastig. De principes van Agile zijn immers prachtig dus wat kan je daarop tegen hebben? Een van de bezwaren zou kunnen zijn Agile ook vrijblijvendheid kan rechtvaardigen. Onder het mom van “we zijn agile” komen we wel medewerkers tegen die dan maar helemaal niet meer plannen, of vastleggen of testen of begroten. Of erger nog: organisaties die agile gaan toepassen op projecten die zich echt niet lenen voor een agile aanpak zoals de marktintroductie van een nieuw product. Want ‘agile is beter’ (hipper, socialer, moderner, innovatiever, leuker, …vul zelf maar in).
Onmiskenbaar is het zo dat door het invoeren van agile teams er meer macht bij de techneuten en programmeurs komt te liggen in vergelijking met traditioneel projectmanagement. In een goed georganiseerd agile team is zelfs geen projectleider meer nodig. Nieuw verkregen macht is moeilijk af te staan en de angst daarvoor maakt een open gesprek over het (dis-)functioneren van de agile methodiek in de praktijk soms lastig.
Klik hier voor meer informatie over onze Agile of Scrum opleidingen.
Auteur: Wouter Baars
