Dit artikel is onderdeel van de themareeks BI & Techniek, bedoeld om de meer technische aspecten van BI voor het voetlicht te krijgen. Het is geschreven voor project-managers en ontwikkelaars binnen de BI, die zich afvragen hoe agile zich in de BI-praktijk staande houdt.
SCRUM
Wij zijn nu alweer een flink aantal jaren succesvol met de SCRUM methode bezig. Daarmee voorkomen we de inmiddels welbekende problemen die we vaak in BI-omgevingen tegenkomen:
- niet op tijd of buiten budget opleveren;
- niet leveren wat gewenst is;
- onduidelijkheid over wie welke verantwoordelijkheid heeft (of niet heeft);
- teamleden die single points of faillure blijken te zijn etc.
Met vaak als resultaat; een ontevreden klant, gestreste medewerkers en halve eindproducten. Overgaan op SCRUM biedt vaak uitkomst in dit soort situaties, maar het opzetten van een agile ontwikkelproces is best een lastig traject en kent een aantal veelvoorkomende valkuilen.
Opstartproblemen
Bedrijven die met SCRUM beginnen, haken na een jaar of half jaar al snel weer af met de conclusie: 'SCRUM werkt binnen onze organisatie niet'. Nader bekeken, blijkt de reden echter meestal een halfslachtige implementatie van SCRUM te zijn. Dat is geheel begrijpelijk, want starten met SCRUM is echt een leertraject. Hieronder enkele opmerkingen die in de praktijk vaak worden gemaakt door beginnende bedrijven;
“We introduceerden het welbekende SCRUM-bord, maakten een backlog en noemden een overleg opeens een sprintplanning.”
“Punten leek overbodig, een punt staat toch voor een aantal uur?”
“Onze stand-up’s werden al snel sit-down’s omdat ze wel drie uur duurden, en drie keer in de week overslaan of naar een later dagdeel verschuiven was ook geen probleem.”
“Onze teamleden pakten meestal hun eigen story op.”
“Wanneer was iets ook alweer 'done'?”
“Eén van de stakeholders benoemden we tot de productowner, maar omdat die ook niet wist wat dat inhield, pakte de SCRUM-master wel wat van die extra taken op.”
Het resultaat mag duidelijk zijn: weinig verandering en veel frustratie. Op dat moment is de kans groot dat een bedrijf in een dergelijke situatie de conclusie trekt dat de methode SCRUM (of in bredere zin agile) niet werkt.
“We hebben immers erg ons best gedaan, toch? Het ligt al jaren aan de methode. Prince2, RUP en watervallen zijn toch ook altijd al waardeloos geweest!”
Vallen en opstaan
Gelukkig zien veel bedrijven ook in dat de methode meestal niet het probleem is, maar de wijze waarop de methode wordt geïmplementeerd. Als een bedrijf het vertrouwen van alle betrokkenen nog niet heeft verloren, is een nieuwe doorstart heel goed mogelijk. Een training voor de SCRUM-teamleden en betrokkenheid vanuit de business zijn onontbeerlijk. Niet zozeer om de SCRUM-theorie er in te stampen - die kun je ook makkelijk uit een boekje halen -, maar vooral om te begrijpen dat het om een andere manier van denken, organiseren en met elkaar omgaan gaat (kijk bijvoorbeeld eens in het Agile Manifesto).
Na de training is het handig om bij onervaren bedrijven, in eerste instantie zoveel mogelijk, de door SCRUM voorgestelde onderdelen te implementeren. Essentieel om te hebben bij de start zijn:
SCRUM-implementatie
Agile BI (met SCRUM) werken is namelijk niet alleen 'een methode toepassen', maar het is vooral een andere manier van denken en werken. Niet alleen voor het team, maar juist ook voor ‘de business’. Opeens moeten zij óók mee in die constante stroom van ontwikkeling, testen, bekijken of dit was wat ze bedoelden, aanpassen, verbeteren etc. Het idee hierachter laten vallen blijkt vaak makkelijker dan het ook daadwerkelijk uitvoeren. Wat hierbij enorm helpt zijn duidelijke rollen en verantwoordelijkheden en het voortdurend daarop blijven wijzen (niet verslappen!).
Een zegen voor een succesvolle SCRUM-implementatie is:
een enthousiast team dat echt probeert er wat moois van te maken, elke dag (op tijd!) tien minuten tot maximaal een kwartier naar het bord toekomt, onderling deelt en ook enthousiast blijft ondanks de onvermijdelijke valpartijen.
Word geen SCRUMdamentalist
Dat in eerste instantie alles wordt opgepakt volgens het boekje, wil niet zeggen dat men precies zo blijft werken. Zoals Sander Hoogendoorn in enkele van zijn blogs over 'SCRUMdamentalists, pokemon-trainer' en het 'institutionaliseren van agile' beschrijft, is het zaak om juist achterom te kunnen kijken en aan te kunnen passen naar de situatie waar je in zit. Daarom is het review-moment zo ontzettend belangrijk. Dat is het moment dat een bedrijf leert: durven kijken naar gemaakte fouten en expliciet stilstaan bij behaalde successen. Na verloop van tijd zien we vaak dat het proces is aangepast, maar dan wel met een vaste basis. De meeste sprints worden gehaald en zo niet dan is het altijd duidelijk waarom die niet is gehaald. Maar belangrijker: de teams leveren waarde. Dit komt niet alleen doordat de teams weten wat ze doen, maar ook omdat de stakeholders meegaan in de flow, zij (en de ontwikkelaars) zijn niet meer ‘bang’. Fouten maken mag, want bijsturen kan, of eigenlijk misschien zelfs moet, want we werken ‘agile’.
Download hieronder de gratis SCRUM-StarterKit met handige checklists en templates:
Dit blogartikel is geschreven door Jorg Vreeswijk