Agile als bijvoeglijk naamwoord

"Doen jullie Agile?" is een vraag die je vaak hoort op conferenties en netwerkborrels. Vaak gesteld door de zoveelste "digital transformation" consultant die je wat uren en zelfgebakken methodieken probeert te verkopen. "Agile doen" is het nieuwe goud en als je niet op de trein naar Klondike zit dan tel je niet meer mee als bedrijf. Paniek!

Agile is ontstaan als tegenbeweging tegen het vele plan- en onderzoekswerk van de waterval-methodiek. De gefaseerde waterval aanpak leidde vaak tot stugge processen met lange doorlooptijden waarin de gebouwde oplossing zelden aansloot bij de wensen van de klant. De afgelopen jaren zijn er al veel verschillende smaken Agile langsgekomen: SCRUM, NEXUS, SAFe, Kanban, XP, Crystal, FDD, MSN, DSDM, Enterprise Agile. Schitterende acroniemen waarvan ik er zelf één van heb verzonnen, want het zou zomaar een Agile-methodiek kunnen zijn.

En zoals met elke tegenbeweging wordt dit uiteindelijk verpakt en voor een prijs weer aangeboden. Kijk maar hoe dat met Punk, Che Guevara en de Tesla's ging. Stukje cultuur als een comfortabel pak, zolang je er maar geld aan uitgeeft. Dat heeft geleid tot een volledige nieuwe industrie waar onwijs veel geld in omgaat. En tot fancy job titels als Agile coach, Principal Agile Practitioner en misschien nog wel de mooiste: Agile Delivery Lead.

Het jammere van deze commercie is dat de originele intentie — ofwel de spirit — verloren raakt in de buzzwords, sales pitches, trainingen en certificeringen.

De belofte van Agile

Veel bedrijven zitten met de uitdaging dat ze de juiste producten en diensten willen ontwikkelen voor een markt die razendsnel verandert. Deze bedrijven hebben doelstellingen die ze moeten halen. En de markt eist een bepaalde mate van flexibiliteit om daarin succesvol te zijn. Agile zou deze flexibiliteit bieden, zodat een bedrijf snel kan schakelen en itereren wanneer situaties veranderen. Vaak wordt een framework gebruikt om Agile te adopteren.

Laten we SCRUM als voorbeeld pakken. SCRUM is een lichtgewicht framework uit begin jaren '90 voor het managen van complex werk. Volgens SCRUM kun je van tevoren niet alles weten. Dus verschuift het de focus naar hoe je teams snel kunt laten leveren, zodat producten snel getest worden en doorontwikkelingen direct kunnen reageren op veranderingen in de markt. Het heeft een aantal onderdelen, waaronder een product backlog, sprint planning, sprint board, refinement en een retro.

Als bedrijf adopteer je dit framework in alle afdelingen en pas je de SCRUM onderdelen toe. Je wijst een SCRUM master en product owner aan en zet alles netjes in een backlog. En dan kunnen er sprints gedraaid worden. Huppetee op de trein naar Klondike, toch?

In mijn ervaring draait dit vooral uit op backlog tickets waarin de oplossing van de user story tot in de fijnste details is vastgelegd. Vervolgens wordt hier eindeloos over gekibbeld (of het wel of niet alle requirements bevat) in een 3 uur durende refinement sessie (waarvan de tweede helft in de sprint planning plaats vind). Aan het eind van de sprint is er een retro (waar iedereen zijn plus en minpuntjes opleest) waarin er afspraken worden gemaakt (die vervolgens worden vergeten en niet worden nageleefd). Oh ja, voorafgaand aan de sprint zat twee maanden aan onderzoek en specificatie werk (waar het team niet bij betrokken was).

Het uiteindelijke resultaat is vaak dat SCRUM of Agile niet aan zijn belofte voldoet. Gevolg: boze mensen die de tool de schuld geven. Ander gevolg: een bedrijf dat nog steeds met dezelfde uitdaging zit, maar nu wel Agile doet. Waar zit het hem dan in?

Het bijvoeglijk bij het naamwoord zetten

Om tot de kern van een concept te komen is het altijd handig om naar de algemene definitie te kijken:

Agile
adjective — able to move quickly and easily.

Een bijvoeglijk naamwoord dus. Iets wat wordt gebruikt om iets nader te omschrijven. "Agile" omschrijft dus hoe iets beweegt, niet wat iets is. Dat is namelijk een naamwoord — en Agile als naamwoord zegt helemaal niks.

De "hoe" is essentieel voor het kunnen plakken van "agile" voor "bedrijf" of "team". En elk bedrijf en elk team is anders: andere uitdagingen, andere mensen en andere behoeftes. En daarmee een andere aanpak om effectief te zijn. Het originele manifesto stelt twaalf principes voor als basis voor de hoe. Dit vind ik de belangrijkste 3 die universeel toepasbaar zijn (dus niet alleen binnen software development!):

  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • Simplicity the art of maximizing the amount of work not done is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

SCRUM is slechts een middel om een bepaalde manier van werk te faciliteren. Hoe je SCRUM — of een ander framework — uitvoert bepaalt het resultaat, niet het framework zelf. Bij Aiden werken wij ook met SCRUM, maar met onze eigen (in)vulling en een hoop special sauce.

Spoiler alert: onze manier werkt voor ons, maar waarschijnlijk niet voor jou. Zoals eerder gezegd, elk bedrijf en elk team is anders. Maar er is niks mis met inspiratie, dus pik eruit waar je denkt dat je wat aan hebt!

Kijkje in de keuken van Aiden


Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

De belangrijkste middelen in een bedrijf zijn de mensen zelf. Daar besteden wij dus veel aandacht aan. Denk aan een flink educatie budget dat iedereen zelf mag besteden aan de vaardigheden die zij willen opdoen of verfijnen om hun werk beter te doen. En een regelmatige borrel of teamuitje (aanrader: escape rooms). Dit creëert een hechte band binnen ons team, motiveert en bouwt vertrouwen. Vertrouwen door elkaar beter te leren kennen. Dit is iets wat geen enkel Agile Framework je gaat brengen, maar wat essentieel is voor het succes van jouw bedrijf. Deze activiteiten vormen samen een omgeving en sfeer waarin alles besproken kan worden en waar mensen op elkaar kunnen bouwen. En dát vormt effectieve teams.

We hebben ook formele momenten. Elke maand heeft iedereen een catchup een gesprek tussen jou en twee collega's om te kijken hoe dingen gaan, waar je tegenaan loopt en wat er gedaan kan worden om jou te helpen in jouw werk. Waarom elke maand? Dat werkt voor ons. Misschien dat we dit minder frequent gaan doen als blijkt dat er minder een behoefte is, misschien dat we het vaker doen als de behoefte toeneemt.

Daarnaast gebruiken we bij Aiden ook het SCRUM framework, nu al iets van 9 maanden. We hebben tweewekelijkse sprints, maar overwegen nu sprints van een week. Zodat we sneller kunnen schakelen en wat vaker een focus moment hebben om onze volgende kleine stap te plannen.


Simplicity — the art of maximizing the amount of work not done — is essential.

Iets wat we niet doen bij Aiden zijn volledige projecten inschatten met story points, om vervolgens de gemiddelde geleverde punten per sprint te gebruiken voor een projectie van wanneer een project af is. Dit creëert een valse verwachting naar het team en de stakeholders toe. En doet teniet waarom je in eerste instantie agile wilde gaan werken. Je focust daarmee namelijk op de lange termijn, in plaats van op de korte termijn en de veranderingen die zich kunnen voordoen. Tijdens het uitvoeren van een project wordt er eigenlijk altijd nieuwe kennis opgedaan, waardoor bestaande estimates niet meer kloppen of volledige features komen te vervallen. Kleine stapjes!

Ook belangrijk: het doel van de sprint is nooit om al het werk wat gepland is afkrijgen. Tuurlijk, bepaalde beloftes en afspraken maak je met je stakeholders. Maar als je denkt dat het belangrijk is om n features of story points op te leveren, dan ben je met de verkeerde metric bezig. Output is een slechte metric als je gaat voor kwaliteit en effectieve oplossingen. En dat is nou net waar we bij Aiden voor gaan. Je weet wel, echte meerwaarde voor je gebruiker en bedrijf.

Hoe houden we het bij Aiden "simpel"? Binnen sprints proberen wij te experimenteren met verschillende oplossingsrichtingen. Dit doen wij door soms verschillende schetsen te maken, prototypes te maken of een halve implementatie te doen en deze vervolgens in diezelfde sprint te testen met gebruikers. Zo kom je snel tot meer inzichten waardoor je betere keuzes kunt maken om je doel te bereiken — en vaak heeft dit als gevolg dat je minder hoeft te maken wat vervolgens agility faciliteert.


The best architectures, requirements, and designs emerge from self-organizing teams.

Bij Aiden werken we in een multi-disciplinair, zelfsturend team. Designers, developers, researchers en infrastructuur mensen allemaal bij elkaar in de sprint. Samen onderzoeken en overwegen wij oplossingen die op korte en lange termijn voor resultaten moeten zorgen. De beste kennis om die overwegingen te maken zit in de teams die het product doorontwikkelen en onderhouden.

Wat betekent dit in de praktijk? Wat ik vaak zie in organisaties die Agile doen, is dat de user stories volledig gespecificeerd worden en de oplossing al vastgelegd wordt voordat het team de story onder ogen krijgt. Kortom, in het ticket staat exact welk probleem er is en hoe dit opgelost moet worden. Niet alleen is dit zonde van alle tijd en energie die erin gaat zitten, maar mogelijk ook beperkend voor het team dat de user story probeert te vervullen.

Experimenteren is essentieel om te voorkomen dat je als team in de uitvoermodus komt te zitten en de eerste de beste oplossing maakt die boven tafel komt. Wanneer user stories omschreven worden als oplossing heeft dat een beperkend effect op het gevoel van ruimte dat een team ervaart. Zeker in software loont het om goed na te denken over oplossingsrichtingen voordat je een richting kiest. Want wat je bouwt moet je onderhouden. Een verkeerde keuze kan zelfs toekomstige features of wijzigingen in de weg zitten. Kom dus met een probleem en laat de oplossing aan het team over.

Een super agile conclusie

Samenvattend: agile werken is doelen stellen, een klein stapje daarnaartoe nemen, her-evalueren waar je staat en kijken wat je volgende stap moet zijn. Belangrijk hierin is het constant experimenteren met processen en oplossingsrichtingen om te kijken wat werkt, wat niet (meer) werkt en wat beter kan om je doelstellingen te behalen. Doe dit, in plaats van Agile doen. Of doe het helemaal niet als het niet voor jou werkt.