Er wordt al veel geschreven over Scrum. Scrum is dood, enzovoort. Nou, als je een vacature hebt voor een “Manager”, een “conciërge” of een andere duidelijk niet-Scrum functietitel, maar besluit het een vacature voor een Product Owner of Scrum Master te noemen, dan ben jij degene die het verkloot. Alleen het beest een andere naam geven zorgt er niet voor dat het ineens als magie werkt.

We hebben het allemaal weleens gehoord: “We doen Scrum, en hupsakee! We leveren in een mum van tijd waarde!” (Spoiler alert) zo werkt het niet. Scrum is geen toverdrank die chaos in orde verandert door er wat ceremonies overheen te strooien. Het kost veel meer dan de stappen in de Scrum guide volgen om tot echte resultaten te komen. Het draait om teamwork, discipline en de juiste mensen op de juiste plek — en geloof het of niet, het verschilt niet zoveel van hoe dingen in het leger getraind worden ;-).

Sprint is een missie

Beginnen we nog eens met de olifant in de kamer: het woord “sprint”. We zijn toch niet echt aan het hardlopen? Voor mij suggereert die term nog steeds haast, maar in werkelijkheid mikken we op een doordachte, goed geplande missie. Net als in het leger gaat het niet om snelheid, maar om precisie en succes. Een goed uitgevoerde missie gooi je niet zomaar in elkaar, die wordt strategisch gepland en vereist dat iedereen zijn rol speelt en zijn steentje bijdraagt tot de finish.

Een missie uitvoeren vraagt om aanpassing onderweg. Je gaat onbekenden tegenkomen en je moet erop voorbereid zijn om daarmee om te gaan in plaats van ze te vermijden of negeren en je missie te verkloten.

Onbekenden oplossen als een TEAM is wat een Agile/Scrum-aanpak laat werken.

Gespecialiseerd, maar allround

In zowel Scrum-teams als militaire eenheden heeft iedereen z’n eigen specialiteiten en sterke kanten. Maar hier komt de kicker: we leveren waarde als team. Net als in het leger, waar soldaten cross-trained worden om gaten te vullen, zijn wij ook allrounders. Als er iets misgaat, steken we niet onze handen in de lucht en noemen we het een dag. We passen ons aan en klaren de klus, samen (als team!).

Scrum werkt niet zonder de juiste mindset {#scrum-doesn%E2%80%99t-work-without-the-right-mindset}

Scrum draait niet vanzelf. Alleen Scrum aannemen zorgt niet ineens voor waarde. Ik heb het zien gebeuren. Mensen denken dat als ze de ceremonies draaien en wat Scrum-gerelateerde stappen volgen, de magie vanzelf gebeurt. Maar zonder dat je team zelf het proces managet, is het als een militaire missie draaien zonder kapitein, zonder briefing, en iedereen die maar wat aanmoddert. Misschien kom je wel tot het einde, maar wat heb je dan eigenlijk gedaan?

Het leger weet dit goed. Er is structuur, leiders die sturen, maar ook het vertrouwen dat elk teamlid proactief is. In Scrum heb je de juiste mix nodig: een Product Owner met een mandaat en een daadwerkelijke visie die het bedrijf ondersteunt, een Scrum Master die de flow erin houdt, en een team dat niet alleen taken uitvoert maar nadenkt over het grotere geheel. Die mindset bereik je alleen door samen te werken en als één team met elkaar te blijven praten.

Een team dat over de moeilijke dingen praat

Als team moeten we samenwerken, open met elkaar praten en de moeilijke dingen aanpakken. Ik heb het niet over makkelijke gesprekken waarin iedereen het met elkaar eens is. Ik bedoel moeilijke, ongemakkelijke discussies over wat niet werkt of niet duidelijk is, wat beter moet en hoe je daar komt. Pas dan komt de juiste geleverde waarde bovendrijven.

Bespreek onbekenden tijdens je missie en pak ze aan. Een “daily scrum” aanhouden leert dat niet vanzelf.

Hoe denk je dat Apple de iPhone heeft gemaakt? Jobs en Ive zaten niet samen elkaar op de schouder te kloppen. Ze discussieerden, itereerden en duwden elkaar voort tot het product goed was. En zo zouden Scrum-teams moeten werken. Je doet niet gewoon wat makkelijk of snel is. Je werkt de problemen door, daagt elkaar uit en itereert tot je het hebt. Je stelt ook veel (WAAROM-)vragen, zodat je begrijpt waar ieder vandaan komt.

Briefings en debriefings zijn cruciaal, maar alleen als je er iets voor doet

In Scrum hebben we onze Planning (briefing) en onze Review en Retrospective (debriefing). Klinkt bekend? Je kunt niet zomaar aan een missie beginnen zonder plan, en je kunt al helemaal niet verbeteren zonder terug te kijken naar wat er mis of goed ging. Maar, en hier zit de kneep: je moet deze sessies ook echt gebruiken waarvoor ze bedoeld zijn. Te vaak worden ze overhaast gedaan of afgevinkt. In het leger kan een mislukte briefing of debrief levens kosten, in Scrum kost het je de mogelijkheid om bij de volgende missie te itereren en dingen te testen en te verbeteren. Neem ze serieus, anders zijn het gewoon lege meetings die geen waarde leveren.

Teamwork is alles

Uiteindelijk slagen zowel Scrum als militaire missies door teamwork. Je hebt mensen nodig die betrokken zijn, die communiceren en die voor elkaar klaarstaan. Zonder dat ben je gewoon een stel mensen die roept dat ze Scrum doen, en dat levert helemaal geen waarde op. Scrum draait niet om helden, maar om het collectieve doel. Je wint samen, je verliest samen.

Scrum is geen heilige hamer die alles oplost

Oké, even dit: Scrum is een framework. Een door mensen bedachte structuur, bedoeld om teams efficiënt samen te laten werken. Maar Scrum doen levert niet automatisch waarde op voor je bedrijf. Je hebt de juiste mensen nodig, de juiste mindset en een duidelijke missie waar iedereen naartoe werkt. Anders ben je gewoon taken aan het afvinken zonder erover na te denken — en dat gaat mis.

Nog iets: pas je manier van werken aan aan wat je bedrijf nodig heeft. Scrum geeft een structuur waar je je aan kunt aanpassen. Maar wees niet bang om dingen te veranderen als dat beter werkt voor je organisatie. Het doel is een team dat graag werkt binnen de structuur en waarde levert in plaats van features.

Je als team, of zelfs als organisatie, moet het laten werken door de juiste mensen (met visie en mandaat) en processen op zijn plek te zetten. Doe je dat niet, dan eindig je met een noodlanding: niets opgeleverd, alleen frustratie.

Laat solo managers die vooral zichzelf er goed uit willen laten komen je drive naar waarde en het écht helpen van de business niet overnemen. Niet de business schaden.

Deze post is een vervolg op GIT deployment-strategieën binnen Kubernetes-omgevingen. Lees eerst deze post:

CI/CD pipeline with Docker and Git branching strategyExplore advanced CI/CD with Docker & Git. Master deploying Docker artifacts via Git branching. Dive into strategies for DEV, STAGING, LIVE environments. Perfect your pipeline now! All Subjects MatterRemco Loup.

In een CI/CD-pipeline die draait om Docker artifacts, met de focus op één enkele branch, vraagt een efficiënte hotfix-strategie om een kleine afwijking van de standaardaanpak. Zo zorgen we dat kritieke fixes snel gedeployd worden. Laten we onze aanpak voor hotfixes in deze Docker-gerichte omgeving uitwerken, op basis van de branch-architectuur uit de post hierboven.

Wanneer is een hotfix nodig?

Hotfixes zijn cruciaal voor de stabiliteit en betrouwbaarheid van elke software in productie. Ze zijn meestal nodig in situaties die directe actie vragen. Weten wanneer je een hotfix inzet, is essentieel om je CI/CD-pipeline goed te beheren, zeker als je werkt met Docker artifacts en een gestroomlijnde branch-strategie met één hoofdbranch. Dit zijn onze scenario’s waarin een hotfix nodig kan zijn:

1. Beveiligingslekken: Een van de meest urgente redenen voor een hotfix is het ontdekken van een beveiligingslek in je applicatie. Of het nu gaat om blootgestelde data, risico op ongeautoriseerde toegang of een andere kwetsbaarheid die kwaadwillenden kunnen misbruiken: je moet snel handelen om het lek te dichten en je gebruikers en data te beschermen.
2. Kritieke bugs die de gebruikerservaring raken: Als een serieuze bug door je testproces heen glipt en in productie belandt, kan dat de gebruikerservaring flink raken. Dat kan van alles zijn: een kapotte kernfunctionaliteit waardoor gebruikers de applicatie niet meer kunnen gebruiken, of ernstige performanceproblemen die leiden tot timeouts of crashes. Raakt het probleem een groot deel van je gebruikers? Dan is een hotfix op zijn plaats.
3. Compliance-problemen: Sommige applicaties hebben te maken met wettelijke of regelgevende eisen. Als er een compliance-probleem wordt geconstateerd dat je juridische positie of de privacy van gebruikers kan raken, moet dat snel met een hotfix worden opgelost om boetes of verlies van vertrouwen te voorkomen.
4. Risico op dataverlies: Situaties waarin gebruikersdata verloren kan raken of corrupt kan worden, vragen om directe actie. Of het nu een fout is in hoe data wordt opgeslagen, bijgewerkt of opgehaald: deploy dan een hotfix om verlies of corruptie van gebruikersdata te beperken.
5. Falende betalingen of transacties: Voor applicaties die betalingen of andere transacties verwerken, zijn problemen die transacties blokkeren of tot financiële discrepanties leiden kritiek. Zulke problemen schaden niet alleen het vertrouwen van gebruikers, maar kunnen ook financiële gevolgen hebben voor zowel gebruikers als de dienstverlener. Een hotfix is dan noodzakelijk.

Een hotfix deployen

Als er een kritiek probleem in de productieomgeving wordt geconstateerd, is het doel om zo snel mogelijk een hotfix te ontwikkelen, testen en deployen. Omdat MAIN onze hoofdbranch voor development is en we Docker artifacts genereren voor deployment, hebben we een proces nodig dat snelle interventie mogelijk maakt zonder het lopende werk te verstoren.

1. Een hotfix-branch aanmaken: In plaats van te branchen vanaf je Production branch (LIVE bestaat in deze strategie immers niet meer in de Git-repository), maak je de hotfix-branch vanaf de commit die op dat moment in productie draait. Zo is de hotfix gebaseerd op exact de versie die in de productieomgeving draait. De specifieke commit vind je via tags of Docker image-labels die gekoppeld zijn aan de productie-deployment.
2. De hotfix ontwikkelen en testen: De kritieke fix wordt ontwikkeld binnen deze hotfix-branch. De urgentie vraagt om een gerichte aanpak: pak het probleem aan met minimale wijzigingen om testen en deployen te versnellen. Ook onder tijdsdruk is het naleven van de Definition of Done (DoD) cruciaal voor de stabiliteit en betrouwbaarheid van de hotfix. Dat kan een compactere versie van de DoD zijn, met prioriteit voor de kritieke tests en checks die garanderen dat de fix geen nieuwe problemen introduceert.
3. Een Docker artifact voor de hotfix maken: Zodra de hotfix aan de afgesproken DoD-criteria voldoet, bouwt een geautomatiseerd proces een Docker image van de hotfix-branch. Dit Docker artifact krijgt een passende tag, zodat duidelijk is waar het voor dient en hoe urgent het is.
4. De hotfix deployen: Het nieuwe Docker artifact wordt direct in de productieomgeving gedeployd, waarbij de gebruikelijke route via DEV en STAGING naar PRODUCTION wordt overgeslagen. Deze deployment is alleen te rechtvaardigen door de kritieke aard van de fix en de tests die erop zijn uitgevoerd.
5. Terugmergen en consistentie bewaken: Als de hotfix succesvol in productie draait, is het essentieel om de wijzigingen terug te mergen naar de MAIN branch en eventuele andere relevante branches of tags. Pas deze stap zorgt ervoor dat de fix wordt opgenomen in het lopende developmentwerk en toekomstige releases, en dat je geen regressie krijgt!!

Snel deployen en zo min mogelijk storing

• Geautomatiseerde processen: Automatisering speelt een sleutelrol in deze strategie, van het maken van het Docker artifact tot de deployment. Geautomatiseerde tests, builds en deployments zorgen dat het hotfix-proces zo snel en efficiënt mogelijk verloopt.
• Communicatie en monitoring: Snelle deployment van hotfixes vraagt om heldere communicatie binnen het team en nauwe monitoring van de productieomgeving na de deployment, om te verifiëren dat de fix werkt en geen nieuwe problemen introduceert.
• Documentatie en review: Het documenteren van het hotfix-proces en het doen van post-mortem-reviews helpt om de hotfix-strategie te verfijnen, zodat het team bij toekomstige problemen nog effectiever kan reageren.

Conclusie

In een CI/CD-pipeline met Docker en Git Flow als hoofdstrategie vraagt een hotfix om een strakke aanpak: gebruik de automatisering die er al is en focus op snelle, gerichte fixes. Door hotfix-branches te baseren op de commit die in productie staat, fixes te bouwen en testen volgens een goed gedefinieerde Definition of Done, en de Docker-artifacts direct naar productie te deployen, lost een team kritische problemen snel op zonder de stabiliteit en integriteit van de applicatie in gevaar te brengen.

In deze post ga ik in op het beheren van een CI/CD-pipeline met Docker, met de nadruk op een Git branching-strategie met een development- (DEV), staging- (STAGING) en production-branch (LIVE). Het doel is duidelijk maken welke rol elke branch speelt in het proces, en vooral hoe Docker-artifacts binnen dat stramien worden aangemaakt en beheerd.

Docker-deployments met Git Flow en meerdere branches

De kern van onze branching-strategie bestond uit drie branches:

1. DEV: Hier gebeurt alle ontwikkeling. Elke nieuwe feature, bugfix of verbetering start in een feature branch, afgesplitst van DEV. Is het werk af, gereviewd en voldoet het aan de Definition of Done (DoD), dan wordt het gemerged naar DEV.
2. STAGING: Deze branch spiegelt een pre-productieomgeving. Hier worden geïntegreerde features uit DEV als geheel getest en door stakeholders geaccepteerd, zodat we zeker weten dat alles samenwerkt.
3. MASTER: De branch die de huidige staat van onze live-omgeving weerspiegelt. Alleen grondig geteste en door stakeholders goedgekeurde wijzigingen uit STAGING halen het tot Productie.

Git Branching and Branching StrategyIn this post, we will go over why branching is required, the difference between development, staging… DEV CommunityPreetham

Dit was onze variant op een Git Flow-strategie, die we tot nu toe gebruikten. Zodra je met artifacts gaat werken, verandert dat allemaal terug naar een normale Git Flow-structuur. We hebben nog steeds omgevingen die draaien (Dev, Staging en Prod). Het echte verschil is dat code nu één keer gecommit wordt, in plaats van gemerged te worden naar een branch die op Staging of in Productie draait.

In plaats daarvan hebben we nu één branch, die we Main noemen. Daar wordt na een geslaagde code merge met Docker images een runnable artifact aangemaakt. Alles wat we op Staging of in Productie deployen is een specifieke versie van een eerder aangemaakt artifact.

Het grootste verschil: STAGING en PROD zijn geen branches meer waar je code in merged. Het zijn omgevingen geworden die een specifieke versie van een Docker image draaien. Dat brengt eigen uitdagingen met zich mee, zeker bij een hotfix. Hotfixen krijgt een eigen post, die je na deze kunt lezen. Ik loop het nu eerst stap voor stap door, zonder de hotfix erbij. Het is al omvangrijk genoeg zo.

Wat is een artifact?

Een Docker-artifact, vaak door elkaar gehaald met een Docker image, is een lichtgewicht, zelfstandig uitvoerbaar package dat alles bevat wat nodig is om een stuk software te draaien: de code, een runtime, libraries, omgevingsvariabelen en configuratiebestanden. Simpel gezegd: een snapshot van je applicatie én de omgeving eromheen, samen verpakt, klaar om overal gedeployed en gedraaid te worden waar Docker is geïnstalleerd. Zo weet je dat alles in verschillende omgevingen consistent werkt.

Het belang van de DoD bij het mergen van code

Een volledige en heldere Definition of Done (DoD) speelt in dit nieuwe proces een sleutelrol, zeker nu alle wijzigingen in één enkele branch gemerged worden die een Docker image moet opleveren die runnable en deployable is:

• Kwaliteitsborging: De DoD zorgt dat alle wijzigingen — nieuwe features, verbeteringen en hotfixes — die terug in MAIN gemerged worden aan een consistent kwaliteitsniveau voldoen. Denk aan code quality checks, succesvol doorlopen geautomatiseerde tests en het volgen van security best practices.
• Regressie voorkomen: Door de DoD toe te passen op alle merges naar MAIN voorkomt het team regressies en zorgt het dat nieuwe wijzigingen bestaande functionaliteit niet breken. Cruciaal voor de integriteit en stabiliteit van de codebase.
• Deployments soepeler laten verlopen: Een duidelijke en volledige DoD maakt deployments makkelijker, omdat alleen volledig gecontroleerde, deploy-klare wijzigingen in MAIN gemerged worden. Zo verspil je geen resources aan het bouwen van Docker images met bugs of die helemaal niet werken, en dat levert efficiëntere en betrouwbaardere artifacts op.

Artifacts aanmaken en beheren

De eerste voorwaarde om dit proces te laten werken: zodra een afgesplitste branch terug in MAIN gemerged wordt, start dat een geautomatiseerd proces in onze CI/CD-pipeline. Dit gebeurt er:

1. Geautomatiseerde tests: Eerst draaien de geautomatiseerde tests om te checken of de nieuwe wijzigingen aan onze kwaliteitsnormen voldoen. Cruciaal voor een stabiele branch.
2. Docker-artifact aanmaken: Zijn alle tests geslaagd, dan wordt er een Docker image (ons artifact) van de MAIN-branch gebouwd. MAIN is immers de enige branch die de laatste staat van alle afgeronde ontwikkeling vertegenwoordigt. Van daaruit genereren we artifacts die “shippable” producten kunnen worden.
3. Waarom MAIN voor Docker-artifacts?: Door artifacts op dit moment aan te maken vangen we integratieproblemen vroeg op. Omdat elke feature die in MAIN gemerged wordt als release-klaar wordt beschouwd, heb je door hier een artifact te genereren altijd een geteste en potentieel deploybare versie van je product bij de hand.

Van branches naar omgevingen

In traditionele Git-workflows staan branches als STAGING en PROD voor verschillende fasen in het ontwikkelproces, van testen tot productie. In een Docker-gecentreerde CI/CD-pipeline verschuift de focus: deze branches dienen niet langer voor code-integratie, maar als referentie voor deployment-omgevingen.

Deployen naar STAGING

• Docker-artifacts aanmaken: zodra de ontwikkeling klaar is en gemerged is naar de MAIN-branch, wordt er automatisch een Docker-artifact aangemaakt. Dat artifact is een snapshot van je applicatie op dat moment, met alle wijzigingen die gemerged zijn.
• Deployen in plaats van mergen: de rol van de STAGING-omgeving is om dit Docker-artifact te testen onder omstandigheden die sterk lijken op productie. In plaats van code van MAIN naar een STAGING-branch te mergen, deploy je het Docker-artifact naar een STAGING-omgeving. De code zelf beweegt dus niet tussen branches; het is de gecompileerde en gecontaineriseerde versie van je applicatie die getest wordt.
• Het doel van STAGING: de STAGING-omgeving is essentieel voor uitgebreide tests, waaronder performance- en security-assessments. Het is een laatste check om te verifiëren dat alles werkt zoals verwacht in een productie-achtige omgeving, zonder je echte gebruikers direct te raken.

Naar productie

• Goedkeuring van stakeholders: zodra je Docker-artifact grondig getest is in STAGING en goedgekeurd is door de stakeholders, is het klaar voor productie. Deze stap is cruciaal om te garanderen dat alle features, fixes en updates aan de nodige standaarden en verwachtingen voldoen.
• Deployen naar productie: de overgang van STAGING naar PROD betekent dat je het geteste Docker-artifact deployt naar je productieomgeving. Dit deploymentproces garandeert consistentie: het exacte artifact dat in STAGING getest is, wordt naar PROD gedeployd. Zo zijn er geen verschillen tussen geteste en gedeployde code.

Belangrijkste punten

• Geen branch-merges meer voor deployment: in deze gestroomlijnde workflow worden STAGING- en PROD-branches niet meer gebruikt om code te mergen. In plaats daarvan verwijzen ze naar specifieke deployment-omgevingen waar Docker-artifacts voor tests en productie gedeployd worden.
• Focus op artifacts: de nadruk ligt op het aanmaken, testen en deployen van Docker-artifacts. Deze artifacts vertegenwoordigen stabiele versies van je applicatie, klaar voor STAGING en uiteindelijk voor PROD.
• Consistentie en betrouwbaarheid: door hetzelfde Docker-artifact van STAGING naar PROD te deployen, weet je zeker dat wat getest is exact is wat er uitgebracht wordt. Dat vergroot de betrouwbaarheid en voorspelbaarheid van je deployments.

Deze aanpak vereenvoudigt het deploymentproces, verkleint het risico op fouten en zorgt ervoor dat elke release grondig getest wordt in een omgeving die productie zo nauw mogelijk benadert.

Zijn meerdere branches nog nodig?

In deze nieuwe workflow hebben de STAGING- en PROD-branches in de Git branching strategy geen actieve functie meer en zijn ze dus overbodig geworden. Ze hielpen om bij te houden welke versies van de code naar welke omgeving gedeployd waren. Dat probleem hebben we nu opgelost door een specifieke versie van een artifact te draaien.

Conclusie

Door Docker op te nemen in onze Git branching strategy stroomlijnen we het hele traject van development tot deployment: elke merge naar MAIN triggert een Docker-image met de potentie om naar productie te gaan. De sleutel van deze strategie is het vroeg in de developmentcyclus aanmaken van Docker-artifacts, zodat continuous integration en delivery mogelijk blijven zonder in te leveren op kwaliteit en stabiliteit.

Door de veranderingen aan de Git-branches te begrijpen en het proces van het aanmaken en deployen van Docker-artifacts, kunnen we met vertrouwen omgaan met de complexiteit van CI/CD. Zo leveren we alle nieuwe features en fixes zo efficiënt en betrouwbaar mogelijk af bij de gebruikers.

Hotfixes

We hebben het nog niet gehad over hotfixes. Zoals ik al zei, verdient dit een eigen post. Je leest hier alles over hotfixes en de valkuilen die daarbij komen kijken.

Hotfixing with Docker Artifacts in a Single Branch StrategyMaster hotfixes in Kubernetes with Docker. Learn to rapidly deploy critical fixes in a CI/CD pipeline focusing on streamlined branching. Perfect for tackling urgent issues without disrupting flow. Dive in now. All Subjects MatterRemco Loup.

Inleiding

Ik leerde over Scrum lang voordat de manifest-update van 2020 er was. Toen we na die release van 2020 een Scrum Master-training volgden, hadden we een leuke discussie over de verandering die sinds de update van de Scrum Guide de meeste impact op mij heeft gehad.

De verschuiving van één inspecteerbaar werkend artifact aan het einde van een sprint, naar veel vaker releasen binnen de sprint zelf. Dat is een goede ontwikkeling, want we leven in een CI/CD-wereld en iets vasthouden als het Done is, is niet nodig.

Mijn probleem ermee is dat het de focus weghaalde bij wat ik wist over wat een Sprint Review was. En dat zette me aan het denken.

Wat meer achtergrond

Voor ons team betekent de status “Done” dat een feature klaar is voor deployment. Dat wil niet zeggen dat we overhaast releasen; ingrijpende wijzigingen worden zorgvuldig afgewogen, zodat ze aansluiten bij de wensen van gebruikers en bredere doelen. Elke update wordt grondig gecontroleerd, waarbij onze Product Owner een sleutelrol speelt en de release afstemt op de zakelijke belangen.

Met een goede CI/CD-implementatie kan je team vergeten dat een update al is gereleased zodra die in onze staging-omgeving staat. Wanneer we de trekker overhalen en live gaan, is aan de business. Het team moet wel weten wanneer iets volledig is gereleased, want we houden mogelijke problemen ook in de gaten. Maar de Developers zouden geen belang bij de daadwerkelijke release moeten hebben. Ik snap dat dit wat meer uitleg verdient. Dat bewaren we voor een toekomstige post.

In onze DONE-lane houden we DONE-nog-niet-gereleased en DONE-gereleased apart.

Onze mini-Sprint Reviews

Om het scherp te formuleren: onze feature-releases lijken vaak op een reeks “mini-Sprint Reviews”

Er is een uitgebreide discussie over wijzigingen en mogelijke gevolgen.

Deployment-momenten worden strategisch gepland.

Gedetailleerde changelogs worden samengesteld.

Stakeholders worden op de hoogte gehouden en hun feedback wordt na de release actief opgevraagd.

Door deze grondige aanpak zijn de grote gesprekspunten vaak al behandeld tegen de tijd dat onze Sprint Review eraan komt.

Dat haalt een aantal onderwerpen weg uit de Sprint Review. Zeker als je een goede CI/CD-pipeline hebt en vaak releaset.

Als je updates vóór het einde van de sprint bespreekt en live zet, en je de feedback op de gereleasde features al binnenkrijgt — waarom zou je mensen dan nog een keer om feedback of een discussie over die release vragen? Scrum is een framework dat gesprekken mogelijk maakt. Maar er moet wel waarde in die meetings zitten. En voor ons is de Sprint Review over dit onderwerp behoorlijk nutteloos geworden.

Wat bespreken we dan?

Je zou je kunnen afvragen: met zo’n grondige evaluatie vóór de release, wat blijft er dan over voor de Sprint Review? We zijn onze aanpak nog aan het verfijnen, maar dit is onze huidige structuur

Toetsen of we het sprintdoel hebben gehaald.

Analyseren welke taken in de sprint onaangeroerd zijn gebleven.

Dieper ingaan op lopende development-items.

Het backlog bijstellen naar aanleiding van veranderingen uit de afgelopen sprint, zodat komende sprints duidelijke prioriteiten hebben.

Proactief nieuwe taken of aanpassingen identificeren op basis van recente lessen.

Stakeholders betrekken voor gedetailleerde feedback waar dat nodig is.

Zo werken biedt ons een paar duidelijke voordelen. Onze stakeholders zitten in alle afdelingen van ons bedrijf. Veel van hen werken hybride of zelfs 3/4 dagen in een hybride combinatie. Door frequent te releasen en ons plannen daarop aan te passen, bespreken we de release op een moment dat ze op kantoor zijn, en dat werkt voor ons gewoon het beste. De mogelijkheid om dingen face to face te bespreken is van onschatbare waarde. Het werkt gewoon beter en zorgt voor meer begrip tussen elkaar.

Onze reviews vallen traditioneel op vrijdag. Dat is geen probleem, want we kunnen de stakeholder gewoon op elke dag dat we klaar zijn een seintje geven. De update bespreken. En live gaan. We hoeven hier niet zo’n drama van te maken. We hebben korte feedbackloops! Vreselijke meetings inplannen is iets voor trage, grote bedrijven waar iedereen denkt dat hij belangrijk is en alles vastloopt in bureaucratie.

In de meeste van onze Sprint Reviews bespreken we niets over wat we hebben gedeployd. We inspecteren de increment niet. De increment is al geïnspecteerd en we gaan snel door naar de andere onderwerpen die hierboven staan.

Conclusie

Een paar essentiële elementen sturen deze aanpak van ons aan.

Een Product Owner met echte beslissingsbevoegdheid, die de afstemming op bredere zakelijke doelen garandeert.

Je hebt een Scrum-team nodig dat strak samenwerkt om volledige stories of features af te ronden. Ze écht DONE krijgt. Je hebt FLOW in je team nodig om dit voor elkaar te krijgen.

Je hebt een goede CI/CD-omgeving nodig waarin je geautomatiseerd en vaak kunt deployen. (Daar werken we zelf nog aan. We zijn geautomatiseerd, maar nog niet genoeg. Er kan nog veel meer handwerk uit.)

Scrum blijft zich ontwikkelen, en onze werkwijze ook — altijd met waarde en efficiëntie voorop.

Inleiding

Allereerst dit.

Opinions are like assholes. Everybody has one…

Ik laat het daarbij, maar er zijn genoeg varianten op dit citaat. Lees dus gerust met een gezonde dosis scepsis verder.

Het woord “Sprint”

Ik blijf er moeite mee hebben om het woord Sprint te gebruiken voor elke cyclus van twee weken, elke keer als ik nadenk over wat het woord voor mij betekent. Deze sprints stoppen nooit! Het moment waarop een sprint eindigt, begint een nieuwe sprint…

In het echte leven kun je op z’n minst even op adem komen en slapen voordat je naar de volgende sprint vertrekt. En nee, een retro is niet goed genoeg. (SCRUM-politie) Een nieuwe sprint begint op het moment dat een sprint eindigt! De retro valt ook binnen een sprint. (/SCRUM-politie)

Nederlands is mijn moedertaal, dus mijn interpretatie van het woord sprint kan verschillen. Voor mij staat een sprint voor: zo hard mogelijk gaan om als eerste te finishen. Natuurlijk houd je je aan de regels die je niet diskwalificeren. Maar elke keer als ik aan een Sprint denk, komt het woord “haast” in me op. Afmaken, wat er ook gebeurt. Die betekenis geeft een gevoel van haast, en dat levert geen schonere code of minder technische schuld op.

Na een echte sprint weet ik dat ik fysiek niet in staat ben om direct weer een sprint te starten. Wil je als team in een flow komen, dan moet je juist stoppen met rennen en het gesprek aangaan met elkaar. Neem de tijd om te zorgen dat iedereen op één lijn zit en hetzelfde doel ziet.

SCRUM is toch vooral een framework dat gesprekken faciliteert?

Het woord “Sprint” betekent voor mij ook individualiteit. En dat is ongewenst als je een SCRUM-team bent dat samen in een flow wil komen.

Achieving FLOW with Scrum.In this post I share my current journey of implementing Scrum and Kanban principles with my team, this is mainly about emphasizing the importance of real collaborative work and instilling a product vision which helps us to achieve FLOW which translates to high value Scrum for us. All Subjects MatterRemco Loup.

Gewoon een beetje stoeien met ideeën, maar het een estafette noemen zou misschien beter zijn! Dat roept ook overdracht en teamwork met elkaar op. Het resultaat is voor het hele team hetzelfde, net als bij een echte estafette. Maar ook hier speelt het aspect haast een rol.

Je hoeft de naam natuurlijk niet te veranderen, maar dit onderwerp met je team bespreken kan wél! Bespreek het samen met je DOD, Acceptance Criteria en Sprint goal. Zorg in elk geval dat iedereen begrijpt dat je het gehaaste aspect dat bij het woord sprint hoort niet wilt. Doe het liever zo goed mogelijk, volgens alle afgesproken regels. In plaats van stiekem de hoeken afsnijden in een grijs gebied waar niemand je ziet!

Verander die naam!

En als we een andere naam nodig hebben, wat dacht je van Development Cycles? Dan kunnen we het Cycles noemen, zoals Linear doet. Of noem het Flows. Voor onze Flow van twee weken heb ik deze Flow goal in gedachten.

Om een naamswijziging te laten werken, moeten we het er allemaal over eens zijn dat we die naam gebruiken. Tools zoals Jira leggen veel van deze namen al vast en die zijn niet aan te passen. Wij als development team zitten met de wind mee: Jira wordt bij ons alleen gebruikt voor onze backlog en administratie. Maar ons fysieke Scrum board is onze single source of truth voor wat we proberen te bereiken.

Onze sprints worden alleen op een hoger niveau in Jira geregistreerd. Alle dagelijkse taken die uit de sprint planning voortkomen, staan niet in ons Jira.

A journey into visual ScrumIn this post, I will share the experiments we conducted during the last three sprints with our physical Scrum board. The focus was about creating a better understandable visual representation of our sprint progress. Sprints are two weeks increments for us at this moment. All Subjects MatterRemco Loup.

Verander die naam niet!

Het woord “Sprint” zelf is voor mij eigenlijk geen probleem. Maar het woord roept wel dingen op die ik niet wil hebben in onze sprints.

We willen geen individualiteit in onze sprints.

We willen geen hoeken afsnijden in sprints.

We willen niet als eerste finishen ten koste van andere aspecten in sprints.

We moeten scherp blijven op het verfijnen van onze DOD en het gebruiken van de juiste Acceptance Criteria bij onze issues om de kwaliteit hoog te houden. En het allerbelangrijkste: definieer elke sprint een goede Sprint goal en maak die tastbaar. Een andere naam voor sprints verandert daar niets aan. Wij als team moeten het laten gebeuren: kwaliteit boven snelheid.

Een woord als “Sprint” veranderen betekent niets als je geen omgeving creëert waarin “haast” en “gejaagd” geen woorden zijn die de werkethiek beschrijven. Een sprint is gewoon een development cycle van x weken die iedereen begrijpt, en zou helemaal niets met haast te maken moeten hebben.

Inleiding

Ik ben al een tijdje gefascineerd door het idee om een bedrijf om te vormen tot een DAO (Decentralized Autonomous Organization). Toen ik nadacht over mijn rol als Product Owner, bedacht ik een aanpak die heel goed kan werken bij het omvormen van een deel van ons bedrijf naar een DAO. Zo combineren we de voordelen van Scrum, Agile en een DAO.

In mijn persoonlijke geval hieronder is een hybride aanpak het meest voor de hand liggend: bepaalde onderdelen van ons bedrijf worden door een DAO beheerd, terwijl de rest voor nu onder traditioneel management blijft. Mijn DAO zou worden gebruikt om ons Front/Mid/Backoffice-systeem, BOSS, te beheren en beslissingen te nemen over wat we hierna ontwikkelen. De bredere organisatie blijft voorlopig op de gebruikelijke manier draaien. Zo profiteert ons bedrijf van de voordelen van een DAO, terwijl we een deel van de risico’s en uitdagingen afdekken.

Ons doel is om dit systeem tot een SaaS-product binnen de reisbranche te ontwikkelen. En een DAO kan bijvoorbeeld worden ingezet om onze stakeholders te betrekken. Maar daar lees je verderop meer over.

Wat is een DAO?

Een DAO, of Decentralized Autonomous Organization, is een organisatievorm die wordt gerepresenteerd door regels die als computerprogramma zijn vastgelegd (een zogenaamd smart contract). Die regels zijn transparant, worden gecontroleerd door de leden van de organisatie en staan niet onder invloed van een centrale autoriteit.

De financiële transacties en regels van een DAO liggen vast op een blockchain, een vorm van gedistribueerd grootboek. Daardoor is een DAO volledig autonoom en onafhankelijk van externe of gecentraliseerde controle.

Zie het als een digitaal bedrijf, waarbij alle regels en verordeningen in een smart contract zijn gecodeerd. Stel dat er in een DAO een regel is dat een bepaald voorstel 60% van de stemmen nodig heeft om aan te nemen. Die regel zit in het smart contract, en de blockchain zorgt dat de regel strikt wordt nageleefd. Niemand kan hem manipuleren of omzeilen.

Leden van een DAO kunnen beslissingen nemen over de regels of de richting van de organisatie door voorstellen te doen en erop te stemmen. Iedereen heeft stemrecht naar evenredigheid van zijn stake of aandelen in de DAO. Zo lijkt een DAO een beetje op een traditioneel bedrijf, maar dan volledig democratisch en gedecentraliseerd geleid.

Een DAO gebruikt blockchain-technologie om te zorgen dat de organisatie volkomen transparant, democratisch en gedecentraliseerd wordt bestuurd, vrij van centrale of externe controle.

Tokens

Een uniek token creëren voor een DAO kan nuttig zijn en is een gangbare praktijk. Of het de “beste” praktijk is, hangt af van de doelen en context van de DAO. Dit is waarom DAO’s vaak hun eigen tokens uitgeven:

1. Stemrecht: Tokens kunnen stemmacht binnen de DAO vertegenwoordigen. Hoe meer tokens een lid heeft, hoe meer invloed diegene heeft op de beslissingen van de DAO.
2. Incentives: Tokens kunnen worden gebruikt om bepaald gedrag of bijdragen aan de DAO te stimuleren. Zo kun je tokens geven als beloning voor taken die de DAO verder helpen, zoals programmeren, ontwerpen of projecten managen.
3. Fondsenwerving: Tokens uitgeven kan een manier zijn om geld op te halen. Deelnemers kunnen tokens kopen en worden daarmee in feite investeerders in de DAO.
4. Community-opbouw: Een uniek token kan het gemeenschapsgevoel onder leden versterken. Het bevordert een gevoel van gedeeld eigendom en gezamenlijke investering in het succes van de DAO.

Er zijn echter ook uitdagingen en aandachtspunten:

1. Regelgeving: Afhankelijk van de jurisdictie kan het uitgeven van een token worden gezien als het uitgeven van een security, met implicaties voor regelgeving en juridische vereisten.
2. Tokenverdeling: Bepalen hoe je de tokens aanvankelijk verdeelt, is lastig en kan tot discussie leiden. De verdeling moet eerlijk zijn en aansluiten bij de doelen en waarden van de DAO.
3. Schommelende tokenwaarde: Als het token op de open markt wordt verhandeld, kan de waarde schommelen, wat kan leiden tot instabiliteit en mogelijke manipulatie.
4. Complexiteit: Een token uitgeven en beheren maakt het runnen van de DAO complexer. Niet elke DAO heeft een eigen token nodig, zeker als de operaties simpel zijn of als een bestaand token goed kan worden gebruikt.

Hoe benut je een DAO als Product Owner

Stel je voor dat je een DAO runt waarin klanten of geïnteresseerden direct in je product kunnen investeren. Ze krijgen stakes of tokens, waarmee ze een stem krijgen in je ontwikkelproces, dat volgens Scrum/Agile verloopt.

Zeg dat deze potentiële klanten een specifieke functie, X of Y, in je product willen. Dan kunnen ze met hun tokens op die functie stemmen en zo direct de ontwikkelprioriteiten beïnvloeden. Dit stemmechanisme trekt potentiële klanten dichter naar je merk en geeft bestaande klanten de kans om het product dat ze dagelijks gebruiken zelf vorm te geven.

In feite worden de functies die bovenaan hun wensenlijst staan het focuspunt van je ontwikkelstrategie. Het mooie van deze aanpak is de transparantie. Door gebruikers te laten stemmen over mogelijke uitbreidingen van je product, laat je zien waarom bepaalde functies voorrang krijgen boven andere. Het is een democratie waarin je pas kunt stemmen als je het “waarom” achter elke beslissing kent. Dat leidt tot een gedetailleerd begrip van hoe het product evolueert.

Deze aanpak is een zegen, niet alleen voor Product Owners maar ook voor je organisatie als geheel. In plaats van je ontwikkelproces geheim te houden, nodig je je gebruikers uit om er deel van uit te maken. Zo’n participatieve aanpak kan sneller vertrouwen opbouwen bij klanten en potentiële gebruikers dan traditionele methoden.

Als Product Owner blijf je onmisbaar bij het filteren en interpreteren van klantwensen, en het omzetten daarvan in begrijpelijke stories die zowel technische als niet-technische mensen snappen.

Als het tijd is om de topprioriteiten te kiezen, staat je roadmap al uitgestippeld door de democratische stemming. Deze interactie laat je sneller met je klanten in gesprek komen en van ze leren dan wanneer je personas of andere traditionele tools gebruikt om te bepalen wat er komt. Meerderheidsbesluiten kunnen je sprintdoelen bepalen en zo je focus voor de volgende ontwikkelcyclus sturen.

Wat is een betere manier om transparantie en klantinput te stimuleren dan Agile/Scrum op deze manier in te zetten? Dit proces integreert de principes adapt, inspect en learn op een nauw verbonden manier. Met een DAO-achtige aanpak wordt de evolutie van je product echt een community-gedreven onderneming.

Kanttekeningen

Er zijn natuurlijk ook kanttekeningen.

1. Governance-uitdagingen: Het implementeren van het governance-model van een DAO kan complex zijn. De belangen van alle stakeholders op een eerlijke en evenwichtige manier balanceren is een flinke uitdaging. Het is niet altijd zo dat de beslissing van de meerderheid aansluit bij het belang van het project of van alle stakeholders.
2. Beveiliging van smart contracts: DAO’s werken op basis van smart contracts, die onveranderbaar zijn zodra ze gedeployd zijn. Zit er een bug of kwetsbaarheid in het contract, dan kan dat tot serieuze problemen leiden, waaronder verlies van fondsen. De beruchte “The DAO”-hack van 2016, waarbij 50 miljoen dollar werd weggesluisd via een loophole in een smart contract, is daar een voorbeeld van.
3. Onduidelijke regelgeving: DAO’s bestaan in veel rechtsgebieden in een juridisch grijze zone. Hoe ze juridisch worden geclassificeerd en gereguleerd, is in veel delen van de wereld nog onduidelijk.
4. Token-distributie: Hoe tokens aanvankelijk worden verdeeld, kan ook een complexe kwestie zijn. Als dat niet goed gebeurt, kan het leiden tot centralisatie of een machtsonevenwicht binnen de DAO.
5. Lage participatie: DAO’s zijn afhankelijk van actieve deelname van token-houders. Lage opkomst kan echter een groot probleem zijn, waardoor beslissingen door een kleine groep stakeholders worden genomen.
6. Kortetermijndenken: Er is een risico dat token-houders die alleen in kortetermijnwinst geïnteresseerd zijn, stemmen op voorstellen die direct rendement opleveren maar op lange termijn schadelijk zijn.
7. De interface tussen DAO en de echte wereld: DAO’s zijn digitaal, maar hun beslissingen hebben vaak gevolgen in de echte wereld, waar handhaving complexer kan zijn.

Elk van deze uitdagingen is te overwinnen, maar ze vergen wel zorgvuldig nadenken en een doordacht ontwerp om ze effectief aan te pakken. Zoals bij elk systeem moet je de voordelen altijd afwegen tegen de mogelijke risico’s en nadelen.

De rol van een Product Owner

Hier komt een goede Product Owner om de hoek kijken: die zorgt ervoor dat mensen niet over je hele backlog stemmen, maar over zorgvuldig geselecteerde items die al voldoende gerefined zijn en klaar staan om tot op een zekere mate van onzekerheid ontwikkeld te worden. Je wordt nog steeds geacht de totale markt te kennen, zodat je de items om aan te pakken voorselecteert en mensen er vervolgens op laat stemmen.

Je hebt nog steeds stakeholders die je tevreden moet houden en features moet ontwikkelen die de markt het liefst wil. Alleen door een DAO te gebruiken en mensen betrokken te houden, kun je je markt veel beter leren kennen en je erop aanpassen dan op andere manieren.

Ook al is een DAO fundamenteel democratisch, het heeft iemand nodig met een volledig begrip van het product om de ontwikkeling te sturen. Een PO kan inzicht geven in de haalbaarheid en impact van features, en zo besluitvorming en prioritering helpen sturen.

Smart contracts

Een smart contract is een computerprotocol dat het onderhandelen over of uitvoeren van een digitaal contract faciliteert, verifieert of afdwingt. Smart contracts draaien op de blockchain, wat ze transparant, traceerbaar en onomkeerbaar maakt. Ze zijn ontworpen om automatisch transacties of andere specifieke acties uit te voeren zodra vooraf ingestelde voorwaarden zijn vervuld.

Dit zijn een paar belangrijke redenen waarom het belangrijk is om smart contracts zorgvuldig te ontwerpen en te implementeren:

1. Onveranderlijkheid: Zodra een smart contract op de blockchain is gedeployd, kan het niet meer worden aangepast of gecorrigeerd. Door die onveranderlijkheid is het cruciaal dat een smart contract grondig wordt getest en gereviewd vóór de deployment, zodat het doet wat het moet doen.
2. Security: Smart contracts zijn gevoelig voor bugs en exploits als ze niet correct geprogrammeerd zijn. Gezien de waarde die er vaak via smart contracts wordt verhandeld of beheerd, is security van het grootste belang. Exploits kunnen tot aanzienlijke verliezen leiden, zoals bij de beruchte DAO-hack in 2016, waarbij er zo’n $50 miljoen verloren ging door een bug in het smart contract van de DAO.
3. Financiële gevolgen: Smart contracts beheren, bewaren of faciliteren vaak de overdracht van cryptocurrency, en fouten of kwetsbaarheden in het contract kunnen aanzienlijke financiële gevolgen hebben.
4. Vertrouwen en betrouwbaarheid: Het vertrouwen in een smart contract, en daarmee in de hele operatie of het systeem dat het ondersteunt, hangt sterk af van het feit dat het contract werkt zoals verwacht. Problemen kunnen de waargenomen betrouwbaarheid van het systeem aantasten en mensen afschrikken om deel te nemen of het te gebruiken.
5. Complexiteit en interoperabiliteit: Smart contracts werken vaak samen met andere contracten of systemen. Het is belangrijk om die interacties goed door te denken om onverwacht gedrag te voorkomen. Wie de complexiteit van zulke interacties niet begrijpt of negeert, kan schadelijke gevolgen tegemoet gaan.
6. Wet- en regelgeving: Afhankelijk van de jurisdictie en de specifieke use case moeten smart contracts zo worden ontworpen dat ze voldoen aan de relevante wet- en regelgeving. Dat voegt weer een extra laag complexiteit toe aan het ontwerp en de implementatie.

Het ontwerp, de implementatie en de review van smart contracts moeten dus uiterst serieus en zorgvuldig worden aangepakt. In veel gevallen is het verstandig om smart contracts vóór de deployment te laten auditen door een gespecialiseerd securitybedrijf.

Een geschreven voorbeeld van een Smart Contract

Je hebt dus vooraf een goed werkend contract nodig. De Product Owner kan bijvoorbeeld de beheerder van zo’n smart contract zijn. Hij voegt de issues toe aan het systeem, en de stakeholders kunnen met hun tokens op die issues stemmen.

Elke stem verhoogt het belang van de issues die ontwikkeld moeten worden. Daarna kies je de issues met de hoogste ranking om aan te werken, met in je achterhoofd wat je in één sprint kunt doen.

Je kunt bijvoorbeeld ook met twee soorten tokens werken. Gewone tokens voor je klanten die je product gebruiken, en sociale tokens voor bijvoorbeeld potentiële klanten.

Ook de geldigheid van tokens is iets om over na te denken, want wensen kunnen na verloop van tijd verouderd raken.

Dit kan allemaal behoorlijk complex worden, en misschien post ik in een later blog een volledig voorbeeld van een smart contract in Solidity met de bovenstaande voorwaarden.

Conclusie

Dit is een wat langer artikel geworden dan gebruikelijk, maar er was veel uitleg nodig om te begrijpen wat het betekent om je rol als PO in te zetten binnen een DAO.

Ik hoop dat dit een beetje helpt om te verduidelijken wat een DAO is en hoe je die kunt gebruiken, vooral vanuit het perspectief van een SCRUM/Agile Product Owner, waar beide echt kunnen gedijen.

Francois Fort schreef hier een artikel over op scrum.org: Are DAOs the future of Agile Organisations.

Je hebt stakeholders nodig die achter je plannen staan, en wat is beter dan betrokken stakeholders die een aandeel hebben in je product via een DAO? Je krijgt gedetailleerde en directe reacties van de markt als je een betrokken, gevarieerde groep mensen hebt die wil dat je product slaagt, want dan slagen zij zelf ook.

Inleiding

Zonder een “goede” SME (subject matter expert)-stance is elk product een slechter product dan het kan zijn.

Dat is de bom die ik hier aan het begin laat vallen.

Er zitten natuurlijk nuances in deze stelling. Hieronder leg ik uit waarom dit naar mijn mening klopt. Als SME geef je om je product, vind ik. Waarom zou je er anders zoveel van weten? En al die informatie paraat hebben? Ik vergeet dingen waar ik niet om geef… dus ik moet wel om ons product geven.

De nuance vinden binnen een SME

De struggle is dat je jezelf moet leren hoe je reageert als je onzeker bent of ernaast zit. Koppig zijn omdat je bang bent om te falen is de verkeerde insteek voor deze stance. Je moet anderen ook de kans geven te leren wat jij misschien al weet. Misschien komen er zelfs nieuwe inzichten naar boven! Een antwoord dicteren zorgt er niet voor dat ze het accepteren; dat doen ze pas als ze er zelf achter komen. En nog belangrijker: het team wordt er niet slimmer van als ze dingen niet zelf uitvogelen. Het hele team moet er beter van worden, niet alleen jij.

Dat vraagt om tact en het juiste moment om in bepaalde discussies in te grijpen. Je wilt zo’n discussie niet leiden, maar hem op een natuurlijke manier de juiste kant op sturen op het moment dat het nodig is. En onthoud: er is altijd nog de mogelijkheid dat jij er inderdaad naast zit!

Een “goede” subject matter expert

Een SME zijn is verdomd handig als je de positieve kanten van een subject matter expert goed benut. Daarom is dit voor mij een van de meest interessante en miskende stances van een Product Owner. Je kunt als SME volledig de mist in gaan (miskend) of volledig goed zitten. Op een positieve manier, zonder dat je jezelf elke keer weer met alles bemoeit. En daar moet je de nuance vinden in je rol als Product Owner met een SME-mindset. Als je de details van iets weet, leg dan ook de WAAROM uit aan het team. Blijf ze betrekken in plaats van de wijsneus uit te hangen.

Beperkingen

Het komt allemaal neer op je beperkingen kennen en daar eerlijk over zijn. Je weet veel, maar niet alles, en de wereld evolueert, dus dingen kunnen inmiddels anders liggen. Voor mij betekent dit dat ik mijn mond houd als ik het niet zeker weet. En soms geef ik mijn visie op waarom we vroeger een bepaalde keuze hebben gemaakt, maar moedig ik iedereen aan om het vandaag de dag opnieuw uit te zoeken, want het probleem van toen is misschien geen probleem meer. En je leert altijd van dit soort dingen, ook al is de uitkomst hetzelfde.

Het is een goede praktijk als er iemand is die context geeft bij de keuzes uit het verleden, zonder in een bepaalde richting te sturen. Ik denk dat uitleg op deze manier veel waarde heeft.

Een analogie

Het product dat we als team hebben ontwikkeld begon als mijn kind. De visie kwam van mij. Het duurde twee jaar voordat we bevelden. En na die bevalling van twee jaar hebben we als team de handen ineengeslagen om ons kind zo goed mogelijk op te voeden. Dat gaf veel hoofdbrekens, maar het bracht ons ook zoveel: leren en ons aan elkaar aanpassen. We begonnen allemaal om dit kind te geven.

Hoe kan ik daar geen SME voor zijn? Ik ben degene die met het oorspronkelijke idee kwam. Ik was erbij toen ons kind na twee jaar intensieve ontwikkeling geboren werd. Ik was er tijdens de hele jeugd bij, zag het opgroeien en volwassen worden. En ook al is het inmiddels volwassen, ons kind heeft nog steeds af en toe sturing en hulp nodig. Het blijft immers mijn kind. Dat er steeds meer mensen echt om dit kind zijn gaan geven, verandert niets aan mijn gevoel voor ons product.

Verspreid de liefde voor je product over je team. Houd het niet voor jezelf. Maak het als team beter.

Conclusie

Ik kan er niets aan doen dat ik nog bijna elke keuze herinner die we in het verleden voor ons product hebben gemaakt. En ook waarom we die keuze binnen onze development cycles hebben gemaakt. Ik kies er niet per se voor om die wijsneus te zijn, maar dit onderwerp interesseert me en daarom onthoud ik het. Ik moet anderen wel ruimte geven voor hun eigen gedachten. Dus ja, ik herken mezelf in een subject matter expert, tot op zekere hoogte zelfs volledig.

Je moet wel weten/voelen WANNEER je een discussie instapt. Ga niet elke discussie in als de wijsneus. Dit klinkt misschien cocky of arrogant. Maar we willen allemaal hetzelfde, en dat is een beter product afleveren dan het al was. Als we respectvol met elkaar blijven praten zonder de wijsneus uit te hangen, zitten we als team op het juiste spoor.

En weer! Blijf de WAAROM’s uitleggen en zeg wat je denkt. Betrek je team bij beslissingen en bij de uitleg van keuzes uit het verleden. Samen vorm je een team met alle mensen, niet alleen als PO/SME.

Disclaimer: hoewel ik hier één van de stances van de Scrum Master uitlicht, is het juist de combinatie van alle stances die je een betere Product Owner maakt. Dit is gewoon één stance die mij interesseert, omdat het een vaak verkeerd begrepen stance is (en met een goede reden). Zonder een heldere Vision en zonder de andere stances te “zijn”, heb je het als Product Owner zwaar voor je kiezen.

Introductie

In deze post deel ik de experimenten die we de afgelopen drie sprints hebben gedaan met ons fysieke Scrum board. De focus lag op een beter begrijpelijke visuele weergave van onze sprintvoortgang. Sprints zijn voor ons op dit moment blokken van twee weken.

Ons Scrum board zoals het nu is

De afbeelding hieronder laat het board zien dat we bijna een jaar gebruiken. Toen we Scrum serieuzer gingen nemen, merkten we dat dit board aan transparantie tekortkomt.

Op dit board hebben we al veel van de eerdere problemen opgelost. Die verbeteringen leg ik uitgebreid uit in een eerdere post: Our sprints in real life.

Om onze reis beter te begrijpen is “Achieving FLOW with Scrum” ook een must-read. Die post duikt in onze achtergrond en, belangrijker nog, beantwoordt de vraag: waarom doen we dit eigenlijk?

Dit zijn de lanes en de opzet die we op dit moment gebruiken. De laatste twee (Testing en Done) hebben we gesplitst voor meer transparantie binnen onze huidige CI/CD-opzet. Hieronder een lijst met dingen die we al getest hebben en dus op dit board zijn doorgevoerd. Deze verbeteringen blijven we meenemen bij het experimenteren met nieuwe versies van ons board.

Het sprintdoel is duidelijk zichtbaar.

We gebruiken groene kaartjes voor de items die bijdragen aan het behalen van het sprintdoel.

Taken die te lang in testing staan markeren we met een visueel uitroepteken.

In onze Done-lane gebruiken we “released” en “not yet released”, zodat DOD-items die nog niet gedeployd zijn zichtbaar blijven voor het Scrum team.

De volgorde van ons werk staat op het board in de Todo-lane van boven naar onder. Bovenaan betekent eerst, tenzij er een goede reden is om niet in die volgorde te werken :)

Andere taken uit onze sprintcommitment markeren we blauw.

Willekeurige bugfixes en mogelijke hotfixes die tijdens een sprint opduiken, markeren we rood. Die gaan onderaan het board. Ze kunnen belangrijk zijn, maar ze kwamen tijdens een sprint naar boven en staan daarom onderaan de “TODO”-lane.

Subtasks worden altijd op dit board gedefinieerd. Ze zijn er voor de developers om het werk te doen waarmee de volledige story wordt opgeleverd. Ze kunnen in Jira staan, maar het fysieke board is leidend.

We gebruiken naamkaartjes om te laten zien wie waaraan werkt.

De reden dat we zijn gaan experimenteren met andere boardopzetten, hieronder te vinden, is dat we stories steeds vaker gingen opsplitsen in subtasks. Maar als een developer een subtask afrondde, wilden we die niet direct van het board halen, om een heleboel verschillende redenen.

Een subtask weghalen zorgt voor minder transparantie en voor minder gesprekken over afgeronde subtasks.

Het geeft developers die niet op kantoor waren (vrij) inzicht in afgeronde taken als ze de volgende dag binnenkomen.

Het belangrijkste punt was het gebrek aan transparantie dat dit board nog steeds had rond subtasks!

Het voelt ook bevredigender om een afgeronde subtask naar een vaste plek op het board te verplaatsen. Neerpleuren en verder. Dat geeft een gevoel van afronding. Dat gevoel krijg je niet als je wat je net hebt afgerond direct weghaalt, schoonmaakt en uitwist.

In de eerste versie van ons board hadden we hier geen rekening mee gehouden. Soms gingen subtasks mee met de story. Op andere momenten verschoof een subtask naar de “Done”-lane. Dat is fout! Er valt niets te releasen of niet te releasen. Het is een afgeronde subtask van een branch die waarschijnlijk nog niet eens gecommit is. Deze situatie zorgde voor veel problemen op het gebied van transparantie.

Aanpassingen eerste iteratie

We zijn gaan experimenteren met het splitsen van de “Dev”-lane in een “Doing” en een “Done”. Zo konden we afgeronde subtasks in een eigen lane houden. Aanvankelijk was er wat irritatie over deze opzet. Maar het was essentieel om het uit te proberen om de effectiviteit te bepalen!

Conclusie eerste iteratie

Na twee weken met deze opzet gewerkt te hebben, is onze conclusie dat het nuttig is om een vaste plek te hebben voor “Done” subtasks. Maar die plek binnen de huidige lanes van het board is niet ideaal. Afgeronde subtasks zouden niet meer zo zichtbaar moeten zijn; nu lijkt het alsof ze nog verder naar rechts moeten.

Subtasks zelf gaan bijvoorbeeld niet naar Testing, want ze zijn onderdeel van een story die de waarde vasthoudt. Het is de story die verder beweegt naar Review, Testing en Done. Deze aanpak raden we dus niet aan.

We zijn wel overeengekomen om kaartjes weg te halen als de developers collectief vonden dat het tijd was. Maar ook die methode geeft geen transparantie, omdat er geen duidelijke regel is.

Aanpassingen tweede iteratie

Samen kwamen we met een nieuwe versie van het board. Ook deze versie staat op de afbeelding hieronder.

We zijn teruggegaan naar de lanes zoals we die aan het begin van dit experiment hadden. Todo, Dev, Review, Testing en Done. De visuele weergave van Todo hebben we weggehaald en daar staat nu het sprintdoel. We waren het er allemaal over eens dat dit een betere plek is voor het sprintdoel.

We besloten ook om werk nooit boven de items te plaatsen die het behalen van ons sprint goal vertegenwoordigen. Stel dat we beginnen aan een blauw of rood item. Dat item schuift naar “Dev”, maar blijft op dezelfde horizontale lijn staan waar het oorspronkelijk lag. Vanaf nu willen we items dus horizontaal uitgelijnd houden terwijl ze door de lanes bewegen. De enige uitzondering is de Done lane, die is verdeeld in secties voor gereleased en nog niet gereleased werk.

De “Burn Pile” is een naam die we zelf verzonnen hebben voor alle afgeronde subtasks. We wilden voorkomen dat we twee “Done” lanes kregen. Het is gewoon bevredigend om de subtasks die je net hebt afgerond op deze plek te leggen! Deze aanpak geeft niet alleen een gevoel van afronding, maar laat ook zien wat er allemaal als subtask is afgerond.

Conclusie tweede iteratie

Dit is de eerste iteratie van onze “Burn Pile”-versie. We hebben al wat andere overwegingen besproken om deze versie uit te proberen.

Misschien moeten we voor de transparantie een verwijzing naar het story toevoegen. Of bijvoorbeeld dezelfde subtasks van een story bij elkaar groeperen.

We leren van deze ervaring door het gewoon in de praktijk te brengen. Het is belangrijk om dingen niet meteen onnodig ingewikkeld te maken. Zoals je op de screenshot ziet, hebben we al wat subtasks in de Burn Pile gelegd, en we zijn het er allemaal over eens: het voelt goed om dat fysiek te doen.

Conclusie

We hebben besloten dat we voorlopig met deze versie van het bord verder gaan. De eerste iteratie werkte niet goed: te veel lanes, te veel ruimte, twee Done lanes, en subtasks die na afronding te lang zichtbaar bleven.

Vanaf nu gebruiken we dus deze versie. Ik blijf deze post updaten telkens als we verbeteringen vinden in ons werk met dit bord.

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!

Our sprints in a real life exampleThis post explains how we as a team manage our current Board on which we keep our sprints. This board is leading over Jira we love working analog next to our digital work. All Subjects MatterRemco

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.