Auteur: Rik Marselis ● rik@marselis.eu
Redactie: Frits van Iddekinge en Eric Spaargaren
Kortgeleden was ik in een workshop met een aantal mensen die zichzelf Agile Test Engineer noemen. Toen ik over het Agile Manifesto begon bleek al rap dat ze er wel over gehoord hadden, maar feitelijk geen idee hadden waar het Manifesto over gaat. Wat bij mij de vraag opriep: Als je niet kunt vertellen over het Agile Manifesto, kun je dan wel “Agile zijn”? Alleen maar elke dag een standup doen is iets anders dan “Agile doen”. Je hoeft het Agile Manifesto niet uit je hoofd te kunnen opdreunen (je kunt het tenslotte op elk moment van de dag opzoeken op https://agilemanifesto.org/ in 67 talen), maar als je vanuit een Agile mindset wilt bijdragen aan IT-systemen, dan is een begrip van waar het over gaat wel van belang.
Het Agile Manifesto is opgesteld door een groep mensen die simpelweg een betere manier van systeemontwikkeling wilden bereiken, ten opzichte van de toen gangbare sequentiële werkwijze. Een belangrijk verschil tussen traditionele systeemontwikkeling en de Agile werkwijze is dat traditioneel het proces centraal stond, terwijl bij Agile mensen centraal staan. Het gaat om samenwerking tussen teamleden met verschillende kennis en vaardigheden, en samenwerking met degenen voor wie het systeem ontwikkeld wordt. Plannen zijn belangrijk, maar als de wereld verandert dan moet je daarin mee, dus flexibel meebewegen. En het doel is pas gehaald als er werkende software is.
Bij deze vier kernwaarden van Agile horen wel wat toelichtingen:
Ja, werkende software is belangrijker dan uitgebreide documentatie, maar enige mate van documentatie is onontbeerlijk (dus laat niemand beweren dat documenteren niet meer hoeft nu we Agile werken).
Ja, flexibiliteit is belangrijk, maar het is wel de bedoeling om eerst te bedenken wat er gemaakt moet worden, voordat gestart wordt met een systeem bouwen. Mijn grootste ergernis zijn mensen – bijv. product owners – die werken op een manier van “Bouw maar wat dan vertel ik aan het eind van de sprint wel dat ik dat niet wil, en dan bouw je maar weer wat anders.”.
Hoe kun je als teamlid zorgen voor continue verbetering? Daarvoor heb ik de volgende welgemeende tip:
Tijdens elke retrospective bespreek je met je team één principe van de twaalf die in het Agile Manifesto beschreven zijn. Samen met je team onderzoek je wat het betreffende principe betekent voor de manier waarop jullie werken, en of je daar op een goede manier mee om gaat. Vrijwel altijd stuit je dan op verbetermogelijkheden. Kernwoorden uit de principes zijn: value, change, frequently, collaboration, motivation, conversation, progress, pace, excellence, simplicity, self-organizing en improvement. Samen geeft dit al mooi de Agile mindset weer.
Als je sprints van twee weken hebt, en elke sprint één van de twaalf principes bespreekt, heb je in een half jaar alle principes van het Agile Manifesto behandeld. En ik durf de stelling wel aan dat je dan al heel snel het best geïnformeerde Agile team uit jouw wijde omgeving bent. Dan zullen jij en je team daadwerkelijk Agile Denken, Agile Doen en Agile Zijn!
Veel succes met Agile testen!
Rik Marselis