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.
Succesvolle, ervaren teams hebben geen probleem met het uitvoeren van hun ‘task breakdown’. Veel startende teams hebben hier echter wel moeite mee en dat is niet zo raar. Zoals zo vaak in ‘agile werken’, is het ook hier weer de kunst om de juiste balans te vinden. Zeker in BI hebben we wel eens de neiging om eeuwig te discussiëren en te veel vooraf te willen doen en uit te willen pluizen. Op die manier zijn we stiekem ouderwets aan het watervallen, leveren we heel lang geen waarde op en stoppen we potentieel veel moeite in zaken die we wellicht nooit gaan uitvoeren. Aan de andere kant schieten we soms door, doen we zo goed als niets vooraf en worden we onvoorspelbaar. Hoewel het per situatie verschilt, zie ik binnen BI en datawarehousing de volgende drie stappen doorgaans als een goede leidraad bij de ‘task breakdown’. De aanpak die ik hier beschrijf vloeit uit eerdere eigen ervaringen binnen verschillende Agile BI-projecten.
Stap 1: Maak taken klein genoeg voor een goede inschatting
Maar wat is een goede inschatting? Dat hangt van veel factoren af en eigenlijk voornamelijk van de vraag in hoeverre een team mag falen. Of misschien beter gezegd…, hoe goed is een team in het falen met beperkte schade (non-deadly failure). Het gaat te ver voor dit blog om hier dieper op in te gaan, maar laten we stellen dat het een goed teken is als het team over het algemeen oplevert wat het heeft beloofd. Met andere woorden; het team is voorspelbaar.
Teams worden voorspelbaar door onder andere het ‘refinen’ van de opdrachten (stories) en het gebruik van planning-poker voor de inschattingen. Refinement van de stories op de backlog moet een constante activiteit van het team zijn. Tijdens het refinen en inschatten praten de teamleden vaak al over bepaalde ‘hoog-over’ taken, en dat is nu precies van belang in deze stap. Deze taken – of misschien in dit vroege stadium de ‘hoog-over stappen’ – hebben teamleden nodig om de opdracht goed te begrijpen en voor zich te zien. Het is voor teams heel natuurlijk om hier al over te praten en te discussiëren. Of voor sommige opdrachten zelfs al een standaardlijstje te maken. Het is vaak alleen nog maar zaak om dit geordend terug te laten komen in de refinement sessie. En als we ze dan toch bespreken: noteer die ‘hoog-over’ taken gelijk even in de story.
Stap 2: Maak taken klein genoeg voor een goede planning
De volgende stap vindt plaats als we de sprint willen starten, dus op zijn laatst in sprintplanning deel twee. Het belangrijkste daarbij is dat we, als team, een goed overzicht krijgen van hoe we de sprint gaan inrichten. In deze stap willen we de taken zo opsplitsen dat we een goed gevoel krijgen van de doorlooptijd van de verschillende taken en inzichtelijk krijgen welke taken afhankelijkheden laten zien. Snappen we wat de globale aanpak wordt? Past het in de sprint? Wat betekent het als iemand er niet is? En moeten we toch eerst een taak onderaan het scrumbord oppakken zodat we later in de sprint niet vastlopen?
Stap 3: Maak taken klein genoeg voor een goede team-communicatie
De laatste stap richt zich op de samenwerking binnen het team. Hoe gaan de taken het team ondersteunen in het elkaar helpen en het onderling snappen waar iedereen mee bezig is? Wat we in deze stap doen is taken klein genoeg maken zodat iedereen snapt wat de taak precies inhoudt en andere teamleden eventueel kunnen bijspringen. Hierbij kijken we zeker verder dan een functioneel blokje. We gaan dus van ‘bouw X’ naar: ‘schrijf test a’, ‘schrijf test b’, ‘maak tabel a’, ‘maak tabel b’, ‘maak ETL a’, ‘maak ETL b’, ‘voer test a uit’ etc. Het doel hiervan is dat teamleden gedurende de sprint eenvoudig van elkaar begrijpen waar ze mee bezig zijn (geweest), elkaar kunnen helpen en bij kunnen springen.
Hierbij is het handig te proberen om taken (een stuk) kleiner dan acht uur te maken. Zo zorgen we ervoor dat een taak eigenlijk niet langer dan één stand-up in ‘busy’ kan blijven hangen. Dit bevordert niet alleen de communicatie, maar zorgt er ook voor dat mogelijke ‘impediments’ snel naar boven komen. Stap 3 begint eigenlijk al bij sprintplanning deel twee (en heeft dus wat overlap met stap 2) en loopt de gehele sprint door. Als een teamlid voor het oppakken doorheeft dat één van zijn taken prima uiteen kan vallen in kleinere taken, dan zal hij deze verder op moeten splitsen.
Aan de slag!
Het zal van team tot team verschillen hoe en wanneer taken worden opgesplitst. Het lijkt misschien evident, maar door ook hierin discipline aan te brengen en standaard deze drie stappen aan te houden zullen teams uiteindelijk meer voorspelbaar zijn en onderling beter kunnen communiceren.
Dit blogartikel is geschreven door Jorg Vreeswijk