Wij hebben voor de scrum-methodiek gekozen om de opgedane kennis uit de trainingen en kennissessie’s in de praktijk te toetsen en de praktische uitdagingen van deze methode te ondervinden. En vanaf het moment dat wij de theorie in de praktijk aan het toepassen zijn, zijn de onderlinge discussies erg interessant geworden!

 

Aan de start van het project moest er een rolverdeling komen, werkafspraken moesten worden gemaakt en backlogs worden gevuld. Kortom, de methode van het project moest worden vastgesteld, en die wilde wij zo veel mogelijk in lijn houden met de scrum-principes. Bij iedere afspraak die wij echter probeerde te maken ontstond er een discussie of wij de richtlijnen van scrum moesten hanteren, of dat we een oplossing kozen die op dat moment het meest praktisch leek - die mogelijk wel sterk afweek van de scrum-principes. 

 

Enerzijds wil je namelijk die principes en richtlijnen goed opvolgen, want je hoort en ziet op verschillende plekken de successen van deze methode en leunt daarmee op de best-practice van voorgangers. Anderzijds wil je er ook geen doel op zich van maken. Zelf heb ik ook een aantal van deze best-practices mogen ervaren bij klanten, en weet voor mijzelf welke onderdelen mij wel of minder goed bevallen. Ik weet bijvoorbeeld hoeveel energie een team kan krijgen van een strak georganiseerde stand-up zoals scrum die ook voorschrijft, maar ik heb ook gezien wat voor een negatief effect een stand-up kan hebben als er te veel inhoud wordt besproken en het team daarmee zijn momentum verliest. Een ander voorbeeld wat ik als waardevol heb ervaren is dat iedereen aan het begin van de dag uitspreekt wat diegene verwacht op te leveren aan het einde van de dag. Hiermee manage je elkaars verwachtingen maar hierdoor creëer je ook commitment. 

Dat scrum geen doel op zich moet zijn, vind ik een belangrijk standpunt. Het is goed om gebruik te maken van de ervaringen van anderen en jezelf open te stellen voor iets nieuws. Maar ik ben ervan overtuigd dat deze methode pas echt tot zijn recht komt als je constant de afweging blijft maken of theoretische voorschriften wel of niet bruikbaar zijn voor je project, en dus niet blindelings de theorie volgt. Het blijft tenslotte een guideline. Iedere werkmethode kent zo zijn randvoorwaarden, en zo kent scrum die ook. Wanneer een project daar niet aan voldoet, bijvoorbeeld als het project geen product-owner met mandaat heeft, het projectteam niet op dezelfde dagen beschikbaar is of wanneer het op te leveren product gefixeerd is, dan moet je je afvragen of scrum wel zo geschikt is en of een klassieke waterval methode niet beter is. Bepaal je doel en kies vervolgens je middel.

 

Juist deze afweging maakt het project binnen InnoviQ zo interessant. Gaandeweg leren we de do’s en don’ts van het ‘scrummen’ en ervaren we onder welke voorwaarden bepaalde onderdelen van de methode juist wel of niet goed werken. Ik ben tot nu toe dan ook erg enthousiast over de methode. Leuk ook om te constateren dat gemeenten hier steeds meer mee aan het experimenteren zijn.