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
In onze vorige blogs zijn we ingegaan op de valkuilen van agile-BI voor starters met SCRUM en de effecten van SCRUM op de rollen en verantwoordelijkheden. Deze keer bespreken we een aantal mooie bijeffecten van SCRUM voor de teamleden.
Team spirit
In het begin worden de dagelijkse stand-ups niet door iedereen even serieus genomen. Onder het mom van 'tijdverspilling' worden opmerkingen geplaatst als: ‘ik weet toch wel wat ik doe’. In werkelijkheid blijkt dit vaak door onzekerheid veroorzaakt te zijn, onzekerheid over het melden van problemen. Sommige teamleden zijn door de jaren heen zo gewend geraakt aan individueel ontwikkelen, dat ze gaandeweg een 'einzelgänger' zijn geworden. Met als gevolg dat aan een optredend probleem zo lang wordt geprutst als onze eenzame ontwikkelaar nodig acht. Risico’s: tijdverspilling, suboptimale oplossingen en eenzame frustratie.
Een goed lopend SCRUM-team voelt een gezamenlijke verantwoordelijkheid voor het halen van de sprint (zie mijn vorige blog over het kunnen committeren aan een sprint). Hierdoor ontstaat er een natuurlijke interesse in elkaars werk. Al vrij snel zullen teamleden elkaar actief gaan uithoren, gaan doorvragen over iets waar iemand mee zit en bekijken hoe het team daarbij kan helpen. Beetje bij beetje ontstaat zo op natuurlijke wijze een hechter team. Dat effect kan nog wat worden versterkt of versneld door ‘pair programming’ (2 mensen achter 1 computer), afkomstig uit XP ('extreme programming'). Dit lijkt misschien inefficient, maar het betaalt zich snel terug in de vorm van het sneller oplossen van problemen, het beter afwegen van oplossingsalternatieven en op termijn een betere uitwisselbaarheid van teamleden (‘alle teamleden kunnen alle taken oppakken’). Hierdoor wordt uiteindelijk een verhoogde productiviteit bereikt.
‘Pair programming’ doen we overigens niet altijd, maar in ieder geval wel bij de bouw van lastige of risicovolle stukken software. De stukken software die we niet middels pair programming ontwikkelen worden wél altijd minimaal door één ander teamlid nagekeken. Ook dit lijkt een kostbare bezigheid, maar onze ervaring is dat het de kwaliteit dusdanig verhoogd dat het de inspanning meer dan waard is. Bovendien wordt men op deze manier ‘gedwongen’ om software-code te schrijven die door alle teamleden te begrijpen is.
Naast pair programming gebruiken wij bij onze BI-projecten ook het principe van ‘iedere ontwikkelaar heeft gelijke rechten over alle programmacode’. Dit is de praktische ondersteuning bij het principe dat elk teamlid verantwoordelijk is voor de kwaliteit van het eindresultaat, waarmee bijna automatisch bij de teamleden de behoefte ontstaat om te snappen wat er gebeurd.
Introverte persoonlijkheden
Bij het introduceren van SCRUM hoort onvermijdelijk ook het starten met SCRUM-poker. ‘We gaan pokeren’. Dat klinkt ook leuk; een spel doen op het werk. Bij SCRUM-poker worden de kaarten ‘blind’ neergelegd en gaan de ontwikkelaars met de hoogste en de laagste puntenschatting vervolgens als eerste met elkaar in discussie. Hierdoor krijgen de meer introverte ontwikkelaars binnen de groep opeens een mond. Dit is in het begin ongetwijfeld eng voor ze, maar het blijkt wel steeds beter te gaan naarmate ze meer en meer gehoord worden door de rest van het team. Naarmate de ervaring van het team stijgt en de teamleden goed luisteren naar elkaars argumenten, worden de inschattingen steeds accurater en de oplossingsideeën en uiteindelijke software steeds beter. Daarnaast is dit ook goed voor de teamspirit: door in een vroeg stadium de neuzen al één kant op te krijgen, voorkom je later verrassingen.
Van specialisten naar generalisten
Een SCRUM-team dat uit louter specialisten bestaat, die elkaars werk niet kunnen uitvoeren, is niet effectief. Om te zorgen dat je geen single-points of failure gaat creëren, moet je ervoor zorgen dat iedereen elke story op kan pakken en dus overal kennis van heeft. Specialisatie van SCRUM rollen lijkt vaak optimaal, maar in de praktijk valt dit tegen omdat niet elk specialisme op het juiste moment gevraagd wordt, hetgeen al snel tot een lagere productiviteit leidt.
Dit zijn natuurlijk slechts een beperkt aantal positieve, bijkomende effecten van het werken met SCRUM. Gewoon beginnen, en dan op weg naar een team van positieve, betrokken en extraverte generalisten. De aanhouder wint. Download de gratis SCRUM-StarterKit met handige checklists en templates. Meer weten van Business Intelligence vanuit het perspectief van de manager? Lees dan onderstaand ebook.
Dit blogartikel is geschreven door Jorg Vreeswijk