Wat is een Agile Methodologie?

Terwijl ik de vraag 'wat is een agile methodologie?' beantwoord, zal ik proberen enkele taalkundige uitdagingen te verduidelijken die vaak in de weg staan. Bijvoorbeeld, is er verschil tussen Agile (met een hoofdletter A) en agile (met een kleine letter a)?  En wat bedoelen we met methode, framework of methodologie en maakt het uit?

De meningen hierover verschillen, dus ik zal het concept van wendbaarheid gebruiken om te helpen met de antwoorden omdat het een woord is dat boven dit alles staat zonder controversieel te zijn.

Wendbaarheid wordt gedefinieerd als het vermogen om snel en gemakkelijk te denken en te handelen. In de context van het plannen en uitvoeren van werk, omarmt wendbaarheid het concept van voortdurende verandering. Het is bijzonder waardevol in een omgeving waar een zekere mate van volatiliteit, onzekerheid, complexiteit of ambiguïteit het moeilijk maakt om rigide gedetailleerde plannen te formuleren en uit te voeren.

Sommige mensen zien 'Agile' als het definiëren van een manier van werken, terwijl anderen het zien als het beschrijven van een manier van denken of gedragen. Sommigen proberen zelfs hoofdletters te gebruiken bij Agile versus agile om onderscheid te maken tussen deze. Dit alleen al kan urenlange, soms vermakelijke, maar vaker frustrerende debatten voeden over wat belangrijker of waardevoller is – Agile doen of wendbaar zijn?

Persoonlijk zou ik me liever richten op de gemeenschappelijke basis – erkennend dat denken en doen nauw verbonden zijn. Sterker nog, gezien de eerdere definitie van wendbaarheid, vooral het aspect gerelateerd aan responsiviteit, zou het niet eens mogelijk moeten zijn om 'Agile te doen' zonder te denken. Ook heeft wendbaarheid in denken, zonder daaropvolgende actie, geen tastbare waarde, behalve misschien leren door observatie. Dus elke werkelijk wendbare manier van werken moet zowel menselijke als procesperspectieven combineren om effectief te zijn.

Voordat ik mijn mening hierover deel, is het goed om te zeggen dat de woorden methode, framework en benadering vaak door elkaar gebruikt worden met methodologie.

Framework wordt het vaakst gebruikt in een merkgebonden context waarbij bijvoorbeeld Scrum, AgilePM en SAFe zichzelf allemaal omschrijven als frameworks. De andere termen worden vaker gebruikt wanneer er in meer algemene bewoordingen over wendbaarheid wordt gesproken.

De beste van de agile frameworks beschrijven specifieke combinaties van waarden, principes, processen, praktijken, rollen, verantwoordelijkheden en ondersteunende werkproducten of artefacten. Waarden, principes, rollen en verantwoordelijkheden hebben betrekking op de menselijke aspecten van wendbaarheid, terwijl processen, praktijken en werkproducten de structuur en mechanismen voor oplevering bieden.

Enkele van de meest populaire agile frameworks zijn:

Scrum is een agile framework dat primair wordt gebruikt bij het creëren van producten. Het heeft zijn oorsprong in de softwareontwikkeling en dat is waar het nog steeds het meest wordt gebruikt. In tegenstelling tot wat vaak wordt gedacht is het GEEN projectmanagementmethodologie omdat het geen aspecten van projectmanagement behandelt. Het richt zich uitsluitend op productoplevering waar het werkelijk uitblinkt.

Scrum bestaat uit een set van 5 waarden (Commitment, Focus, Openheid, Respect en Moed) die sterk gericht zijn op de menselijke aspecten van wendbaarheid. Ze beschrijven een set van ideale gedragingen die iedereen in een Scrum-team zou moeten proberen uit te voeren en bij elkaar te ondersteunen. Scrum definieert ook drie rollen binnen het framework:

• Eén Product Owner verantwoordelijk voor het identificeren en prioriteren van werk om optimale waarde vroeg en vaak op te leveren;
• Meerdere Developers die zichzelf organiseren om waardevolle Incrementen van het product op te leveren; en
• Eén Scrum Master die het hele team helpt het maximale uit de agile manier van werken te halen die Scrum beschrijft.

Productlevering wordt georganiseerd in een eenvoudige herhalende cyclus van ontwikkeling die bekend staat als een Sprint. Sprints zijn doorgaans kort – één maand of minder in duur. Elke cyclus begint met events (korte, gerichte bijeenkomsten) om het werk af te stemmen en te plannen. Het eindigt met events om te beoordelen wat er is opgeleverd en om te onderzoeken hoe zowel het product als de manier van werken kunnen worden verbeterd. Elke dag is er een 15 minuten durende Daily Scrum meeting die door de Developers wordt gebruikt om de focus te behouden op het leveren aan hun afgesproken Sprint Goal en de details van hun plannen dienovereenkomstig aan te passen.

Scrum benadrukt empirisme in de beheersing van zijn processen - een andere belangrijke menselijke onderbouwing van echte agile methodologie. Naarmate de ontwikkeling vordert, wordt van het team verwacht dat zij de transparantie benutten die wordt geboden door Scrum events en artefacten. Gebaseerd op inspectie hiervan, zouden zij voortdurend moeten aanpassen wat zij doen om de levering van waarde te optimaliseren. Transparantie, inspectie en aanpassing zijn de drie pijlers van empirische procesbeheersing.

Sommige mensen beschouwen Kanban als een lean benadering van ontwikkeling in plaats van een agile benadering. Hoewel er mogelijk technische verdienste zit in dat argument, is het voor de meeste doeleinden irrelevant. Net als Scrum beschrijft Kanban een manier van werken die gericht is op het vroeg en vaak leveren van waarde, samenwerking tussen teamleden aanmoedigt en hen de bevoegdheid geeft om de details van hun werk te beheren.

Een belangrijk verschil tussen Scrum en Kanban is dat het Kanban-proces er een is van continue doorstroom van werk in plaats van herhaalde cycli. Teamleden pakken een werkitem uit een backlog zodra ze het vorige item hebben afgerond. In tegenstelling tot Scrum, dat de voorkeur geeft aan teamleden die cross-functioneel zijn (multi-skilled), zijn overdrachten van de ene persoon naar de andere in Kanban gebruikelijker. Het aantal Work in Progress (WiP) items wordt bewust beperkt, wat teamleden aanmoedigt om samen te werken aan het oplossen van problemen wanneer de WiP-limiet wordt bereikt.

De menselijke gedragsaspecten van Kanban worden geleid door zes kernpraktijken: Visualiseer het werk; Beperk Work in Progress; Beheer de doorstroom; Maak beleid expliciet; Implementeer feedback loops; Verbeter collaboratief; en Evolueer experimenteel.

Net als in Scrum wordt een geordende backlog bijgehouden om het werk van de ontwikkelaars te begeleiden en vorm te geven. In tegenstelling tot Scrum zijn planning, reviews en retrospectives niet gekoppeld aan ontwikkelingscycli. Analogen hiervan bestaan echter wel in Kanban en worden doorgaans georganiseerd volgens een vooraf afgesproken cadans en bevatten een Daily Stand-up. De onderstaande tabel beschrijft de Scrum events en hun Kanban analogen.

SAFe – het Scaled Agile Framework – is iets anders omdat het, zoals de naam al suggereert, een veel breder plaatje adresseert. Het is specifiek ontworpen om agile praktijken op te schalen binnen grote ondernemingen.

Terwijl Scrum en Kanban goed geschikt zijn voor individuele teams, biedt SAFe een structuur om meerdere agile teams te coördineren, vaak over afdelingen en waardestromen heen, bij het leveren van complexe producten en oplossingen.

SAFe bouwt voort op fundamentele agile en lean principes – puttend uit frameworks zoals Scrum, Kanban en Lean Product Development – en integreert deze in een gestructureerde hiërarchie. Het adresseert niet alleen levering op teamniveau, maar ook strategische afstemming, governance, budgettering en samenwerking tussen teams.

Belangrijke rollen in SAFe zijn onder andere:

• Agile Teams (die Scrum of Kanban volgen),
• Product Owner en Scrum Master (op teamniveau),
• Release Train Engineer (RTE) – een agile-georiënteerde leider voor een Agile Release Train (ART),
• Product Management en System Architect/Engineer – coördineren van prioriteiten en architectuur tussen teams,
• Lean Portfolio Management – afstemmen van investeringen op strategie.

Werk wordt gepland en geleverd in Program Increments (PI's) – doorgaans 8–12 weken lang – en gestructureerd rond regelmatige cadans-gebaseerde evenementen:

• PI Planning – een grootschalige, face-to-face planningssessie die alle teams afstemt op doelen en afhankelijkheden,
• System Demo's – die geïntegreerde voortgang tussen teams tonen,
• Inspect & Adapt – een gestructureerde retrospective voor continue verbetering.

SAFe stimuleert Lean-Agile leiderschap, een cultuur van continu leren en klantgericht denken. Hoewel meer prescriptief dan Scrum of Kanban, biedt SAFe een raamwerk voor opschaling, waardoor organisaties hun wendbaarheid kunnen behouden terwijl zij complexiteit en afstemming op ondernemingsniveau managen.

AgilePM verschilt ook een beetje doordat het zich richt op een project- in plaats van een productcontext, waarbij het alle klassieke aspecten van projectmanagement behandelt maar op een fundamenteel agile manier. Het brengt alle voordelen van behendigheid in balans met de strengheid van meer traditionele projectmanagementdisciplines.

Het is bijzonder geschikt voor organisaties zoals in de overheid, financiële dienstverlening, of andere gereguleerde sectoren die stakeholder-zekerheid, gedefinieerde rollen en verantwoordelijkheden, en een gecontroleerde leveringsomgeving vereisen.

AgilePM bevat elementen van opschaling naar meerdere zelforganiserende teams en richt zich op het leveren van waarde. In tegenstelling tot de meeste agile benaderingen richt het zich echter op uitkomsten in plaats van outputs en omvat het al het werk dat nodig is om waarde te realiseren in plaats van alleen iets te leveren dat waardevol zou moeten zijn.

Zoals elk goed agile raamwerk bevat het zowel menselijke als procesonderdelen, allemaal geïdentificeerd in onderstaand diagram.

Nu we enkele van de belangrijkste agile frameworks hebben samengevat, is het een goed moment om terug te keren naar de term methodologie.

Voor velen is methodologie simpelweg een ander woord voor framework, maar ik kijk liever wat dieper naar de toegevoegde waarde die dit woord zou kunnen hebben. Veel bronnen definiëren methodologie als "de studie, analyse of toepassing van methoden". Een agile methodologie zou dus in deze context iets anders geïnterpreteerd kunnen worden dan een framework, namelijk inclusief een werkelijk begrip van wat een bepaald framework laat werken, en waarom.

Recent lijken sommige organisaties teleurgesteld te zijn geraakt in 'agile', waarbij ze zich vaak afkeren van aanzienlijke investeringen die er niet in zijn geslaagd de gemaakte beloftes waar te maken. Waarom is dat? Komt het omdat agile frameworks niet werken? Komt het omdat er te veel werd beloofd? Of komt het door een gebrek aan aandacht voor methodologie?

Ik ben betrokken geweest bij wendbaarheid sinds de opkomst ervan in het midden van de jaren negentig, door het implementeren, aanpassen en zelfs creëren van agile frameworks. Na het ervaren, en soms leiden van de goede, slechte en lelijke kanten van initiatieven om prestaties te verbeteren door middel van wendbaarheid, denk ik dat de laatste van deze het dichtst bij de waarheid komt.

Zoals ik eerder al zei, moet er aandacht worden besteed aan zowel de menselijke als de procesmatige dimensies van elk agile framework.  Het procesgedeelte is makkelijk... Werk in korte periodes vanuit een geprioriteerde backlog van werk, houd frequente productbeoordelingen tijdens de ontwikkeling, houd dagelijks 15 minuten durende 'stand-up' teamvergaderingen, etc.

Het menselijke gedeelte is veel ingewikkelder. Een werkelijk begrip van de persoonlijke en interpersoonlijke aspecten van de agile manier van werken is nodig als het potentieel van elk framework gerealiseerd moet worden. Deze omvatten:

Alle agile benaderingen benadrukken zelforganisatie (of zelfmanagement) op teamniveau. De veronderstelling hierachter is dat degenen die het dichtst bij het werk staan het best gekwalificeerd zouden moeten zijn om te beslissen wat de beste manier is om het te doen. Voeg daarbij de noodzaak om snel te reageren op relatief kleine veranderingen in de werkomgeving en zelforganisatie wordt essentieel voor de agile manier van werken.  De twee dimensies hiervan zijn empowerment en eigenaarschap.

Empowerment heeft betrekking op de mate van autonomie en zelfbeschikking die teams en individuen binnen teams hebben. Het moet autoriteit rond wat te doen, wanneer en hoe, om een overeengekomen doel te bereiken, in balans brengen met de competentie om dat effectief te doen. 

Dit wordt gecompenseerd door eigenaarschap. Individuen en teams die de bevoegdheid hebben om op deze manier eigenaarschap van hun werk te nemen, tonen betere prestaties en productiviteit, en verhoogde werktevredenheid vergeleken met degenen wiens werk wordt gecontroleerd door anderen.

Een goede agile leider (traditioneel, een manager) zal daarom werken om optimale empowerment van hun teams te waarborgen.

Onder de eigenschappen van mensen die ons onderscheiden van de meeste andere diersoorten is ons vermogen om samen te werken bij het oplossen van problemen. Samenwerking wordt gevoed door onze geavanceerde vaardigheden in communicatie – voornamelijk ons vermogen om gedachten en ideeën te delen door middel van taal. Alle agile benaderingen hebben collaboratief werken als kern en vertrouwen op transparantie ondersteund door duidelijke, open, eerlijke communicatie over alle aspecten van het werk dat wordt ondernomen. Dit is een essentiële vereiste binnen een agile team en zou ook de standaard moeten zijn voor externe communicatie.

Dit is waar methodologie echt van pas komt… Een van de hoofdoorzaken van het falen van agile transformatie-initiatieven komt voort uit een gebrek aan intelligente, pragmatische toepassing. Dit verwijst terug naar de cruciale menselijke basis van wendbare werken. Als je Scrum, AgilePM of een ander agile framework puur behandelt als een set processen die gevolgd moeten worden, zul je er waarschijnlijk niet veel waarde uit halen.

Volledig succes met elk agile framework vereist empirisme. Dat wil zeggen, het vereist doorlopende transparantie en voortdurende inspectie en aanpassing:

• Transparantie van zowel de benadering die wordt gevolgd als de voortgang die wordt geboekt richting de gewenste doelstellingen is essentieel. Dit is noodzakelijk om... mogelijk te maken
• Inspectie van beide. Specifiek analyseren of iedereen die betrokken is de manier van werken begrijpt en het gekozen framework correct toepast en of de outputs en uitkomsten zijn zoals verwacht. Dit is noodzakelijk om effectieve... mogelijk te maken
• Aanpassing. Dit kan ook betrekking hebben op aanpassing in mensen of processen.
  • Mensen die nieuw zijn in een agile manier van werken zullen het waarschijnlijk behoorlijk anders vinden dan de manier waarop ze eerder hebben gewerkt. Zowel teamleden ALS de belanghebbenden buiten het team zullen waarschijnlijk aanpassingen moeten maken aan de manier waarop ze werken.
  • De standaard processen en praktijken in het framework moeten mogelijk worden aangepast voor optimale resultaten. Elke aanpassing die het team in staat stelt om efficiënter en effectiever te zijn in het bereiken van zakelijke einddoelen zou overwogen moeten worden. Met wendbaar werken zou er geen angst moeten zijn voor experimenteren in dit opzicht.

AgilePM is het eerste, en waarschijnlijk het beste framework voor Agile Project Management. Het beschrijft agile projectmanagement als een flexibele en iteratieve benadering voor het managen van projecten. Het is ontworpen om de uitdagingen van moderne, dynamische omgevingen aan te pakken. AgilePM richt zich op het vroeg en voortdurend leveren van bedrijfswaarde terwijl het verandering en onzekerheid gedurende de hele levenscyclus van het project omarmt. In tegenstelling tot traditionele methoden die zwaar leunen op gedetailleerde voorafgaande planning en uitgaan van een stabiele omgeving, is AgilePM gebouwd om te floreren in omstandigheden van volatiliteit, onzekerheid, complexiteit en dubbelzinnigheid (VUCA).

In agile projecten worden mensen, samenwerking en werkende oplossingen benadrukt boven rigide processen en documentatie. AgilePM integreert de waarden van het Agile Manifesto – waaraan alle echt agile benaderingen voldoen – in een bredere projectcontext, waarbij het zich uitbreidt voorbij softwareontwikkeling om toe te passen op diverse bedrijfsprojecten.

AgilePM benadrukt iteratieve ontwikkeling van de bedrijfsoplossing, timeboxing van werk, en frequente stakeholder betrokkenheid om ervoor te zorgen dat oplossingen evolueren als reactie op echte feedback in plaats van vaste vereisten die vroeg zijn gedefinieerd. Maar AgilePM gaat verder dan dat. Het is niet beperkt tot het overzien van productontwikkeling maar omvat ook het waarborgen van waarderealisatie door het afstemmen van middelen, het managen van risico's, en het handhaven van governance. Het framework ondersteunt just-in-time planning en besluitvorming, waarbij flexibiliteit en aanpassingsvermogen worden aangemoedigd terwijl er nog steeds robuuste controles en verantwoording worden geboden.

Over het geheel genomen is Agile Project Management, geëxemplificeerd door AgilePM, een gedisciplineerde maar aanpasbare benadering van projecten die behendigheid balanceert met governance. Het is vooral effectief voor projecten waar verandering wordt verwacht, en klantwaarde een centrale focus is. Het helpt bedrijfsbehendigheid mogelijk te maken door organisaties in staat te stellen snel en verantwoordelijk te reageren op veranderende behoeften zonder kwaliteit of strategische richting in gevaar te brengen.

Bedrijfsbehendigheid is het vermogen van een organisatie om zich snel aan te passen aan markt- en omgevingsveranderingen op productieve en kosteneffectieve manieren. Het benadrukt responsiviteit, innovatie en klantgerichtheid, waardoor organisaties kunnen floreren te midden van onzekerheid en verandering.

Historisch gezien put het concept uit denkers zoals Alvin Toffler en Peter Drucker, die de noodzaak van aanpassingsvermogen en innovatie benadrukte in het licht van snelle veranderingen. De term "bedrijfsbehendigheid" werd prominent in de vroege jaren 2000, beïnvloed door de Agile Software Development beweging, en is sindsdien geëvolueerd om bredere organisatiepraktijken te omvatten.

Belangrijke aspecten van bedrijfsbehendigheid zijn:

• Klantfocus: Behendige organisaties geven prioriteit aan het efficiënt leveren van waarde aan klanten, waarbij ze continue feedback gebruiken om de klantervaring te verbeteren.
• Flexibiliteit en Aanpassingsvermogen: Dergelijke organisaties kunnen processen en structuren snel aanpassen als reactie op zowel kleine variaties als significante veranderingen, waarbij ze vertrouwen op gemachtigde medewerkers om geïnformeerde beslissingen te nemen.
• Operationele Efficiëntie: Door processen te stroomlijnen en verspilling te verminderen, bereiken behendige bedrijven efficiëntie, vaak door teams te machtigen om eigenaarschap te nemen van hun werkstromen.

Bedrijfsbehendigheid is geen one-size-fits-all benadering; het varieert tussen organisaties en zelfs binnen verschillende gebieden van dezelfde organisatie. Het is een continue reis, waarbij een cultuur nodig is die voortdurend leren en aanpassen ondersteunt. Het implementeren van behendige frameworks zoals Scrum, kan een startpunt zijn, maar echte behendigheid houdt een mentaliteitsverandering in door de hele organisatie.

Uiteindelijk biedt bedrijfsbehendigheid een concurrentievoordeel door organisaties in staat te stellen snel te reageren op marktvraag, continu te innoveren en duurzame waarde aan klanten te leveren.

Veel mensen gebruiken de termen agile methodologie, agile methode en agile framework door elkaar. Dat is prima – zo gaat dat nu eenmaal. Dat gezegd hebbende, geloof ik dat methodologie een diepere duik suggereert in het waarom en hoe methodes en frameworks werken.

Velen zullen bescheiden verbeteringen in prestaties behalen door een relatief 'onnadenkende' implementatie van een agile framework zoals Scrum of AgilePM 'uit de doos'. Voor velen zal dat voldoende beloning zijn, maar voor degenen die verkocht zijn aan een droom van radicale verbetering, is 'agile leven' in plaats van 'agile doen' een essentiële volgende stap.  

Dit kan worden bereikt door de empirische fundamenten van alle beste frameworks te benutten – door transparantie en leren door inspectie en experimentele aanpassing uit te buiten die ten grondslag liggen aan de agile manier van werken.

Hoewel aanzienlijke verbeteringen relatief snel kunnen worden gerealiseerd, is het omarmen van wendbaarheid niet altijd gemakkelijk omdat het meestal een gedragsverandering vereist binnen en rondom leveringsteams. Het optimaliseren van wendbaarheid is een nooit eindigende reis, en het is vermeldenswaard dat aanpassing in de menselijke aspecten van de manier van werken in plaats van de procesaspecten waarschijnlijk de rijkste beloningen zal ontgrendelen.