Inleiding
Ik heb lang getwijfeld om een blog te starten. Niet zomaar om een blog te hebben, maar om mijn kijk op bepaalde onderwerpen te delen met wie er iets aan heeft. Dit is mijn eerste poging om uit te leggen hoe ik denk en werk.
Het idee om uit te leggen hoe wij bij 333travel FLOW bereiken, ontstond tijdens het lezen van het boek Applying Scrum with kanban. Terwijl ik las, merkte ik dat veel van de ideeën in dit boek dingen waren die we al deden. Dat gaf me de moed om dit vanuit mijn eigen perspectief te schrijven.
Ik schrijf deze post als ik halverwege het boek ben. Op het punt waar Katie met haar team, waarin ze Scrum Master is, positieve FLOW aan het ontdekken is. Toen het boek over FLOW begon, werd er diep vanbinnen iets bij me getriggerd.
Ik kreeg kippenvel bij het lezen van dat hoofdstuk, omdat ik me realiseerde dat we veel van de ideeën uit het boek al hadden geïmplementeerd. Zonder te weten wat Scrum of Kanban was, in mijn begindagen. Gewoon door te proberen wat aanvoelde als een natuurlijke en goede manier van werken, al terug in 2017 met agile methoden.
Resultaten
We hebben sindsdien veel vooruitgang geboekt. Ik kan nu al zeggen dat we veel van de uitkomsten die het boek beschrijft in de praktijk brengen.
We begonnen in 2017 met Jira, met een aangepaste versie van swim lanes.
Een board met swim lanes die de onderwerpen van issues dekken.
Sommige swim lanes geschrapt, omdat onderhoud beheersbaar moet blijven en er een doel moet zijn om ze te gebruiken.
In de jaren daarna, toen we ons way of working echt wilden professionaliseren, kwamen de volgende onderwerpen onze workflow binnen. Deze inzichten staan in willekeurige volgorde.
Een definition of done (DOD) schrijven voor elke status van de swim lanes.
Het sprintdoel zichtbaar op ons fysieke whiteboard.
Een fysiek whiteboard gebruiken dat de single source of truth is, boven Jira.
Specifieke kleuren op de stories die we in een sprint oppakken, met een speciale kleur (groen) voor de stories die het meest bijdragen aan het sprintdoel.
Specifieke kleuren voor andere taken, hotfixes en dergelijke.
Blocked is geen status waar issues kunnen blijven staan. Geblokkeerde issues moeten zo snel mogelijk gedeblokkeerd worden, of teruggedraaid nadat we hebben vastgesteld dat we niet verder kunnen.
Werken vanuit het gevoel dat we elke taak/story die door de lanes zwemt als team helemaal naar rechts moeten afmaken, voordat we besluiten nieuw werk (stories) te starten.
Voor een visueel beeld van ons huidige Scrum board verwijs ik je naar de link aan het einde van deze post.
Zet een FLOW op gang!
Waarom dit me zo raakte, hield me lang bezig. Als ik er nu over nadenk, begrijp ik dat dit de katalysatoren waren die onze flow op gang brachten. Wat ik in mijn team zag, was dat we pas echt gingen samenwerken toen mensen écht samen gingen werken. (In de zin van: aan dezelfde stories werken en de subtasks daarbinnen oppakken.) Pas toen gingen de gesprekken over de stories waaraan we werken echt open.
Maar om dat te kunnen doen, moesten we eerst een bepaalde manier van werken creëren, met alle bovenstaande punten als basis voor transparantie en focus.
Scrum is een framework dat gesprekken faciliteert. Om een flow op gang te brengen moet je samenwerken. Aan dezelfde stories werken met alle developers richting het sprintdoel. Idealiter maak je iets af voordat je aan iets nieuws begint.
Developers proberen echt samenwerken vaak te vermijden, omdat ze denken dat het meer werk oplevert. Ze splitsen stories liever verder op, zodat ze solo aan stories kunnen werken. In plaats van aan subtasks binnen dezelfde story. Deze kleine gedragsverandering vraagt wat gewenning van developers. Maar als ze als team gaan opereren, kunnen ze in een staat van positieve flow komen waarin alles werkt.
Als je dit solo Scrum binnen een sprint blijft doen, verlies je veel van de voordelen die Scrum kan bieden. Je kunt natuurlijk zeggen dat je Scrum doet. Maar wil je zeggen dat je Scrum doet? Of wil je samen in een epische flow komen en de manier waarop je werkt voor altijd veranderen! (wie kan het schelen hoe het heet, toch?).
Het is ons standaardgedrag om binnen een sprint eerst te werken aan taken die we al het beste kennen (dan ben je sneller klaar, toch?). Ik daag mijn developers ook uit om te werken aan dingen waar ze binnen onze projecten nog niet aan gewerkt hebben. We moeten als Scrum team beter worden. Dat gebeurt niet als we in onze eigen kennisbubbels blijven werken. Developers moeten uitgedaagd worden om samen richting het productdoel te werken. Dat geeft elke developer meer autonomie en zelfvertrouwen.
Scrum gaat niet over de snelheid van development. Dat is slechts een bijkomstig voordeel als je met je team een bepaalde staat van flow bereikt.
Een visie instillen
Een visie neerzetten is ook cruciaal voor FLOW. Een idee hebben van waarom je dit product bouwt, is een van de belangrijkste dingen om mee te beginnen. Een productvisie of doel en een duidelijk sprint goal om vanuit te starten zijn een must. Je moet je doel kunnen uitleggen. Zo weet je waar we aan werken en wat we daarna moeten doen om dat doel te halen.
Het definiëren van technische schuld hangt sterk samen met je productvisie/-doel. Daardoor kun je de huidige staat van je product vergelijken met waar je het wil hebben. En welke technische schuld we moeten oplossen om daar te komen.
Een productvisie is niet concreet, en hij hoeft ook niet lang te zijn. Hij evolueert met de tijd, naarmate je meer ontdekt over wat het product gaat doen en wat de markt wil. Maar het begint allemaal met een visie waar je naartoe werkt. Er moet iets zijn dat het WAAROM uitlegt.
Conclusie
Ik hoop dat ik een paar nuttige inzichten heb gedeeld over hoe wij FLOW hebben weten te bereiken in ons Scrum team. We krassen volgens mij nog maar aan de oppervlakte, en er moet in ons team nog veel meer geoptimaliseerd worden. Maar we zitten zeker op het juiste spoor.
Zeker omdat ons hele Scrum team het gevoel heeft dat we in een FLOW opereren. En dat is een verdraaid goed gevoel om in te werken!
All Subjects MatterRemco
