Hieronder vind je een voorbeeld van ons huidige visuele whiteboard. (wat is daar een bruikbare term voor?). Ik weet dat er nog veel punten aan te pakken zijn om ons board nog verder te verbeteren. We hebben al lang geleden geaccepteerd dat we niet meteen perfectie kunnen bereiken. Try, Inspect and Adapt..
Netter schrijven op een whiteboard is een skill die iedereen wil beheersen, maar het vraagt veel tijd en moeite. Niet iedereen is bereid of in staat zich daarvoor in te zetten ;)
Introductie
Hieronder gebruik ik het woord story om iets op te delen in subtasks. Voor ons is dit meestal een story, en dat vertelt ons ook dat we openstaan om te discussiëren over het hoe en het wat.
Een task is iets dat gewoon gedaan moet worden, of een specifiek verzoek om bijvoorbeeld een query te draaien voor een export. Niet veel creativiteit in :). Een task is meestal al gedefinieerd in het wat/hoe. Dat is voor ons het belangrijkste verschil tussen de twee.
Bugs en hotfixes zijn voor ons bijna hetzelfde. Behalve dat een hotfix meteen gefixt en gedeployd wordt. En een bug gewoon normaal door het systeem beweegt. We markeren ze allebei rood op het board, dus dat is voor ons ook nog een punt om aan te werken om een visueel verschil te maken.
Subtasks zijn tasks die van een story worden afgesplitst en af moeten zijn om de story verder te bewegen. Om het simpel te houden kun je zeggen dat we de term story gebruiken voor tasks die opgedeeld kunnen worden. Vanuit het DoD-perspectief kan het mij niets schelen hoe de subtasks op het board staan. De waarde zit voor mij in de hele story waar we ons aan hebben gecommit. Subtasks worden op dit moment verwijderd zodra ze af zijn.
We bekijken andere varianten om subtasks nog X tijd op het board te laten staan. Als we die bevindingen kunnen analyseren, schrijf ik daar nog een post over.
Werken: TODO & IN DEV
Alle subtasks onder een story gaan pas naar de TODO lane als het werk aan die specifieke story begint. Dit geeft visueel aan dat we ons eraan committen om hem af te maken. Zodra alle subtasks af zijn, beweegt de story tussen de lanes. Dit omdat de waarde van de story als geheel naar de DONE lane moet om voor ons waarde op te leveren.
Deze aanpak zorgt ervoor dat de TODO lane schoon blijft. Het zorgt er ook voor dat de focus alleen ligt op de subtasks binnen de story waaraan gewerkt wordt. Je zou ook kunnen zeggen dat de lane links van TODO op het board de sprint backlog vertegenwoordigt. En we trekken pas nieuw werk binnen als we ons committen aan het deel dat we hierna gaan ontwikkelen.
Als we aan een task gaan werken, verplaatsen we hem fysiek naar IN DEV. Als de subtask klaar is, halen we hem van het board. We zetten ook onze naamtag bij de subtasks waaraan we werken. We kunnen aan meer dan één task tegelijk werken als we zien dat het werk bijvoorbeeld te veel overlapt.
Op de afbeelding hierboven zijn we net klaar met het werk aan onze derde story. De developers hebben deze story gekozen boven de tweede prioriteit. Dit omdat hij op dat moment meer waarde opleverde. Deze beslissing is genomen vanwege ziekte van één van onze senior developers en een korte vakantie van onze PO. De ochtend waarop deze foto is genomen, gaf onze PO ons meer details over de tweede story. Daardoor konden de Developers hem opdelen in werkbare items/tasks.
Geblokkeerde stories
Als stories na afloop van een nieuwe sprint nog in de testing lane op het board staan. En die story geen deel was van de huidige sprint, dan markeren we hem als blocked. In dit geval hebben we de story gemarkeerd met een uitroepteken. Natuurlijk blijven we aan die story werken. We blijven proberen hem vooruit te bewegen, maar soms kost het meer tijd om een story naar rechts te bewegen. Soms moeten we de hulp van de PO inroepen om hem vooruit te helpen, of met de stakeholders over de waarde discussiëren.
Deze blocking state kan door een externe factor komen, zoals dat de task/story niet getest wordt. Het kan ook een kwaliteitsprobleem zijn waarbij bugs blijven opduiken. En we dan niet de vereiste kwaliteit kunnen leveren totdat dit gefixt is. Elke geblokkeerde story wordt bij de sprint planning opnieuw beoordeeld. Zo kunnen we bepalen of hij nog deel gaat uitmaken van de nieuwe sprint planning.
Zoals wij werken kunnen we alleen blocking stories in test hebben. Dat is het moment waarop we dachten de waarde geleverd te hebben. Die waarde zit dan al in onze release cycle, want we vonden dat hij aan de DoD voldeed.
Dit is ook het deel waar we op dit moment de meeste focus op leggen. Meer kwaliteit leveren voordat we iets in test zetten. We hoeven er alleen nog voor te zorgen dat onze infrastructuur meewerkt. En dat is weer een ander onderwerp waar we aan werken. We gaan met Kubernetes werken en dat lost de meeste problemen met onze release cycle op.
Afronden: IN REV & IN TEST
Pas als alle subtasks klaar zijn en de hele story lokaal getest is door de developers, mag de derde story naar de IN REV(iew)-lane.
Daar bekijken twee developers de story, waarna die naar de IN TEST-lane mag. Alleen na een positieve review van beide, natuurlijk. Eén uitzondering: de story mag ook verder als één developer hem gereviewd heeft en er 24 uur voorbij zijn.
Dit werkt voor ons omdat we met z’n vieren zijn, niet iedereen altijd beschikbaar is, en we toch verder moeten.
We hebben momenteel twee testomgevingen: 31test en 32cur.
Zoals eerder uitgelegd werken we aan de overstap naar geautomatiseerde DevOps met Kubernetes. Dat maakt de weg naar de test-lane een veel geautomatiseerdere ervaring. Een extra voordeel is dat het ook meer kwaliteit oplevert.
Eindelijk DONE!
De DONE-lane is opgesplitst, en waarom leg ik hieronder uit. Afgeronde increments die nog niet live zijn deployed, staan op het bord in de “DONE not yet released”-lane. Dit is de enige lane die aan het einde van elke sprint niet geleegd wordt.
De items in de “DONE not yet released”-lane moeten natuurlijk wel gereleased worden. Maar dat gebeurt niet altijd meteen. Zo moeten we soms eerst communiceren over de veranderingen voordat we ze releasen. Een ander voorbeeld: een feature die op een vaste datum live gaat.
Als developers moeten we natuurlijk wel blijven bijhouden wanneer deze updates live gaan. Er kunnen bugs ontstaan, dus we moeten weten wat er wel en niet gereleased is.
Dit houdt ook een gezonde discussie gaande over werk dat af is maar nog niet gereleased. Dat het zichtbaar is, maakt wat we doen transparanter.
Het released-deel onder DONE betekent uiteraard dat het item live en volledig deployed is. Dit deel van de lane wordt elke sprint geleegd. De afgeronde items worden na elke sprint van een versienummer voorzien om de voortgang bij te houden.
Subtasks en zichtbaarheid
We worstelen nog met afgeronde subtasks. We willen ze een tijdje laten staan, voor de transparantie. Het voelt beter om een subtask pas weg te halen nadat je hem hebt afgerond. Dat voelt beter dan ze meteen van het bord verwijderen.
We bespreken momenteel verschillende varianten van ons bord. Misschien maken we een ruimte onder de lanes waar alle afgeronde subtasks komen te liggen. Tot de developers besluiten ze te verwijderen, uiteraard. Zij zijn verantwoordelijk voor de leesbaarheid van het bord.
We testen op dit moment drie verschillende versies van ons whiteboard. Daar kom ik later op terug.
Iets over Jira
We hebben geen regel om subtasks in Jira te zetten. Sterker nog: ik zie ze daar liever niet. Ik gebruik Jira vooral als mijn backlog- en versiebeheersysteem. Subtasks voegen voor mij in Jira niets toe, totdat ze van een story worden afgesplitst en zelf een task worden.
We volgen en plannen de hele sprint wel in Jira. Maar dat is op globaal niveau. Het uitgevoerde werk is vooral zichtbaar op ons whiteboard. Stories bewegen uiteraard op beide plekken. Het bord en Jira moeten synchroon lopen op de stories, anders kan ik mijn versiebeheer en dat soort dingen niet doen.
Als een developer een subtask wil toevoegen of eroverleg over nodig heeft, voegen we de subtask natuurlijk wel toe aan Jira. Zo kunnen we de besproken uitkomsten vastleggen en er later op terugkomen. Dat gebeurt meestal op de parent story, uiteraard. Maar het kan voorkomen dat je een discussie bij een subtask wilt registreren. We moedigen het niet aan, maar verbieden doen we het ook niet.
Gesprek
Als ik wil weten waar we staan in de sprint, moet ik echt naar dat bord lopen, waar de developers ook werken. Een voordeel daarvan is het gesprek dat dan ontstaat tussen de developers en mij als PO. De developers zien dat ik beschikbaar ben, en ik kies mijn momenten om langs te komen natuurlijk zorgvuldig.
Je moet wel oppassen dat je de developers niet te veel stoort en het werk niet te vaak komt checken. Er zit een balans in wanneer je daarheen loopt en met je aanwezigheid de developers stoort.
Dat gesprek gaat vaak over dingen die ze vandaag toch al wilden vragen. Omdat ze zien dat ik beschikbaar ben, is het op dat moment nog makkelijker om me aan te spreken en dat laatste te verifiëren.
Als PO moet je tijdens sprints contact houden met je developers. Liever zelfs dagelijks, afhankelijk van de stories in de sprint. Je bent er niet alleen om de sprint te openen en af te sluiten. Dat is geen samenwerking.
