Agile is niet meer weg te denken uit het bedrijfsleven. In deze almaar veranderende wereld is wendbaar blijven een must. Op de werkvloer gebruiken veel werknemers en managers inmiddels Agile termen om deze werkwijze eigen te maken. Wellicht ook in jouw organisatie. Maar weet jij de oorsprong van Agile?
Op 13 februari 2001 kwamen 17 software-Developers van verschillende organisaties samen in Utah, de Verenigde Staten. Zij kwamen bij elkaar om inzichten te delen en te leren van elkaar. Deze Developers gebruikten al nieuwe methoden om software te ontwikkelen, zoals eXtreme Programming, Crystal en DSDM. De conferentie in Utah leek een uitgelezen kans om hun werkwijzen te vertegenwoordigen en de koppen bij elkaar te steken over wat nog meer mogelijk was.
De traditionele manier van ontwikkelen duurde namelijk te lang, kostte te veel tijd en zorgde voor onenigheid tussen Developers en opdrachtgever. Het moest sneller, effectiever en vooral beter om kunnen gaan met de complexiteit van het proces van softwareontwikkeling. Door het naast elkaar leggen van hun verschillende methoden vonden de Developers in Utah overlap in hun werkwijzen. Deze overeenkomsten legden zij vast in het Agile Manifesto.
Het Agile Manifesto is een kort document dat 4 waarden en 12 principes beschrijft. Hiermee laten de Developers zien dat er betere manieren zijn om software (en producten en diensten) te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen ze:
Met ‘boven’ wordt bedoeld: belangrijker dan. Als we bijvoorbeeld kijken naar het tweede principe, dan wordt een werkend product belangrijker gevonden dan een ellenlange handleiding bij dat product. En dat is eigenlijk ook wel logisch: stel dat je een nieuwe telefoon koopt, dan sta je toch een beetje gek te kijken als er meer aandacht is besteed aan de documentatie die erbij komt dan aan het toestel zelf. Dat wil niet zeggen dat er helemaal geen handleiding of documentatie nodig is, maar wel dat de meerwaarde voor de klant zit in het werkende product.
Eigenlijk kun je stellen dat hetgeen dat rechts staat, moet bijdragen aan dat wat links staat. Dus de eerste waarde uit het Agile Manifesto zegt dat processen en hulpmiddelen moeten bijdragen aan mensen en hun onderlinge interactie – ze zijn ondersteunend aan het onderlinge begrip en de communicatie tussen mensen. Klinkt logisch, maar toch zien we dit nog weleens mis gaan. Een Product Owner kan soms meer bezig zijn met de keuze voor een bepaalde applicatie om de voortgang van het project in bij te houden, dan met het uitdragen van een heldere productvisie. Maar als Developers geen goed beeld hebben bij de visie van de PO, dan kunnen ze zelfs met state-of-the-art applicaties niet genoeg waarde leveren.
Het Agile Manifesto stelt ook dat samenwerken met de klant belangrijker is dan contractonderhandelingen. Juist in een snel veranderende wereld kunnen al te rigide contracten een enorme belemmering zijn. Contracten worden opgesteld op het moment dat je eigenlijk nog het minst weet, namelijk aan het begin van het project. Maar we leggen daarin al wel de hele scope vast. Als zowel opdrachtgever als opdrachtnemer krampachtig blijven vasthouden aan contractuele afspraken gedurende het project, dan is de kans groot dat het eindresultaat tegenvalt (en dat opdrachtgever en opdrachtnemer lijnrecht tegenover elkaar zijn komen te staan). Maar hoe doe je dat dan, samenwerken met de klant? Scrum heeft daar een elegante oplossing voor: de Sprint Review. Aan het einde van de Sprint presenteer je het Increment en wat je hebt geleerd en stem je met de stakeholders af of je nog op de goede weg bent of dat er aanpassingen nodig zijn.
Tot slot kijken we nog naar de vierde waarde: het inspelen op verandering boven en het volgen van een plan. Dit betekent niet dat het maken van plannen niet belangrijk is. Het zegt alleen dat je niet koppig een plan moet blijven volgen terwijl de wereld om je heen verandert. Ook in Agile projecten worden plannen gemaakt, alleen zijn die voor de lange termijn niet al te gedetailleerd. We weten namelijk niet precies wat de toekomst brengt. Voor de korte termijn kunnen we dat wel goed inschatten en ons committeren aan een gedetailleerde planning. Als we weer Scrum als voorbeeld nemen, dan zien we dat het resultaat van de Sprint Planning een gedetailleerd plan is voor de komende Sprint.
Kortom, deze 4 Agile waarden voorzien in de behoefte aan minder bureaucratie, meer communicatie en afstemming binnen teams en tussen opdrachtgever en -nemer en in de wens sneller te kunnen schakelen om vlug een werkend product op de markt te brengen dat door korte feedbackloops blijft inspelen op de vraag vanuit de markt en de stakeholders.
De 4 waarden van het Agile Manifesto vertalen zich naar de volgende 12 principes:
Ook al hebben de afzonderlijke Agile methodieken en raamwerken vaak hun eigen principes en waarden, je zult bovenstaande waarden en principes terug zien komen als gemene deler. Zo komen de events in Scrum bijvoorbeeld terug in principe 4, 6 en 12.
En hoewel het Agile Manifesto duidelijk geschreven is met softwareontwikkeling in het achterhoofd, zijn de waarden en principes wel degelijk geschikt voor niet-IT organisaties. Overal waar je ‘software’ leest in de Agile principes, kun je dit vervangen voor ‘producten en diensten’.
Het Agile Manifesto geeft Agile organisaties richting. Er bestaan tientallen (zo niet honderden) verschillende Agile raamwerken en methodes, maar die geven je niet altijd antwoord op vragen waar je in de praktijk tegenaan loopt. Laten we Scrum weer als voorbeeld nemen. De Scrum Guide beschrijft Scrum met alle events, verantwoordelijkheden en artefacten die daarbij horen. Maar wat doe je als er onvoldoende betrokkenheid is van de stakeholders? Of juist als er heel veel externe druk is om meer werk te verzetten dan eigenlijk mogelijk is? En wat doe je als het team gedemotiveerd lijkt te zijn of de werkverdeling? En wat kun je doen als de Scrum Master Scrum heel dogmatisch toepast? Op deze vragen geeft de Scrum Guide niet direct antwoord, maar kun je de Agile waarden en principes uit het Manifesto als leidraad gebruiken om deze problemen het hoofd te bieden.
Welke Agile Manifesto principes gebruik jij en welk Agile Manifesto principe heeft nog een ontwikkelslag nodig in jouw organisatie? Toets dit: leg alle 4 waarden van het Agile Manifesto op tafel en leg deze op volgorde van boven naar onder welke het belangrijkst is in jouw organisatie, team of project. Hoe Agile zijn jullie?