slim
samen
werken

Wat zijn de 4 Agile waarden? Uitleg & praktische voorbeelden

In het zeer uitgebreide artikel Wat is Agile? is het volgende te lezen: Definitie Agile: “Een mindset die verandering omarmt om snel waardevolle resultaten te leveren en hiervan te leren.” De Agile mindset wordt gevormd door 4 waardes en 12 principes, dit wordt het Agile Manifest genoemd. In dit artikel gaan we in op de vier waarden met uitleg & praktische voorbeelden.

De 4 agile waa

Dit is een blog uit een reeks van 3 over het Agile en de bijbehorende waarden en principes. Lees hier de overige 2 blogs:

Wat zijn de 4 Agile waarden?

De onderstaande vier waarden van het Agile Manifest zijn vrij vertaald, zodat het ook op non-IT situaties het van toepassing is.

Agile teams waarderen:

  1. Mensen en hun onderlinge interactie gaat boven processen en tools
  2. Werkende producten of diensten gaat boven allesomvattende documentatie
  3. Samenwerking met de klant gaat boven contractonderhandelingen
  4. Inspelen op verandering gaat boven het volgen van een plan

Je kunt de Agile waarden als volgt lezen: “gaat boven” kun je ook vervangen door “is belangrijker dan”.

Oftewel het betekent dat in het geval van Agile waarde nummer drie we de samenwerking met de klant belangrijker vinden dan een contract. Natuurlijk hebben we nog steeds contracten, maar de samenwerking moet de basis zijn. Op deze manier kun je ook later in het project omgaan met veranderende omstandigheden, in plaats van een stijf contract dat je aan het begin van een project opstelt, terwijl je op dat moment nog het minste weet.

Wat ook behulpzaam kan zijn bij het lezen van de Agile waarden: hetgeen wat rechts staat moet bijdragen aan links. Dus draagt de documentatie bij aan werkende producten of diensten?

Waarom zijn de Agile waarden belangrijk?

Welk Agile Raamwerk je nu gebruikt, of het Scrum, Kanban of SAFe is. Je kunt er vergif op innemen dat er tijdens een sprint vragen zijn waar de Scrum Guide geen expliciet antwoord op geeft. Wat doe je als de Stakeholder steeds meer wensen heeft die eerst niet duidelijk waren? Wat doe je als een Developer ontslagen is en er een gat qua kennis ontstaan? Wat doe je als de verwachtingen van de Product Owner anders zijn dan die van de Scrum Master?

Op dit soort vragen geeft Scrum geen antwoord, maar wellicht dat de Agile waarden je wel kunnen helpen. Zie de Agile waarden dan ook als een kompas en leidend bij het nemen van beslissingen.

Mensen en hun onderlinge interactie over processen en tools

Onze processen zijn belangrijker dan dat we elkaar goed begrijpen. Deze zin leest gek toch? Vandaar dat de eerste Agile waarde is:

“Mensen en hun onderlinge interactie gaat boven processen en tools”

Alleen wat betekent dit precies? Het houdt in dat je eerst moet zorgen dat je elkaar als collega’s heel goed begrijpt. Daarna kunnen we processen en hulpmiddelen inrichten om deze samenwerking te bevorderen. In andere woorden: processen en tools dienen als aanvulling op, en niet als vervanging van mensen en hun onderlinge interactie.

Voorbeelden:

  • Laat nieuwe medewerkers zelf beslissen of ze een Windows of Apple laptop willen, in plaats van dat je het door het bedrijf laat opleggen. We schuiven dus niet een specifieke tool naar voren die ooit is afgesproken. Maar zorgen dat mensen die er elke dag mee gaan werken zelf invloed op hun keuze hebben.
  • In plaats van een rigide proces in te richten hoe we elkaar inlichten over de voortgang en obstakels van het project, kunnen we ook dagelijks kort bij elkaar zitten om het te bespreken terwijl we elkaar in de ogen kijken, oftewel een Daily Scrum / Stand-up.

Werkende producten of diensten gaat boven allesomvattende documentatie

We hebben liever een pak papier op ons bureau dan een werkend product. Als je dit leest snap je ook wel dat het niet klopt, maar helaas zie je het nog veel te veel gebeuren. Daarom de tweede Agile waarde:

“Werkende producten of diensten gaat boven allesomvattende documentatie”

Dit wil natuurlijk niet zeggen dat niks meer gedocumenteerd hoeft te worden. Op de korte termijn lijkt dit misschien makkelijk, maar op de lange termijn is het vragen om problemen. Zeker als de personen die ooit iets gemaakt hebben niet meer voor de organisatie werken en kennis verloren gaat.

Kortom: goede documentatie en handleidingen zijn belangrijk, zodat er naslagwerk is als we in de toekomst iets willen veranderen. Toch moet de focus gaan naar werkende producten of diensten aangezien daar meer waarde in zit.

Voorbeelden:

  • Documenteren kost tijd. In dezelfde tijd zouden we ook kunnen bouwen aan een werkend product of dienst. Het is daarom slim om aan het einde van het project meer tijd te nemen voor documentatie, maar dit te beperken als je nog volop in het project zit. Dit biedt een belangrijk voordeel: omdat je in dezelfde tijd meer gebouwd hebt kun je ook meer aan de stakeholder laten zien en daardoor meer feedback ontvangen.
  • Je documentatie op papier kan helemaal top zijn, maar het enige écht tastbare bewijs van voortgang krijg je door iets werkends te laten zien waar je feedback op kan krijgen. Dit kan software zijn, maar mocht je je in een non-IT situatie bevinden dan kan het lastig zijn om iets ‘werkends’ na elke sprint op te leveren. Laat dan in ieder geval iets zien waar je feedback op kan krijgen, in plaats van alleen documentatie. Bijvoorbeeld: het programma met artiesten van een festival, een prototype van een product, een try-out van 10 minuten voor een klein publiek voordat je op het podium staat voor 1000 bezoekers.

Samenwerking met de klant gaat boven contractonderhandelingen

We vinden het contract belangrijker dan dat de klant daadwerkelijk blij is met het product. Dit klopt niet, want bij Agile werken staat klantwaarde bovenaan. Daarom de derde Agile waarde:

“Samenwerking met de klant gaat boven contractonderhandelingen”

Contracten en budgettering zijn binnen Agile werken nog steeds belangrijk alleen de samenwerking met de klant staat voorop. Tenslotte weten we dat de klantwensen tijdens het project zullen veranderen, als hier goede ideeën uitkomen willen we die doorvoeren. Mocht een contract helemaal zijn dichtgetimmerd dan kun je natuurlijk minder wendbaar ofwel Agile zijn.

Voorbeelden:

  • Aan het begin van een project weten we vaak nog het minst. Toch is dit het moment waarin veelvuldig de contracten worden opgesteld samen met de scope. Wil je halverwege je project iets veranderen door voortschrijdend inzicht? Dan is dat lastig. Als je je contract meer insteekt op samenwerking kun je afspreken dat je na elke sprint samen met de stakeholders bekijkt of de scope nog steeds actueel is. Geheid dat we veranderingen zullen doorvoeren die we in het begin van het project nooit hadden kunnen bedenken.
  • Strenge contracten die erg rigide zijn kunnen problematisch zijn als de marktomstandigheden snel veranderen. Bedrijven zullen flexibel moeten reageren en dan zou je elke keer opnieuw je contracten moeten openbreken. Niet heel praktisch.
  • Strikte contracten kunnen creatieve ideeën en innovaties in de weg staan. Tenslotte staat de uitkomst van het project toch vastgesteld in de strenge kaders van het contract en hebben medewerkers minder ruimte om zelf hun creativiteit los te laten gaan.

Inspelen op verandering gaat boven het volgen van een plan

Het plan is heilig, elke verandering die ons plan in de weg staat moeten we zien te voorkomen. Als we Agile werken doen we dat in een omgeving waarin we niet alles van tevoren kunnen voorspellen, zie Stacey Matrix. We weten linksom of rechtsom dat de omstandigheden veranderen. Vandaar dat een strikt plan nooit zal werken. Daarom de vierde Agile waarde:

“Inspelen op verandering gaat boven het volgen van een plan”

Een planning binnen Agile is essentieel, maar hoeft niet allesomvattend te zijn voor de lange termijn. Bij de start van een project weten we vaak het minste van de risico’s en nieuw inzichten. Daarom kunnen we ons goed vastleggen aan een gedetailleerde planning voor de korte termijn, maar in de verre toekomst praten we over een Productvisie, een MVP en Sprint Goal.

Voorbeelden:

  • Teamleden komen en gaan. Ze zullen ingewerkt moeten worden, kennis zal overgedragen worden of kennis zal verloren gaan. Hierop valt lastig een plan te maken.
  • Bij de stakeholders veranderd de visie of is voortschrijdend inzicht waardoor het originele plan aangepast moet worden.
  • Wet- en regelgeving veranderd waardoor we ons product moeten aanpassen.

Samenvattend: wat zijn de 4 Agile waarden?

Je weet nu wat de 4 Agile waarden zijn en hoe je ze ziet terugkomen in de praktijk. Alleen hoe kun je de Agile waarden binnen je eigen team omarmen? Om te beginnen kun je dit artikel doorsturen, zodat de Agile waarden bij alle teamleden bekend zijn. Daarna kun je ze bijvoorbeeld tijdens een Retrospective bespreken. “Hoe vinden wij dat we de Agile waarden omarmen?”

Mocht je behoefte hebben aan een Agile Coach die met je kan sparren over hoe je dit het beste kan faciliteren? Neem dan contact met ons op via info@agilescurmgroup.nl of 020 2614 195.

Ook interessant:

Over de auteur: Rob Koppenaal

Rob is Agile coach en trainer. Met zijn ervaring uit informatiekunde, toegepaste cognitieve psychologie, datingcoach, Product Owner en Scrum Master / Agile Coach van vele teams geeft Rob het theoretische kader met praktische oefeningen om blijvende veranderingen te realiseren. Met het resultaat dat er een hoop wordt gelachen en cursisten met motivatie en kennis naar huis gaan. Naast anderen helpen te ontwikkelen, is Rob ook altijd bezig met zichzelf te verbeteren.