Praktijkervaring met Burn Down Charts in de context van SAFe en Scrum

In dit artikel ben ik van plan te vertellen hoe wij in de praktijk de burn down chart gebruiken in het werkproces volgens de SAFe-methodologie

Ik begin toch maar met het meest interessante. Namelijk dat het gebruik van deze diagram in SAFe geen enkele specifiekheid zou moeten hebben ten opzichte van het gebruik van deze diagram in SCRUM. Of toch wel?

SAFe bij ons verschilt door de aanwezigheid van een rol als RTE, in tegenstelling tot SCRUM, waar die er niet is. Burn Down Chart - dit is een hulpmiddel om de omvang van het werk in de sprint te volgen en het is vooral nodig voor het SCRUM-team, en niet voor iemand van buiten, toch?

Zo ga ik toch over naar hoe wij Burn Down Chart gebruiken, ongeacht alles, en, nog steeds binnen het SAFe-framework.

Ik vervul de rol van Scrum Master en probeer deze diagram dagelijks onder de aandacht te brengen voor het hele Dev Team. Het middel dat ik gebruik - dat is de teamchat, een vermelding van het hele team via "@", een screenshot van de huidige staat van de diagram. Een vermelding van het hele team - dat is een nogal subtiel instrument en het is belangrijk om het zo zelden mogelijk te gebruiken (we, Scrum Masters, moeten de team immers helpen werken in comfort en met zo minimaal mogelijke afleiding, toch?)

Uiteindelijk ziet het team dagelijks de huidige staat van de sprint en is het in staat de volgende gebeurtenissen te volgen

• Het verschijnen van ongepland werk
• Lang blijven hangen van taken in een onvoltooide status
• Overmatig inbouwen van risico's
• Begrip - of het werk in het juiste tempo gaat

Vervolgens zal ik proberen elk van deze gebeurtenissen toe te lichten en voorbeelden uit mijn praktijk te geven.

Het verschijnen van ongepland werk

Op deze diagram is heel goed te zien hoe nieuw werk verschijnt (op de tweede dinsdag van de tweewekelijkse sprint).

Geval uit de praktijk: "Een ontwikkelaar, als lid van het scrum-team dat de agile-principes deelt, werkt prima samen met de Product direct. De Product zegt hem dat dit even snel ingebouwd moet worden, je begrijpt zelf wel, hier is het snel en de risico's zijn minimaal.

De ontwikkelaar is prima, hij weet alles van agile en van het belang van het leveren van bedrijfswaarde, gaat en gooit een story uit de backlog op het bord, door het team geschat op 6 sp.

De rest van het team (behalve de ontwikkelaar en de Product) merkt dit op bij de ochtendupdate van de diagram. Op de standup neemt het team een beslissing hoe met deze situatie om te gaan. Hoogstwaarschijnlijk wordt de story uit de sprint gegooid, aan de Product en de Ontwikkelaar maakt het team duidelijk dat dit niet de bedoeling is, de product kan deze story indien nodig in de volgende sprint plaatsen.

Natuurlijk zou het team idealiter het verschijnen van nieuw werk op de standup moeten opmerken en zonder de diagram. Maar de diagram is een goede indicator die de risico's om zo'n belangrijke verandering voor het hele team niet op te merken tot een minimum beperkt.

Hier is het belangrijk te begrijpen dat het scenario anders had kunnen verlopen afhankelijk van het niveau van het team. In sterke teams zou de Product Owner dit waarschijnlijk niet zo gedaan hebben, en als hij het al deed, dan zou hij het niet argumenteren met dat "dit even snel ingebouwd kan worden", maar met dat "ik schat de kans op 55% dat als dit nu ingebouwd wordt, het onze winst volgende maand met 20% kan verhogen" of een andere meetbare metriek.

Lang blijven hangen van taken in een onvoltooide status

Hier zien we dat het werk heel lang niet eens gedeeltelijk wordt afgerond. Dit kan wijzen op verschillende problemen, ik noem er enkele

• Slechte decompositie van taken

  Heel vaak zeggen beginnende teams dat decompositie onmogelijk is. Bij hen brandt alles af op de laatste dag, het werk wordt niet geparallelliseerd enz. Natuurlijk moet de Scrum Master hiermee aan de slag en het team de waarde van decompositie uitleggen.

• Niet optimaal geformuleerde DOD

  DOD (Definition of Done) - beschrijving van de criteria voor gereedheid van een User Story in de sprint. Soms zijn ze er helemaal niet of ze zijn zeer abstract beschreven. Dit kan heel goed een probleem zijn, dat natuurlijk door de Scrum Master moet worden helpen opgelost

Overmatig inbouwen van risico's

In dit geval zien we een situatie waarin het team te veel risico's heeft ingebouwd.

Mogelijk is een verhaal overschat. Mogelijk is dit een meer systemisch probleem en moet het werkvolume worden vergroot bij de sprintplanning. In elk geval is deze situatie niet correct. De business had immers gepland dat precies de taken van de sprint zouden worden gerealiseerd en precies aan het einde van de sprint. Afhankelijk van hoe de afhankelijkheden waren gepland, zullen hier waarschijnlijk bijeenkomsten moeten worden gehouden om de verwachtingen bij te stellen.

In mijn praktijk gebeurde dit toen er een snellere oplossing werd gevonden dan tijdens de schatting was besproken. We bespraken met het hele team welk verhaal we voor het einde van de sprint konden afronden en tijdens de retrospective spraken we af dat we zouden proberen de code bij het groomen te bekijken. Het bleek dat het voldoende was om gewoon in de code te kijken om te begrijpen dat de oplossing veel eenvoudiger was.

Begrip - gaat het werk in het juiste tempo

Hier wil ik de aandacht vestigen op grafisch ongelukkige manieren om de Burn Down Chart weer te geven

Bovenaan de afbeelding staat een voorbeeld van een niet al te geslaagde grafische implementatie om twee redenen, die ik hieronder uiteen zal zetten.

• Het is niet zichtbaar dat nieuwe SP de sprint binnenkomen

  Hier, op de bovenste diagram, is het nauwelijks zichtbaar dat er ongepland werk is toegevoegd. Op de onderste is dit duidelijker.

• De relatieve resterende hoeveelheid werk wordt niet correct weergegeven

  Volgens de bovenste diagram resteert nog 3 dagen werk. In feite zijn het er 2, op de vrije dag is het mogelijk dat iemand van plan is te rusten.

Natuurlijk zullen sommigen zulke kleinigheden onbeduidend vinden. Maar men moet begrijpen dat elk lid van het team slechts met een half oog naar deze diagram kijkt en dat deze zoveel mogelijk nuttige informatie moet overbrengen.