Agile Scrum is voor mij geen verzameling ceremonies die je volgens een vast schema moet uitvoeren. Het is vooral een manier om softwareontwikkeling behapbaar te maken door werk op te delen, regelmatig te toetsen of je nog het juiste probleem oplost en als team verantwoordelijkheid te nemen voor het resultaat.
Ik werk inmiddels meerdere jaren binnen Agile Scrum teams en heb daarnaast mijn Professional Scrum Master certificering behaald. In mijn werk heb ik Scrum gebruikt binnen verschillende soorten organisaties, van SaaS en consultancy tot omgevingen zoals Port of Amsterdam en ANWB.
Wat ik belangrijk vind binnen Agile Scrum
Voor mij werkt Scrum alleen wanneer het team begrijpt waarom bepaalde onderdelen bestaan.
Een Daily is niet bedoeld om Jira voor te lezen. Een refinement is niet bedoeld om zoveel mogelijk tickets van punten te voorzien. En een retrospective heeft weinig waarde wanneer dezelfde problemen iedere sprint opnieuw terugkomen.
De kracht zit voor mij juist in een paar eenvoudige principes:
Begrijp eerst wat je probeert op te lossen
Maak werk klein genoeg om daadwerkelijk voortgang te kunnen zien
Zorg dat verantwoordelijkheid bij het team ligt
Maak problemen vroeg zichtbaar
Durf gedurende het proces bij te sturen
Houd processen zo eenvoudig mogelijk
Scrum moet het team ondersteunen. Het team moet niet bestaan om Scrum correct uit te voeren.
Eerst begrijpen, daarna bouwen
Een van de belangrijkste onderdelen van Agile werken zit voor mij nog vóórdat iemand begint met programmeren.
Wat proberen we eigenlijk op te lossen?
Als developer vind ik het belangrijk om niet alleen een ticket te implementeren, maar ook te begrijpen waarom iets nodig is. Soms blijkt tijdens een refinement dat een technisch complexe oplossing helemaal niet nodig is wanneer je het probleem achter de requirement goed begrijpt.
Dat sluit sterk aan op hoe ik naar backend engineering kijk. Simpliciteit ontstaat meestal niet door minder na te denken, maar juist door eerst voldoende te begrijpen.
Eigenaarschap binnen het team
Scrum werkt naar mijn mening het beste wanneer developers niet alleen verantwoordelijk zijn voor code, maar voor het resultaat van het product.
Dat betekent dat ik mij ook bemoei met architectuur, requirements, performance, monitoring, technische schuld en soms zelfs de vraag of een feature überhaupt gebouwd moet worden.
Binnen mijn recente werk heb ik regelmatig architecturale verantwoordelijkheid genomen en technische knelpunten proactief bespreekbaar gemaakt. Bij ANWB betekende dat bijvoorbeeld dat ik verder keek dan individuele stories en veranderingen doorvoerde in de achterliggende architectuur en datastromen.
Dat is voor mij Agile werken: niet wachten totdat iemand een oplossing voorschrijft, maar samen verantwoordelijkheid nemen voor wat het team oplevert.
Scrum zonder dogma
Ik ben voorstander van Scrum, maar niet van Scrum om Scrum.
Niet ieder team heeft dezelfde hoeveelheid refinement nodig. Niet iedere Daily hoeft exact vijftien minuten te duren. En een sprintplanning van drie uur is niet automatisch beter dan eentje van een uur.
Wanneer een proces geen waarde meer toevoegt, moet je durven vragen waarom je het nog doet.
Dat betekent niet dat structuur onbelangrijk is. Juist het tegenovergestelde. Goede structuur maakt duidelijk waar vrijheid mogelijk is.
Mijn voorkeur is daarom simpel: behoud de onderdelen die samenwerking, voorspelbaarheid en transparantie verbeteren en verwijder onnodige proceslast.
Techniek en Agile moeten elkaar versterken
Softwareontwikkeling laat zich niet volledig voorspellen.
Tijdens het bouwen ontdek je nieuwe informatie. Een integratie blijkt complexer. Een architecturale keuze heeft andere gevolgen dan verwacht. Of een technisch probleem blijkt structureler dan een individuele story.
Een goed Agile team creëert ruimte om daarmee om te gaan.
Daarom vind ik technische onderwerpen zoals refactoring, technische schuld, observability en architectuur onderdeel van productontwikkeling. Ze horen niet thuis op een verborgen backlog die alleen wordt opgepakt wanneer er toevallig tijd overblijft.
Wanneer je software duurzaam wilt ontwikkelen, moet onderhoud onderdeel zijn van het normale proces.
Samen vooruit
Mijn favoriete Agile teams zijn teams waarin developers elkaar inhoudelijk uitdagen.
Niet om gelijk te krijgen, maar om samen tot een betere oplossing te komen.
Ik heb tijdens mijn carrière binnen verschillende Agile teams gewerkt en daarnaast een business course aan Ohio University gevolgd rond High Performance Teaming en Agile samenwerking. Die combinatie heeft mijn beeld vooral bevestigd: sterke teams ontstaan niet door processen alleen. Ze ontstaan wanneer mensen verantwoordelijkheid nemen, kennis delen en elkaar voldoende vertrouwen om verschillende inzichten uit te spreken.
Scrum kan daar een goede structuur voor bieden.
Maar uiteindelijk zijn het de mensen die bepalen of het werkt.
Mijn kijk op Agile Scrum
Voor mij draait Agile Scrum uiteindelijk om drie dingen: begrijpen, samenwerken en aanpassen.
Begrijpen voordat je bouwt.
Samenwerken in plaats van werk over de schutting gooien.
En aanpassen wanneer nieuwe informatie laat zien dat je oorspronkelijke plan niet meer de beste route is.
Wanneer Scrum daarin helpt, is het waardevol.
Wanneer Scrum alleen nog bestaat uit meetings, tickets en velocity grafieken, ben je naar mijn mening het belangrijkste onderdeel van Agile kwijtgeraakt.