Het Agile Manifesto kritisch bekeken

Wat is het verband tussen de verspreiding van de "agile" ontwikkelingsmethoden en het "Agile Manifesto"? Leestijd: 7'15" + 4'30".

Bewegingen en manifesten

"Agile" is een kenmerk van methoden voor ontwikkeling van (doorgaans) software, maar wordt gepromoot als een methode (vlag-en-ladingprobleem), wat bijgevolg regelmatig aanleiding geeft tot misverstanden en discussies, bv. over het verband tussen Agile en Scrum (een "agile" methode, naast bv. XP, DSDM en FDD). Je kan beter spreken van een "Agile" beweging, die het kenmerk als naam draagt. De grondslagen van een beweging kunnen verduidelijkt worden met een manifest. Doorgaans is dat een effectieve methode om een beweging bekendheid te geven, en dat geldt ook voor "Agile". Als een groep mensen met faam in de software ontwikkeling samen een manifest publiceren, dan kan je verwachten dat dit impact heeft, en zo is het ook gegaan. Maar hoe deugdelijk is het "Agile Manifesto" eigenlijk? Verklaart het werkelijk de opgang van de "Agile" beweging sinds begin deze eeuw?

Het "Manifest voor Agile Software Ontwikkeling" heeft allicht wel een verschil gemaakt in de verspreiding van de "agile" methoden; het feit alleen al dat het bestaat geeft "Agile" een aura van betrouwbaarheid: "hier is over nagedacht". Maar als je het kritisch bekijkt valt er ook veel op aan te merken. Laat ons eens kijken naar de 4 waarden en 12 principen van het "Agile Manifesto".

De "Agile" waarden

Ik krijg altijd argwaan als er geschermd wordt met waarden en normen. "Waarde" is een containerbegrip waar je alle kanten mee uit kan, maar omdat "waarde" iets waardevol is of lijkt krijgt het altijd een positieve connotatie. Dus als iemand iets zegt over waarden, zijn we geneigd daar respect voor te hebben, en er waarde aan te hechten.

Het manifest begint met de beschrijving van enkele waarden, ideeën die als waardevol worden gezien, en bepaalde voorkeuren aangeven: "Wij verkiezen <A> boven <B>". Men zegt er wel bij dat <B> ook waardevol is, om kritiek al op voorhand af te wenden. Maar hoe dan ook, als er conflicten ontstaan tussen <A> en <B> (en die zullen er zijn, zie verder), dan zal <A> de voorkeur krijgen, wat op termijn onvermijdelijk een verwaarlozing impliceert van <B>. Kijken we even naar de zgn. waarden.

1 – "Mensen en hun onderlinge interactie boven processen en hulpmiddelen" – Onderlinge relaties tussen mensen mogen dan interessant en belangrijk zijn (maar jammer genoeg  ook afhankelijk van influencing skills), maar die mensen hebben nog altijd processen en hulpmiddelen nodig om iets te realiseren. Een gebrek aan aandacht voor processen leidt onvermijdelijk tot chaos. Je wil niet weten hoeveel software ontwikkelingsprojecten in chaos verlopen door gebrek aan procesbeheersing, of hoeveel geld dat kost aan de maatschappij.

2 – "Werkende software boven allesomvattende documentatie" – De term "allesomvattend" komt over als sneer aan het adres van wie nog aandacht heeft voor documentatie. Documentatie is en blijft belangrijk, niet alleen voor onderhoudbaarheid van het opgeleverde product, maar evenzeer als leidraad bij de ontwikkeling. Documentatie hoeft ook niet "allesomvattend te zijn" om goed te zijn. Voorrang geven aan werkende software t.o.v. documentatie komt erop neer dat (1) de ontwikkelaars kunnen programmeren zonder zich iets van documentatie aan te trekken (ze hebben genoeg aan de "user story"), en (2) niemand zich nog om documentatie bekommert zodra de software werkt.

3 – "Samenwerking met de klant boven contractonderhandelingen" – Samenwerking is goed; een tekort aan samenwerking heeft al veel ellende veroorzaakt. Samenwerking is nog beter als die gebaseerd is op goede afspraken, maar die kosten doorgaans wat meer moeite. Dus contractonderhandelingen aan de kant schuiven is eerder slecht dan goed voor de samenwerking. Onderliggende boodschap: "we willen liever niet gebonden zijn, wel ons goesting doen".

4 – "Inspelen op verandering boven het volgen van een plan" – Dit zijn twee aspecten die in feite helemaal niet tegenover elkaar staan. Je speelt in op verandering of niet, en je maakt een plan of niet. Als je een plan maakt, en inspeelt op verandering, zal je plan om aanpassing vragen, dat wel. Maar of je nu werkt met of zonder een plan, dat is een keuze die los staat van je bereidheid om in te spelen op verandering. Maar deze "waarde" suggereert iets anders: "wij willen inspelen op verandering, dus werken we beter zonder een plan". Dat is dus een foutieve redenering.

De "Agile" principen

Het manifest wordt begeleid door 12 (toevallig, een mooi getal) principes (klinkt ook deugdelijk), waarvan er echter vijf helemaal niet afhankelijk zijn van de methode (5, 7, 9, 11 en 12), en twee maar gedeeltelijk (3 en 10). Dat die 12 principes er zijn versterkt de methode (of zou dat moeten), maar als je ze dan nader bekijkt kom je in feite bedrogen uit. Zie de sectie "Kritiek" verderop voor details per principe.

Ook de principes die je wel als typisch "agile" kan beschouwen, zijn voor kritiek vatbaar.

Principe 1, "De hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software", lijkt na analyse eerder verkoopspraat dan een belangrijk "agile" principe; het overlapt met principe 3, en het niet-overlappende deel, "het tevredenstellen van de klant" is niet typisch "agile", en is bovendien methode-onafhankelijk.

Principe 2, "Verwelkom veranderende behoeften", is essentieel voor "agile". Dat je moet kunnen inspelen op veranderende behoeften wordt enkel in de "agile" methoden zo duidelijk gesteld. Het is wel te vrezen dat de mogelijkheid om beter met veranderende behoeften om te gaan, de noodzaak om op voorhand beter na te denken (wat nog altijd veel ellende vermijdt) nog verder terugdringt. Maar uiteindelijk mag je een gebrek aan voorafgaande analyse, of de veranderlijkheid van behoeften, niet op het conto van de "agile" methoden schrijven; dat bestaat ook bij andere methoden.

Ook principe 3, "Lever regelmatig werkende software op", behoort tot de kern van "agile", en staat bovendien duidelijk op zichzelf. Essentieel bij dit principe is dat regelmatig, met korte perioden (enkele weken), een afgewerkt product ontstaat, getest en gedocumenteerd (!). Twee kanttekeningen daarbij: (1) regelmatig testen is essentieel, zodat fouten niet de kans krijgen tot een foutsequentie uit te groeien, maar dat kan bij elke methode, en (2) de klant wil zijn probleem opgelost zien, met of zonder software, en dat lijkt Agile navelstarend te negeren.

Principe 4, "business en ontwikkelaars moeten dagelijks samenwerken", past volledig bij principe 2. Als je vooraf niet of slecht analyseert, moet je nauwer samenwerken. Dit werkt echter in twee richtingen. Enerzijds, als er veranderende behoeften zijn, zal de samenwerking ervoor zorgen dat ze snel gedetecteerd worden, en dus ook snel kunnen behandeld worden. Anderzijds kan de samenwerking er ook voor zorgen dat de behoeften sneller veranderen. Globaal gezien lijkt mij dit een nuttig effect van "agile". Bij een behoeftenspecificatie wil je immers niet alle details opnemen (bv. qua user interface), ook al omdat die vaak samenhangen met keuzen die dan nog niet gemaakt zijn. Bovendien is het moeilijk om op voorhand lacunes en neveneffecten te identificeren (bv. qua functionaliteit). Een iteratieve methode is de enige die deze problemen effectief opvangt. Nu zijn iteratieve methoden geen uitvinding van de "Agile" stroming; hun opname in de DOD-STD-2167 dateert van 1985, als reactie op de nadelen van het watervalmodel. De vele reacties op het watervalmodel hebben in elk geval de software literatuur een dienst bewezen. Ook "Agile" heeft al heel wat artikels en boeken (documentatie dus…??) voortgebracht.

Principe 6, "informatie delen door met elkaar te praten", loopt parallel met principe 4. Dagelijks samenwerken doe je immers niet schriftelijk. Essentieel hier zijn de korte communicatielijnen tussen het ontwikkelteam en de "business", in welke vorm dan ook (van klant over analist tot product owner).

Principe 8 doet vragen rijzen over de vertaling. In het Engels: "Agile processes promote sustainable development"; in het Nederlands: "Agile processen bevorderen constante ontwikkeling". Duurzaam is niet hetzelfde als constant. Er is echter geen houvast om hier een keuze te maken. Vermoedelijk is er gedebatteerd over de betekenis van duurzaamheid van ontwikkeling (een discussie die uiteindelijk de hele sector ondergraaft), en heeft men "constant" aangenomen om ervan af te zijn. Het idee van een "duurzame ontwikkeling" zoals in een maatschappelijke context, lijkt mij niet van toepassing op software ontwikkeling. Verder lijkt mij dit een variant van principe 3.

Principe 10 zegt eerst "eenvoud is essentieel" (hoor ik graag), en stelt dan eenvoud gelijk aan de kunst om zo veel mogelijk werk te mijden (OK) of te schrappen (gevaarlijk). De "agile" methoden behouden zich blijkbaar het recht voor om delen van een opdracht te annuleren. Enerzijds is dit lachen met de klant: hij vraagt wel zus en zo, maar wij beslissen dat hij dit en dat niet krijgt. Anderzijds kan je in een agile context ook nauwelijks zonder dit principe. Er staat immers geen beperking op het aantal wijzigingen dat kan behandeld worden; gegarandeerd krijg je dan meer op je bord dan je op kan.

Het lijkt alsof de Agile beweging is opgezet om effectiever te kunnen werken (verdienen dus) in de gevallen waarin de klant op voorhand te weinig heeft nagedacht. Op die manier kunnen klanten die om gelijk welke reden hun vereisten onvoldoende analyseren of specificeren, toch door een software leverancier geholpen (?) of minstens gebonden (!) worden.

Nog meer kritiek

Ik ben niet de enige met bedenkingen bij de "agile" methoden. Kijk eens naar dit artikel: "How well does the Agile Manifesto align with principles that lead to success in product development?". Dit komt van Tom Gilb, die hier uiteraard zijn eigen aanpak promoot (Planguage en Evo), maar zijn commentaar is niet mis. Hier en daar kort door de bocht, maar hij doet duidelijk een poging om de waarden en principes van Agile tot puin te herleiden, en naar ik vrees niet helemaal onterecht. Maar beoordeel dat vooral zelf. Overigens, ook user stories liggen terecht onder vuur bij Gilb… Meer over Gilb en "Agile" vind je in zijn blog.

Meer kritieken op "Agile" vind je hier en hier. En dan heb je nog darkagilemanifesto.org, met een hoogst interessant artikel dat de Agile stroming in zijn context plaatst (eigenlijk veel beter dan mijn eigen blogartikel).

Slag in het water

Agile was in 2001 een begrijpelijke reactie op wat er in de software-industrie allemaal fout liep. De initiatiefnemers zouden het eens anders gaan aanpakken, en het Agile Manifesto moest dat duidelijk maken. Maar een analyse daarvan laat alles behalve een degelijke indruk na. Als houvast voor organisaties die betere softwareproducten willen leveren is het dus niet geslaagd; de "agile" methoden hebben ook nog niet bewezen beter te werken dan andere.

In feite is het bestaan van dit manifest dus geen reclame voor de "agile" methoden; je zou denken dat dit gebrek de methode ondergraaft. En toch wordt er meer en meer "agile" gewerkt, en wordt ervaring met "Agile" meer en meer gevraagd in vacatures (misschien blijven opdrachtgevers hopen eens iemand te vinden die er wél iets van bakt). Wat dan weer betekent dat de agile gemeenschap, en bij uitbreiding dus een deel van de software sector, nog altijd niet begrepen heeft waar het om gaat (zie de tekst van Gilb), nl. problemen oplossen, in plaats van de boel op te blazen met software methoden ten voordele van de sector zelf.

De beweging en het manifest

Het manifest heeft de "Agile" beweging ondersteund, alhoewel het niet deugt; als je het een beetje analyseert kom je daar vanzelf achter. In de veronderstelling dat het manifest de beweging definieert, zit die dus met een groot probleem. De "agile" methoden worden intussen wijd en zijd toegepast, terwijl ze gebaseerd zijn op een slechte definitie.

Vanwaar dan het succes van de methode? Ik denk dat hier verschillende redenen voor zijn:
– de methode belooft, zoals alle andere, om het software probleem op te lossen, en die belofte is nog niet voldoende ontkracht;
– regelmatig wordt ons verteld, door de ICT-sector nota bene (of de politiek, die daar nog groei hoopt te vinden), dat de veranderingen voortdurend sneller gaan, waardoor projecten ook sneller moeten uitgevoerd worden om concurrentieel te blijven, waardoor doeners (liever efficiënt) dan weer het overwicht krijgen over denkers (liever effectief), en in die omstandigheden is een methode voor doeners, zoals "Agile", uiteraard aantrekkelijker;
– heel wat betrokkenen worden verschoond van het schrijven en lezen (!) van specificaties (dat mensen die zoveel code schrijven niet meer willen lezen is een bangelijke gedachte);
– en er zijn er allicht nog; stof voor een ander artikel…

Kritiek

Manifest voor Agile Software Ontwikkeling

Wij laten zien dat er betere (dan ..?) manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt (ja, maar beter?) en door anderen ermee te helpen (kassa,  kassa). Daarom verkiezen we… 

• mensen en hun onderlinge interactie (influencing skills?!) boven processen en hulpmiddelen (waar je nochtans niet zonder kan),
• werkende software boven allesomvattende (overdrijf een beetje) documentatie (anders wel nuttig!),
• samenwerking met de klant (dan kan je die beter opeten) boven contractonderhandelingen  ( bescherming tegen boze wolven),   
• inspelen op verandering (met de wind mee) boven het volgen van een plan (voor wie dat nog kan en wil maken).

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld (zal wel…), hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd (en verwaarlozen wij gemakkelijkheidshalve de rest).

Principes achter het Agile Manifest

1 – Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.

(a) Of het tevredenstellen van de klant de hoogste prioriteit is, hangt van de organisatie af (of van bepaalde individuen daarin), en niet van de gebruikte methode.
(b) Vroegtijdig en voortdurend opleveren is niet gevraagd, en zelfs storend. "Vroegtijdig" kan nog positief gezien worden als "eerder dan verwacht", maar "voortdurend" is niet realistisch. Een klant zal nieuwe software niet in stukjes installeren, dus moet die ook niet in stukjes opgeleverd worden. Dat de ontwikkeling in stukjes zinvol kan zijn, is iets anders (zie ook principe 3). En die "waardevolle software" refereert wel degelijk aan de grote hoeveelheid "waardeloze" software die al is opgeleverd (al mag dat niet zwart/wit gesteld worden).
(c) Volgend uit (a) en (b): dat de klant wordt tevredengesteld door vroegtijdige en voortdurende oplevering is dan ook ten zeerste te betwijfelen.

2 – Verwelkom veranderende behoeftes, zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant.

Dit lijkt nogal hard op reageren op elke prikkel. Past mogelijk wel in de ADHD tijdgeest, maar levert geen stabiel proces op, en dus ook geen stabiele kwaliteit in het product. Veranderende behoeftes kunnen trouwens vermeden worden door (1) niet altijd de laatste stroming te willen volgen, en (2) op voorhand wat beter na te denken.

3 – Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden.

Dit gaat over de periode van de sprint, in de praktijk meestal twee of drie weken. Oplevering aan de klant is niet nuttig; zie ook punt 1. Het "regelmatig" aspect is wel belangrijk. "Werkende" software betekent per definitie dat er functionaliteit werd toegevoegd, en eventuele bugs zijn opgelost. Om foutsequenties (zeer gevaarlijk bij softwareontwikkeling) te vermijden moet er regelmatig (bv. elke sprint) getest en gedebugd worden. Dit is een zeer nuttig principe, maar het is niet beperkt tot de "agile" methoden. Ook in andere methoden (inclusief de "waterval"!) kan iteratief gewerkt worden, met foutloos werkende tussentijdse versies.

4 – Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.

Dit is dubbel. Enerzijds lijkt dit een deugdelijk principe. In het verleden zijn veel software projecten spaak gelopen door een gebrekkige communicatie tussen opdrachtgever en uitvoerder, waaronder slechte specificaties en misverstanden over wijzigingen. Dat kan je oplossen door meer directe communicatie, maar ook door betere specificaties (!). Anderzijds is meer directe communicatie tussen klant en leverancier in de praktijk meestal niet mogelijk, omdat de klant daarvoor niemand constant beschikbaar heeft. In die gevallen wordt intern bij de leverancier een "product owner" aangeduid, maar dat is minder effectief. In bedrijven die hun software zelf maken voor een bepaalde markt (bv. HR, accounting, supply chain…) is de "product owner" doorgaans één van de eigen consultants, wat beter kan werken. Maar de aanduiding van één "product owner" houdt meteen ook het gevaar in dat diens inbreng persoonlijk wordt, en/of wordt beïnvloed door het ontwikkelteam, een gevaar dat zich niet stelt als de ontwikkeling gebeurt op basis van een vooraf bepaalde specificatie (of dan ook volgens de specifiatie wordt ontwikkeld is een andere kwestie).

5 – Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.

Beetje vreemd principe. Moet je dit interpreteren als "zet de beste mensen in voor agile projecten (en de rest elders)"? Da's natuurlijk wel een truc om het "agile" principe te promoten… De leverancier moet het echter doen met de beschikbare ontwikkelaars. Het zal duidelijk zijn dat een team met gemotiveerde individuen een grotere kans maakt om goede kwaliteit af te leveren, maar dat geldt dus voor elke methode, Scrum of niet, "agile"of niet. Maat voor niets.

6 – De meest efficiënte en effectieve manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.

Weet ik niet hoor. Men gaat er hier van uit dat mondelinge communicatie minder ruimte laat voor interpretaties, en dat is niet mijn ervaring. Je denkt beter na als je schrijft; dat was altijd zo, en dat zal zo blijven. De spreker brengt zijn boodschap mogelijk minder correct over dan de schrijver, en de toehoorder vult onduidelijkheden gemakkelijker aan met eigen interpretaties. Binnen een ontwikkelteam is mondelinge communicatie de meest logische en de snelste vorm van communicatie. Het gevaar op misverstanden wordt echter groter naarmate de andere partij verder weg staat, zoals de product owner en de klant. Dit is ook afhankelijk van het onderwerp; technische punten, die binnen het team blijven, kunnen doorgaans goed opgelost worden via mondelinge communicatie binnen het team. Maar hoe minder nabij het probleem, of hoe minder direct de communicatie, hoe groter het voordeel van het geschreven woord. Voor wie nog kan en wil schrijven…

7 – Werkende software is de belangrijkste maat voor voortgang.

Klopt, op voorwaarde dat die werkende software ook waarde betekent voor de klant. Testen op verschillende niveaus maakt hier het verschil. Ook zonder opleveren. En in elke methode.

8 – Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.

Het minst duidelijke principe tot hiertoe. (1) Of er constant ontwikkeld wordt of niet hangt niet van de methode af. (2) Constant betekent niet dat er voortdurend geprogrammeerd wordt, wel dat er met vaste tussentijden een werkend product wordt afgeleverd. Dat kan ook met andere methode dan Scrum, en met niet-agile projecten. (3) Een tempo aannemen dat eeuwig kan worden volgehouden is allicht gezond, maar het is ook een luxe die de meeste organisaties zich niet denken te kunnen veroorloven. Als het niet dringt zijn we blijkbaar niet goed bezig…

9 – Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.

Nog een onduidelijk principe, alsof ze aan 10 of 12 willen geraken. Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken gelijk welke methode.

10 – Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.

Waar slaat dit op? Dit kan je langs twee kanten bekijken: (1) niet méér doen dan gevraagd wordt, en (2) zo veel mogelijk schrappen van wat gevraagd wordt.
(1) Het grootste deel van investeringen in software gaat naar ontwikkelmethoden en -tools. Maar dit geldt voor elke methode, dus moet dat onderwerp hier niet behandeld worden.
(2) In Agile / Scrum projecten wordt niet getwijfeld om gevraagde functionaliteit te schrappen als ze binnen de voorziene tijd niet kan ontwikkeld worden. Uiteraard wordt er naar prioriteit gekeken, maar in geen enkele andere methode is deze techniek zo duidelijk opgenomen.

11 – De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.

Dit heeft dus niets met de methode te maken; dit geldt evengoed zonder Agile of Scrum. En of het klopt durf ik te betwijfelden, maar dat is hier geen onderwerp.

12 – Op vaste tijden onderzoekt het team hoe het effectiever kan worden en past het vervolgens zijn gedrag aan.

"Effectiever" zie ik natuurlijk graag. Voor het overige is ook dít weer onafhankelijk van de methode.