Fred Heemstra, Luuk Ketel & Erik van Daalen – Agile: geschikt – ongeschikt

agile geschikt ongeschiktOp de Projectmanagement Parade 2016 kreeg ik als één van de 200 deelnemers die zich als eerste hadden ingeschreven, gratis een hard copy van het boekje Agile: geschikt – ongeschikt, dat KWD Resultaatmanagement in de KWD reeks in 2015 uitgaf. Fred Heemstra, Luuk Ketel en Erik van Daalen bundelden de krachten om hun kijk als projectmanagement practitioners op Agile te verwoorden, gebruikmakend van literatuurstudie, best practices en interviews. Agile is hot, wordt vaak als noodzakelijk in de 21e eeuwse projecten gepropageerd en afgezet tegen ‘ouderwets’, ‘waterval’ en andere uitingen van een veronderstelde gemeenschappelijke vijand van IT’ers en projectmanagers. Toch trappen de auteurs zelf ook na en daarmee in diverse valkuilen rondom de concepten en raamwerken. Het 88 pagina’s tellende boekje heb ik volgepend met kanttekeningen en kritische opmerkingen.

Eerst het gebrek aan definitie van Agile. ‘De methode’ wordt in dit boek niet beschreven, maar ik ken ook zelf ‘de methode Agile’ niet. Welke methode de auteurs als referentie gebruiken, is niet helder. Er is wel een ProductOwner, maar ook een Agilemanager. De auteurs nemen het Agile Manifesto uit 2001 als ontstaansmoment van Agile, maar dat is geschiedvervalsing. Bij het overnemen van het Agile Manifesto is niet de tekst boven en onder de vier statements meegenomen. Een tabel op p.16-18 toont ‘overeenkomstige termen uit de Agile en de traditionele wereld’ (in de tekst aangeduid als ‘old-fashioned-world’), maar continuous delivery <> releases, backlog <> scope, sprint <> fase of release, user stories <> specificaties en story points <> functiepunten, product owner <> senior user en burndown chart <> estimate to complete. Het is toch geen oude wijn in nieuwe zakken?

Alles is na aanraking van de auteurs agile: Agilegebruik, Agile-survey, Agile-aanpak, Agile-experts, Agileready, Agilegebruikers, Agileprojecten, Agileprocess, Agilereadyscore, enzovoorts. Deze nepwoorden ogen, net als ProductOwner in plaats van Product Owner en veel spel- en stijlfouten, uitdrukkingen als ‘krijgt handjes en voetjes’, het vaak gebruiken van ‘dus’ en ‘immers’ slordig. Op diverse pagina’s zijn paragrafen tekst dubbel afgedrukt (p.9-10, p.71-72). Goede (eind)redactie had een nettere tekst opgeleverd.

Hoezo moet de opdrachtgever op alle fronten een draai maken van 180 graden (p.20)? Op p.20 duikt opeens een Scrum master op, die in de rest van het boek niet echt een rol lijkt te hebben, ook niet in de lijsten met rollen op p.43. Traditioneel = waterval = fout, dat is de opvatting van de auteurs. Een project heeft één team en ontwikkelt software, heeft een opdrachtgever en een project of agile manager zonder Scrum master, lijkt de andere rode draad in het boekje. Zoek in dit boekje geen antwoorden op vragen over opschalen, distributed of dispersed teams, alternatieven voor Scrum, de diverse Agile frameworks of bruibaarheid buiten software-ontwikkeling.

En wat moet ik met zinnen als “Het uiteindelijke doel van werken volgens Agile is om een opdracht met succes af te ronden.” of “Echter, de vaardigheden van een Project Manager zijn wel nodig en een Scrum master behoort die in zich te hebben.” of de tip “Bij Agile hoef je niet te doen aan risico beheersing; het is risico beheersing”, “Agile vraagt om een cultuurverandering binnen een organisatie. Als je dat niet voor elkaar krijgt, begin er dan niet aan” en “Een organisatie die met Agile aan de slag wilt, moet zorgen voor meer dan voldoende budget ten behoeve van training en opleiding”? Ook bijzonder zijn zinnen als “Agile toepassen in een organisatie die sterk procesgeoriënteerd is en die samenwerking niet in z’n genen heeft zitten, is gedoemd te mislukken” of “Het gemiddelde Agile project bestaat uit maximaal slechts 10 mensen.” En wat denk je van: “Je moet als Agilemanager absoluut niet directief zijn en geen controle-freak zij zoals sommige traditionele projectmanager. Als je dit niet in je hebt, dan zal je als Agilemanager slapeloze nachten hebben.”?

Dat de 2011 editie van het CHAOS rapport van de Standish Group – het mantra van de 70% falende projecten kennen we inmiddels wel – beweert, dat “The Agileprocess is the universal remedy for software development project failure.” zonder direct weerlegd te worden, zegt veel over de Standish Group, de onderbouwing van een dergelijk rapport en het eigen leven, dat dergelijke beweringen gaan leiden. Met een zwart-wit checklist van kritieke succesfactoren voor succesvol Agile gebruik op organisatieniveau zou met de stelling, dat ‘projectsucces en succesvoorwaarden liggen in elkaars verlengde’, weinig tot geen enkele organisatie succesvolle Agile projecten kunnen afleveren. Niet scherp gestelde faalcriteria als ‘de organisatie cultuur is te politiek’ of ‘de organisatie is te groot’ roepen vragen op. En is ‘projectteams werken op een en dezelfde locatie’ tegenwoordig niet eerder een ideaalbeeld, dan gangbare praktijk? Wat zeg je daarmee over grote IT-bedrijven als Capgemini, Microsoft, Oracle, IBM, Atos, Accenture? En wat moet management bij ABN AMRO Bank, NN Group, Achmea of ING Bank hiermee?

Projectmanagement methoden en raamwerken, en aanpakken voor softwareontwikkeling worden vreemd vermengd. En als Rapid application development tot de lineaire ProjectManagementLifeCycle modellen wordt gerekend, DSDM Dynamic-SystemsDevelopmentModel genoemd, bepleit ik voor het herlezen van de literatuur en oude trainingsmaterialen. Het al dan niet hebben van feedback loops wordt verkeerd uitgelegd. En ik kan beweringen als dat de beheersing bij agile ‘mens gericht is’ en kennismanagement ‘stilzwijgend’, de organisatievorm ‘organisch’, de communicatie alleen ‘informeel’, de rol van de opdrachtgever ‘kritisch’ en de werkcultuur ‘minder stress en meer werkplezier (minder overwerken, minder strijd, meer ‘flow’) is, niet met droge ogen verdedigen. Zijn in ‘de traditionele aanpak’ (wat die ook zijn mag) mensen echt uitwisselbaar? En wordt de project cyclus bepaald door ‘taken en activiteiten’? En wordt ‘de implementatievolgorde bepaald door urgentie en impact en de status waarin het project verkeerd.’?

Zonder in deze bespreking op alle slakken zout te willen leggen – de auteurs mogen mijn boekje vol aantekeningen hebben als een volgende druk of herziene uitgave wordt overwogen – de beschreven combinatie PRINCE2 en Agile als illustratie: “Vergeet alle bestaande governanceregels die je geleerd hebt. Bij Agile is dit compleet anders. Zo past het toepassen van PRINCE2 in een Agile-omgeving ook maar ten dele. Bij complexe projecten kunnen wel elementen van PRINCE2 toegepast worden. (…) Voorbeelden die vanuit PRINCE2 bruikbaar zijn: de techniek product based plannen om de afhankelijkheden tussen (deel)projecten te besturen en het principe van toleranties. Toleranties bij Agile kan je op het aantal iteraties, teambezetting zetten en op welke minimale wensen die afgemaakt moeten worden met een specifieke Business Value.” Beste mannen, lees de PRINCE2 en PRINCE2 Agile manuals na. Voor zicht op hoe eind jaren ’80 bekende methoden en technieken voor ontwikkeling van informatiesystemen zich tot elkaar verhouden, heb ik anders SDM Information Systems Methodologies (Olle, 1988), System Development Methodology (Uijttenbroek, 1991) en Inleiding technieken informatiesystemen (Pottjegort, 1992) in de kast staan.