Wat is een Agile Methodologie?

Terwijl ik de vraag 'wat is een agile methodologie?' ga beantwoorden, zal ik proberen enkele taalkwesties te verduidelijken die de neiging hebben om in de weg te zitten. Bijvoorbeeld, is er een 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 over bovenstaande lopen uiteen, dus ik zal het concept van behendigheid 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 bewegen. 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 dubbelzinnigheid 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 het gebruik van hoofdletters bij Agile versus agile te gebruiken om onderscheid te maken tussen deze. Dit alleen al kan uren van soms vermakelijke, maar vaker frustrerende discussie voeden over wat belangrijker of waardevoller is – Agile doen of wendbaar zijn?

Persoonlijk zou ik liever focussen op de gemeenschappelijke basis – erkennen dat denken en doen nauw verbonden zijn. Sterker nog, gegeven de eerdere definitie van wendbaarheid, vooral het aspect gerelateerd aan responsiviteit, zou het niet eens mogelijk moeten zijn om 'Agile te doen' zonder nadenken. 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 visie hierover deel, is het het beste om te zeggen dat de woorden methode, framework en benadering vaak door elkaar gebruikt worden met methodologie.

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

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 behandelen de menselijke aspecten van wendbaarheid, terwijl proces, praktijken en werkproducten de structuur en mechanismen voor oplevering bieden.

Enkele van de meest populaire agile frameworks zijn onder andere:

Scrum is een agile framework dat voornamelijk wordt gebruikt bij het ontwikkelen van producten. Het heeft zijn oorsprong in de software ontwikkelingswereld en dat is waar het nog steeds het meest wordt gebruikt. In tegenstelling tot wat vaak wordt beweerd 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 na te streven en bij elkaar te ondersteunen. Scrum definieert ook drie rollen binnen het framework:

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

Productlevering wordt georganiseerd in een eenvoudige herhalende cyclus van ontwikkeling die een Sprint wordt genoemd. Sprints zijn doorgaans kort – een maand of minder in duur. Elke cyclus begint met events (korte, gerichte vergaderingen) om het werk overeen te komen 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 vergadering die door de Developers wordt gebruikt om de focus te behouden op het leveren van hun overeengekomen 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 van deze, 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 misschien technische verdienste zit in dat argument, is het voor de meeste doeleinden irrelevant. Net als Scrum beschrijft Kanban een manier van werken die zich richt op het vroeg en vaak leveren van waarde, samenwerking tussen teamleden stimuleert en hen de macht 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 trekken een werkitem uit een backlog zodra ze het vorige item hebben afgerond. In tegenstelling tot Scrum, dat de voorkeur geeft aan teamleden die multifunctioneel zijn (multi-vaardig), zijn overdrachten van de ene naar de andere persoon in Kanban gebruikelijker. Het aantal Work in Progress (WiP) items wordt opzettelijk beperkt, waardoor teamleden worden aangemoedigd samen te werken om problemen op te lossen 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 feedbackloops; Verbeter samen; en Ontwikkel experimenteel.

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

SAFe – het Scaled Agile Framework – is een beetje anders omdat het, zoals de naam al suggereert, een veel groter plaatje adresseert. Het is specifiek ontworpen om agile praktijken te schalen over 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 opleveren 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 oplevering op teamniveau, maar ook strategische afstemming, governance, budgettering en samenwerking tussen teams.

Belangrijke rollen in SAFe zijn onder meer:

• 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ördinatie van prioriteiten en architectuur over teams heen,
• Lean Portfolio Management – het afstemmen van investeringen op strategie.

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

• PI Planning – een grootschalige, face-to-face planningssessie die alle teams afstemt op doelen en afhankelijkheden,
• System Demos – die geïntegreerde voortgang over teams heen tonen,
• Inspect & Adapt – een gestructureerde retrospectieve voor continue verbetering.

SAFe moedigt Lean-Agile leiderschap, een continue leercultuur en klantgericht denken aan. Hoewel meer voorschrijvend dan Scrum of Kanban, biedt SAFe een steiger voor schaalvergroting, waardoor organisaties wendbaarheid kunnen behouden terwijl ze complexiteit en afstemming op ondernemingsniveau managen.

AgilePM verschilt ook een beetje doordat het zich richt op een project in plaats van een productcontext, waarbij alle klassieke aspecten van projectmanagement worden behandeld, maar op een fundamenteel agile manier. Het brengt alle voordelen van wendbaarheid in evenwicht met de discipline van meer traditionele projectmanagementmethoden.

Het is bijzonder geschikt voor organisaties zoals overheidsinstellingen, financiële dienstverleners, of andere gereguleerde industrieën die zekerheid voor belanghebbenden, gedefinieerde rollen en verantwoordelijkheden, en een gecontroleerde leveringsomgeving vereisen.

AgilePM omvat 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 resultaten, waarbij alle werkzaamheden worden omvat die nodig zijn om waarde te realiseren in plaats van alleen iets te leveren dat waardevol zou moeten zijn.

Zoals elk goed agile framework bevat het zowel menselijke als procesmatige elementen, die allemaal zijn geïdentificeerd in het onderstaande diagram.

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

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

De laatste tijd lijken sommige organisaties ontgoocheld 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 zo? Komt het doordat agile frameworks niet werken? Komt het doordat er te veel werd beloofd? Of komt het door een gebrek aan aandacht voor methodologie?

Ik ben sinds het ontstaan van agility in het midden van de jaren negentig betrokken geweest bij het implementeren, aanpassen en zelfs creëren van agile frameworks. Nadat ik het goede, het slechte en het lelijke van initiatieven om prestaties te verbeteren door middel van agility heb meegemaakt, en soms geleid, denk ik dat het laatste van deze het dichtst bij de waarheid ligt.

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 eenvoudig… Werk in korte sprints vanuit een geprioriteerde backlog van werk, houd frequente productbeoordelingen tijdens de ontwikkeling, houd dagelijks 15 minuten durende 'stand-up' teammeetings, etc.

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

Alle agile benaderingen benadrukken zelforganisatie (of zelfmanagement) op teamniveau. De aanname hierachter is dat degenen die het dichtst bij het werk staan het best gekwalificeerd zijn om te beslissen wat de beste manier is om het uit te voeren. Voeg daar de noodzaak aan toe 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 een evenwicht vinden tussen autoriteit over wat te doen, wanneer en hoe, om een afgesproken doel te bereiken, en de competentie om dat effectief te doen. 

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

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

Een van de kenmerken van de mens die ons onderscheidt van de meeste andere diersoorten is ons vermogen om samen te werken bij het oplossen van problemen. Samenwerking wordt aangedreven door onze geavanceerde communicatievaardigheden – voornamelijk ons vermogen om gedachten en ideeën te delen door middel van taal. Alle agile benaderingen hebben collaboratief werken als kern en zijn afhankelijk van 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 belangrijk wordt... Een van de hoofdoorzaken van het falen van agile transformatie-initiatieven komt voort uit een gebrek aan intelligente, pragmatische toepassing. Dit komt terug op de allesbepalende menselijke basis van wendbaarheid. Als je Scrum, AgilePM of welk ander agile framework dan ook puur behandelt als een set processen die gevolgd moeten worden, is het onwaarschijnlijk dat je er veel waarde uit zult halen.

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

• Transparantie van zowel de gevolgde aanpak als de vooruitgang die wordt geboekt richting de gewenste doelstellingen is essentieel. Het is noodzakelijk om mogelijk te maken...
• Inspectie van beide. Specifiek analyseren of iedereen die betrokken is de werkwijze 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 stakeholders buiten het team zullen waarschijnlijk aanpassingen moeten maken aan de manier waarop zij werken.
  • De standaard processen en praktijken in het framework moeten mogelijk worden aangepast voor optimale resultaten. Alle aanpassingen die het team in staat stellen om efficiënter en effectiever te zijn in het bereiken van zakelijke einddoelen zouden moeten worden overwogen. Met wendbaarheid 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 continu leveren van bedrijfswaarde, terwijl het verandering en onzekerheid gedurende de gehele levenscyclus van het project omarmt. In tegenstelling tot traditionele methoden die sterk leunen op gedetailleerde voorafgaande planning en uitgaan van een stabiele omgeving, is AgilePM gebouwd om te gedijen 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 werkelijk 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 real-world 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, wat flexibiliteit en aanpasbaarheid aanmoedigt terwijl het nog steeds robuuste controles en verantwoordelijkheid biedt.

Over het algemeen is Agile Project Management, geëxemplificeerd door AgilePM, een gedisciplineerde maar aanpasbare benadering van projecten die agiliteit balanceert met governance. Het is vooral effectief voor projecten waar verandering wordt verwacht en klantwaarde een centrale focus is. Het helpt bedrijfsagiliteit 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 aanpasbaarheid en innovatie benadrukten in het licht van snelle veranderingen. De term "bedrijfsbehendigheid" werd begin jaren 2000 prominent, beïnvloed door de Agile Software Development-beweging, en is sindsdien geëvolueerd om bredere organisatiepraktijken te omvatten.

Belangrijke aspecten van bedrijfsbehendigheid zijn onder andere:

• 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 Aanpasbaarheid: Dergelijke organisaties kunnen processen en structuren snel aanpassen als reactie op zowel kleine variaties als significante veranderingen, waarbij ze vertrouwen op geautoriseerde 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 de eigendom van hun workflows te geven.

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 die een cultuur vereist die voortdurend leren en aanpassen ondersteunt. Het implementeren van behendige frameworks zoals Scrum kan een startpunt zijn, maar echte behendigheid vereist een mentaliteitsverandering 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 in de wereld. Dat gezegd hebbende, ik geloof dat methodologie een diepere duik suggereert in het waarom en hoe methoden 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 de 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 te exploiteren en te leren door inspectie en experimentele aanpassing die de agile manier van werken ondersteunen.

Hoewel aanzienlijke verbeteringen relatief snel kunnen worden gerealiseerd, is het omarmen van behendigheid niet altijd gemakkelijk omdat het meestal een gedragsverandering vereist binnen en rondom leveringsteams. Het optimaliseren van behendigheid 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.