Agility

Op een vrij warme zomerochtend in 2008 stonden we voor het eerst in een kringetje een tikje onwennig voor het whiteboard. We gingen zoals vele bedrijven starten met de invoering van Scrum en we hadden besloten om dit volgens het boekje te doen. De uitleg van Scrum was geweest en dit was dan onze eerste praktijkoefening. Met zichtbare weerstand stonden mijn collega’s verslag uit te brengen naar mij, in plaats van naar elkaar, want ik was toch degene die met dit idiote idee op de proppen was gekomen. Verzoekjes als “Kunnen we niet gewoon blijven zitten?” gaven aan dat we nog aan het zoeken waren naar de manier waarop Scrum pastte in onze bedrijfscultuur.

Scrum is voor ons een handig opstapje geweest om een aantal gewoontes in het werk te doorbreken en de mindset te veranderen. Een aantal rituelen in Scrum werden echter al snel overbodig maar hebben wel het fundament neergezet voor een wendbare houding in de organisatie ofwel het veelgebruikte 'agility'. Een term die in software ontwikkeling niet meer weg te denken is.

Wat me in de markt en ook op LinkedIn erg opvalt is dat Agility als containerbegrip wordt gebruikt met een grote verscheidenheid aan implementaties. Voor mij is Agility dat je ontwikkelorganisatie zo is ingericht dat je snel mee kan bewegen met de behoefte van je klant en de gebruiker. Dit gaat dan ook veel breder dan processen onder de ontwikkelaars. Noodzakelijk om echt Agile te kunnen acteren is volgens mij:

• Een dev-ops structuur. De ontwikkelaars zijn zelf verantwoordelijk voor de operatie waardoor ze zelf uit bed worden gebeld als de software niet robuust is.
• Een zo kort mogelijke release cycle (bij voorkeur continuous) waardoor kleine wensen die een groot verschil kunnen maken, direct doorgevoerd kunnen worden.
• Geen volgepropte planning met langlopende projecten en een hoge commitment.
• Product Owners met echte (technische) kennis van de inhoud, geen backlog beheerders die de stories kunnen uitwerken en op volgorde zetten.
• Korte lijntjes met de gebruikers en regelmatig contact tussen de developers en gebruikers. Slack heeft hierin voor ons een grote rol gespeeld!
• Een platte productorganisatie waarbij besluiten direct genomen kunnen worden en fouten maken niet wordt afgestraft.
• Een product framework waar je wijzigingen in kan én durft te maken. Dit vereist schone leesbare code, geen complexe constructies en automatische tests die het zelfvertrouwen versterken.

Er is echter één eigenschap die de Agility naar een hoger niveau brengt. En het vreemde is dat juist deze eigenschap in de IT vaak ondergeschoven is. Voor mij is dit ‘domeinkennis’! Zodra de teamleden beschikken over de voldoende kennis van de processen van de gebruikers en de eigenaardigheden van de sector, dan worden veranderingen ineens een stuk makkelijker. Eenvoudige beslissingen hoeven niet meer via de product eigenaren of analisten te worden gespeeld maar kunnen direct en zelfstandig worden gemaakt. Ook de broncode van een project wordt leesbaarder en minder complex omdat een developer met domeinkennis in staat is de uitzonderingen te scheiden van het basisproces.

Het investeren in een (vast) team developers met voldoende domeinkennis is cruciaal. Wat mij betreft is het de combinatie van sector- en technische kennis die een team echt agile maakt.