Scrum resulteerde in een continue flow van energie

06-04-2020

Hoe het scrummen van een dashboard heeft uitgepakt bij de gemeente Enschede

“We zijn verbaasd wat je in vier halve dagen met behulp van scrum allemaal kunt bereiken. We hebben alles af gekregen wat klaar moest zijn en zelfs nog tijd overgehouden voor een extra kwaliteitscontrole.” Ruud Kousman is zeer enthousiast over het nog lopende scrumpilot waarvan de eerste sprint net achter de rug is. Hij en Rob Melenhorst hebben voor het cluster Dienstverlening binnen de gemeente Enschede een proef gedraaid met scrum. Het ging hierbij om de ontwikkeling van een dashboard dat vanaf april actueel inzicht moet geven in de prestaties van de gemeente. Tegelijk met dit project hebben Ruud en Rob ook hun certificaat tot scrum master in de praktijk behaald.

Aanloop naar scrumpilot

Dat de resultaten zo positief zijn, is allerminst vanzelfsprekend. Het gebruik van scrum heeft namelijk een aanloop van ruim twee jaar gekend. Twee jaar geleden is al de keuze gemaakt om Henk Aalders van JE Consultancy in te schakelen voor de introductie van scrum bij de gemeente Enschede. Dit heeft mede plaatsgevonden op initiatief van Hans van Riele, clustermanager Finance & Control. Hij vertelt dat hij al langer bekend was met scrum en voor Henk als begeleider bij het traject heeft gekozen op basis van het goede gevoel dat hij bij Henk had als persoon en de prettige ervaring met Egbert Leppink, die op dat moment voor JE Consultancy in Enschede werkzaam was.

Na het opleiden van zes geïnteresseerde personen, waaronder twee scrum masters, had de gemeente Enschede twee keer eerder een project voor ogen om mee te gaan scrummen. Beide keren bleek echter tijdens het opstellen van de productbacklog, waarin staat beschreven wat het op te leveren eindproduct is en de benodigde stappen en middelen om hiertoe te komen, dat er onvoldoende capaciteit vrijgemaakt kon worden binnen de organisatie. Dit had voor de twee scrum masters echter wel als grote voordeel dat ze in die tijd flink konden oefenen met het uitoefenen van de rol van de scrummaster, waarbij je onder andere de productowner ondersteunt. Ze werden daarbij uitgebreid ondersteund en gecoacht door de scrumcoach, die de droge theorie op een prettige wijze kon omzetten naar een heldere en praktische toepassing. Dit was precies wat Ruud en Rob nodig hadden om een goede productbacklog te kunnen maken.

Gebrek aan goede managementinformatie

Toen er dan eindelijk wel voldoende capaciteit kon worden vrijgemaakt, kon er daadwerkelijk volgens de scrummethodiek gewerkt worden aan het ontwikkelen van een dashboard. De opdracht die het hoofd van het cluster Dienstverlening aan de organisatie had gegeven voldeed aan alle randvoorwaarden voor een succesvol scrumtraject, zo laat Hans weten: “Er was een productowner met een helder beeld van wat hij wilde hebben en een snel op te leveren digitaal product met een multidisciplinair karakter.” Wat Rob betreft was het verschil met de eerdere projecten dat er nu een sterkere en duidelijkere wil bestond bij de opdrachtgever om tot een nieuw product te komen.

Reinier Kreeft, die sinds 1 april vorig jaar aan de slag is gegaan als clustermanager Dienstverlening en zelf uit de IT-wereld komt, laat weten dat hij als opdrachtgever en primaire klant van het eindproduct (productowner), behoefte had aan meer inzicht in de prestaties van zijn afdeling. “Er zijn weliswaar veel gegevens beschikbaar in de organisatie, maar die geven mij niet de informatie die ik nodig heb, omdat ze niet direct gekoppeld zijn aan de kritische prestatie-indicatoren van mijn afdeling. Het inzicht in goede managementinformatie ontbreekt dus.”

Het dashboard waar momenteel aan wordt gewerkt, gaat in de eerste plaats een sturingsmiddel zijn, maar daarnaast ook een informatiebron voor de buitenwereld. Daarnaast zal het intern ook fungeren als verantwoordingsinstrument. Vanuit de sturingskant bekeken is het daarbij ook van belang dat de informatie actueel is. Reinier ziet het dashboard voor zich als een visuele weergave van de hoofdcategorieën waarbij je via de producten kunt doorklikken naar subproducten, uitgesplitst naar de verschillende communicatiekanalen en afgezet tegen de tijd en/of het aantal inwoners.

Concept dashboard

In april dient het dashboard te worden opgeleverd en inmiddels zijn er drie sprints doorlopen. Tijdens de 1e sprint is vooral aandacht besteed aan het maken van procesbeschrijvingen, een heldere definitievorming en het bepalen van geschikte informatiebronnen. Tijdens de sprints daarna is gewerkt aan het opzetten van een concept dashboard voor een aantal producten (o.a. voor rijbewijzen, reisdocumenten en klachten), waarbij is getoetst of voldaan is aan de acceptatiecriteria van de productowner, de gewenste mate van actualiteit van de gegevens en de inhoud en vorm van de rapportages. Dit leidde tot tevredenheid bij de productowner. In de laatste twee sprints zal de focus meer komen te liggen op de lay-out van het dashboard, die vervolgens na realisatie nog zal worden voorgelegd aan een verificatiegroep.

Kwaliteit vereist betrouwbare data

Uit alle sprints is gebleken dat de kwaliteit van de inhoud van de dashboard en rapportages valt of staat met de betrouwbaarheid van de aangeleverde data. Zo is gebleken dat bepaalde processen niet over eenduidige gegevens beschikken en daarmee onvoldoende betrouwbaar zijn als informatiebron. Ook kwam uit een controle naar voren dat het totaal van de aanvragen per kanaal (balie en digitaal) niet gelijk was aan het totaal aantal aanvragen. Daarnaast bleek dat de IT-afdeling maar moeilijk voldoende capaciteit kon vrijmaken en het lastig vond om volgens de scrum-methode te werken. Zij zijn gewend aan de projectmatige aanpak van Prince2, waarbij in geval van knelpunten helemaal wordt teruggegaan naar het begin van het project, terwijl bij scrum knelpunten direct worden opgelost en de sprint doorloopt.

Energieflow en hoge ontwikkelsnelheid

De twee scrum masters laten weten dat ze het scrumtraject gezamenlijk trekken. Hierbij wordt gewerkt met korte cycli (sprints) die bestaan uit:
• een sprintplanning, waarbij het sprintdoel wordt bepaald;
• een daily scrum, waarbij gemonitord wordt of het sprintdoel gehaald wordt;
• een sprintreview, waarbij feedback wordt opgehaald van het gemaakte (deel)-product(en) om een volgende sprint te kunnen starten;
• en een retrospective, waarbij het proces van samenwerken in het scrumteam wordt geëvalueerd.

Rob en Ruud zijn tijdens de eerste sprint allebei bij de ’daily ’s’ aanwezig geweest. Rob keek vooral naar de vorderingen vanuit de wensen van de productowner en Ruud focuste zich vooral op het procesmatige verloop van de sprints.

Wat terugkijkend voor de scrum masters het meest bijzondere was en daarmee een van de grootste meerwaarde is van scrum, is dat de teamleden tijdens de sprints zo intensief aan de slag waren dat er vanuit een soort flow van positieve energie automatisch een goede onderlinge samenwerking ontstond. “Scrum heeft gezorgd voor een continue flow van energie en een enorme ontwikkelsnelheid. Dit was mede dankzij het visuele plaatje van de voortgang.”, aldus Ruud. Deze energie was tot nu toe tijdens alle sprints aanwezig.

Ruud merkt verder nog op dat de aan- en bijsturing vanuit zijn kant tijdens de 2e en 3e sprint is duidelijk is afgenomen ten op zichtte van de 1e sprint: “Op een gegeven moment draait het gewoon gesmeerd en kun je het team zijn gang laten gaan.” Enige aanpassing ten op zichtte van de 1e sprint is het werken in een eigen ruimte, wat als een aangename verbetering is ervaren door iedereen.

Brenda Grunder, lid van het ontwikkelteam en nog niet eerder bekend met scrum, bevestigt het door Ruud geschetste beeld: “Het opstarten van een sprint kostte wat tijd, maar daarna konden we gezamenlijk heel snel stappen maken zonder tussendoor tijd te verliezen”. Volgens haar is de effectiviteit grotendeels te danken aan het feit dat de juiste mensen op hetzelfde moment aan tafel zaten, met een eensgezind doel en gedeelde kennis van de voor de ontwikkeling van het dashboard te gebruiken software.

Belang van gedegen voorbereiding

Een goede productbacklog heeft volgens de scrum masters ook bijgedragen aan het slagen van de eerst sprint. Rob zegt hierover: “Een productbacklog is vooral belangrijk voor het geven van inhoud aan de technische droom die er bestaat. Dit betekent een heldere definitie van wat er opgeleverd moet worden en eveneens heldere acceptatiecriteria. Als je dit niet helder hebt, krijg je onderweg onvermijdelijk discussie.” De heldere productbacklog heeft er in Enschede voor gezorgd dat de onderlinge verwachtingen binnen de organisatie van begin af aan duidelijk waren waardoor zich tijdens het scrummen nauwelijks verrassingen hebben voorgedaan.

Enige nadeel van de gehanteerde sprintplanning is volgens de scrum masters dat de sprints dusdanig intensief bleken, dat het lastig was voor de teamleden om de rest van de dag nog productief aan de gang te gaan met reguliere werkzaamheden. Daarom is vanaf de 2e sprint gekozen voor vier halve scrumdagen in één week maar voor twee opeenvolgende weken met ieder 2 halve scrumdagen.