Je agile scrumteam kan het niet alleen

Ok, dus nu heb je een agile scrum team. Good for you! Maar helaas, je bent er nog niet. Het besluit om agile software development in te zetten is slechts een eerste stap in de betrokkenheid van je (gehele) organisatie bij digitale projecten.

Zo bleek uit een onderzoek naar agile werken van Collab.net, dat ‘algehele weerstand binnen de organisatie tegen verandering’ een belangrijke oorzaak is voor het falen van agile projecten. Wil je project echt een kans maken, dan moet de rest van de organisatie ook bereid zijn mee te bewegen.

Mijn ervaring is dat bedrijven niet zozeer huiverig zijn voor het invoeren van agile werken bij softwareprojecten. Waar het spaak loopt is dat ze denken dat het agile/scrum ontwikkelingsproces op zichzelf staat. Deze manier van werken heeft echter impact op de gehele organisatie. Agile betekent niet voor niets wendbaar – er is een grote mate van flexibiliteit nodig om deze werkwijze succesvol toe te passen en niet alleen bij het team zelf. Je gaat ook niet met een Formule 1-auto in een woonwijk rondjes rijden. Je moet zorgen voor de juiste omgeving en randvoorwaarden. Dat vergt bij veel bedrijven een cultuurverandering.

Nulmeting dicteert niet het vervolg van het project

Aan het begin van een project of bij de start van een team worden de randvoorwaarden bepaald die nodig zijn om tot het gewenste resultaat te komen. Afspraken met de rest van de organisatie vallen hier ook onder. Het heeft geen zin om die in een contract vast te leggen; het is een nulmeting die nadrukkelijk niet in steen gebeiteld kan worden. Retrospectives en andere tussentijdse ijkpunten zijn juist bedoeld om te evalueren, bij te sturen en in de gaten te houden waar het project naartoe gaat en moet. Afspraken met de rest van de organisatie worden net zo goed geëvalueerd als afspraken die binnen het team zijn gemaakt, door te bekijken hoeveel sprints er nodig zijn, hoe de teams eruit moeten zien, et cetera.

Je kunt van tevoren wel bedenken dat een sprint twee weken zal duren maar als in de praktijk blijkt dat drie weken beter is voor het verloop van het project, dan is een aanpassing noodzakelijk. Dat heeft niet alleen gevolgen voor het team zelf maar ook voor de release cycli, testcycli, reviews (een combinatie van een demo en een toelichting over hoeveel er opgeleverd is en wat er nog gaat komen), rapportages en facturaties.

Werk anders verdelen heeft gevolgen voor de hele organisatie

Een praktijkvoorbeeld: bij een bedrijf werden twee teams ingezet, één voor development en één voor onderhoud en kleine doorontwikkelingen. Algauw bleek dat het onderhoudsteam de uitdaging begon te missen. Scrumteams hebben die uitdaging juist nodig, zeker gezien de huidige arbeidsmarkt waar het nóg belangrijker is om je medewerkers tevreden te houden.

Dus werd besloten om het werk anders te verdelen, waarbij elk team een stuk innovatie en een gedeelte maintenance te doen kreeg. Dit had echter impact op de velocity van het ontwikkelingsprogramma, budgetverdelingen, de administratie en de taakverdeling van de product owners. Maar omdat het van essentieel belang was voor het succes van het project, moest de rest van het bedrijf zich wel aanpassen.

Ook dit soort flexibiliteit in de rest van het bedrijf is geheel volgens het agile manifest, waarin staat dat contracten belangrijk zijn, maar goed samenwerken nog belangrijker. Het doel is om met zijn allen, in een open cultuur waarin alles ter discussie mag worden gesteld, de beste software te bouwen. Bedrijven die bereid zijn de valse zekerheid van contractuele afspraken in te ruilen voor flexibiliteit, zijn een flinke stap dichter bij succesvolle agile software development.