kanban

Agile softwareontwikkelingsteams kunnen tegenwoordig dezelfde JIT-principes gebruiken door de hoeveelheid werk in uitvoering (WIP) af te stemmen op de capaciteit van het team. Dit geeft teams meer flexibele planningsopties, snellere output, duidelijkere focus, en transparantie gedurende de hele ontwikkelingscyclus.

Hoewel de kernprincipes van het framework tijdloos en van toepassing zijn op bijna elke branche, zijn het met name softwareontwikkelingsteams die bijzonder succesvol zijn geweest met de agile aanpak. Voor een deel komt dit omdat softwareteams aan de slag kunnen met weinig tot geen overhead zodra ze de basisprincipes begrijpen. In tegenstelling tot het implementeren van kanban op een fabrieksvloer, wat veranderingen in fysieke processen en de toevoeging van substantiële materialen met zich meebrengt, zijn de enige fysieke dingen die een softwareteam nodig heeft een bord en kaarten, en zelfs die kunnen virtueel zijn.

Het werk van alle kanban-teams draait om een kanban-bord, een hulpmiddel dat wordt gebruikt om werk te visualiseren en de stroom van het werk binnen het team te optimaliseren. Hoewel fysieke borden populair zijn bij sommige teams, zijn virtuele boards een cruciale hulpmiddel in elke tool voor agile softwareontwikkeling vanwege hun traceerbaarheid, eenvoudigere samenwerking en toegankelijkheid vanaf meerdere locaties.

Ongeacht of het bord van een team fysiek of digitaal is, hebben ze als functie om ervoor te zorgen dat het werk van het team wordt gevisualiseerd, hun workflow wordt gestandaardiseerd en alle blockers en afhankelijkheden onmiddellijk worden geïdentificeerd en afgesloten. Een eenvoudig kanban-bord is een workflow die uit drie stappen bestaat: Te doen, In uitvoering en Gereed. Afhankelijk van de grootte, structuur en doelstellingen van een team, kan de workflow echter in kaart worden gebracht om te voldoen aan het unieke proces van een bepaald team.

De kanban-methodologie is gebaseerd op volledige transparantie van het werk en realtime communicatie van capaciteit. Daarom moet een kanban-bord worden gezien als de 'Single Source Of Truth' ofwel de enige bron van waarheid voor het werk van het team.

De letterlijke vertaling van 'kanban' uit het Japans is 'visueel signaal'. Voor kanban-teams wordt elk werkitem weergegeven als een aparte kaart op het bord.

Het belangrijkste doel van het voorstellen van werk als een kaart op het kanban-bord is om teamleden in staat te stellen de voortgang van het werk door de workflow op een zeer visuele manier te volgen. Kanban-kaarten bevatten kritische informatie over dat specifieke werkitem, waardoor het hele team volledig inzicht krijgt in wie verantwoordelijk is voor dat werk, een korte beschrijving van de taak die wordt uitgevoerd, hoe lang dat stuk werk naar schatting duurt, enzovoort. Kaarten op virtuele kanban-borden bevatten vaak ook screenshots en andere technische details die waardevol zijn voor de uitvoerder. Teamleden de mogelijkheid bieden om op ieder moment de status van werkitems te zien, evenals alle bijbehorende details, zorgt voor meer focus, volledige traceerbaarheid en snelle identificatie van blockers en afhankelijkheden.

Kanban is een van de populairste methodologieën voor softwareontwikkeling die tegenwoordig door agile teams worden gebruikt. Kanban biedt verschillende extra voordelen voor taakplanning en doorvoer voor teams van elke omvang.

Een kanban-team is alleen gericht op het werk dat in uitvoering is. Zodra het team een werkitem heeft voltooid, pakken ze het volgende werkitem dat bovenaan de backlog staat. De producteigenaar kan werk in de backlog een andere prioriteit geven zonder het team te verstoren, omdat wijzigingen buiten de huidige werkitems geen invloed hebben op het team. Zolang de producteigenaar de belangrijkste werkitems bovenaan de backlog houdt, weet het ontwikkelingsteam dat ze maximale waarde terugleveren aan het bedrijf. Er is dus geen behoefte aan iteraties met een vaste lengte zoals in scrum.

Cyclustijd is een belangrijke statistiek voor kanban-teams. Cyclustijd is de hoeveelheid tijd die een eenheid werk nodig heeft om door de workflow van het team te reizen - vanaf het moment dat het werk begint tot het moment dat het wordt geleverd. Door de cyclustijd te optimaliseren, kan het team vol vertrouwen de levering van toekomstig werk voorspellen.

Overlappende skillsets leiden tot minder lange cyclustijden. Wanneer slechts één persoon een set vaardigheden bezit, wordt die persoon een knelpunt in de workflow. Teams gebruiken daarom eenvoudige best practices zoals codereview en mentoring om de aanwezige kennis te verspreiden. Gedeelde vaardigheden betekenen dat teamleden heterogeen werk kunnen aannemen, wat de cyclustijd verder optimaliseert. Het betekent ook dat als er een knelpunt is, het hele team kan meewerken om het proces weer soepel te laten verlopen. Testen wordt bijvoorbeeld niet alleen gedaan door QA-engineers. Ontwikkelaars helpen hier ook een handje.

In een kanban-framework is het de verantwoordelijkheid van het hele team om ervoor te zorgen dat het werk soepel verloopt tijdens het hele proces.

Multitasking is funest voor de efficiëntie. Hoe meer werkitems er op een bepaald moment actief zijn, hoe meer contextomschakeling er nodig is, wat het pad naar voltooiing belemmert. Daarom is een belangrijk principe van kanban het beperken van de hoeveelheid werk in uitvoering (WIP). Limieten voor werk in uitvoering benadrukken knelpunten en achterstanden in het proces van het team als gevolg van gebrek aan focus, mensen of vaardigheden.

Een doorsnee softwareteam kan bijvoorbeeld vier workflowtoestanden hanteren: Te doen, In uitvoering, Codebeoordeling en Gereed. Ze kunnen ervoor kiezen om een WIP-limiet van 2 in te stellen voor werkitems met de status Codebeoordeling. Dat lijkt misschien een lage limiet, maar daar is een goede reden voor: ontwikkelaars schrijven vaak liever nieuwe code, in plaats van tijd te besteden aan het beoordelen van het werk van iemand anders. Een lage limiet moedigt het team aan om speciale aandacht te besteden aan problemen in de beoordelingsstatus en om het werk van anderen te herzien voordat ze hun eigen codebeoordelingen verhogen. Dit verkort uiteindelijk de totale cyclustijd.

Een cumulatief stroomdiagram toont het aantal issues in elke toestand. Het team kan gemakkelijk blokkades zien aan de hand van het aantal issues dat in een bepaalde toestand is toegenomen. Problemen met tussenliggende toestanden zoals 'In uitvoering' of 'Wordt beoordeeld' worden nog niet aan klanten geleverd en een blokkering in deze toestanden kan de kans op ernstgige integratieconflicten vergroten wanneer het werk stroomopwaarts wordt samengevoegd.

Continue levering (CD) is de praktijk van het regelmatig vrijgeven van werk aan klanten. Continue integratie (CI) is de praktijk van het automatisch bouwen en incrementeel testen van code gedurende de dag. Samen vormen ze een CI/CD-pipeline die essentieel is voor ontwikkelingsteams (vooral voor DevOps-teams) om software sneller te leveren en tegelijkertijd een hoge kwaliteit te garanderen.

Kanban en CD vullen elkaar prachtig aan omdat beide technieken zich richten op de just-in-time (en een voor een) levering van waarde. Hoe sneller een team innovatie op de markt kan brengen, hoe competitiever hun product op de markt zal zijn. En kanban-teams richten zich precies daarop: het optimaliseren van de werkstroom naar klanten

Kanban en scrum delen enkele van dezelfde concepten, maar hebben heel verschillende benaderingen. Ze moeten dan ook niet met elkaar worden verward.

Sommige teams conbineren de idealen van kanban en scrum in 'scrumban'. Ze gebruiken bijvoorbeeld sprints met vaste lengte en rollen uit scrum en de focus op WIP-limieten (werk in uitvoering) en de cyclustijd uit kanban. Voor teams die net beginnen met agile, raden we echter ten zeerste aan om de ene of de andere methodologie te kiezen en er een tijdje mee te experimenteren. Je kunt altijd later nog je voorkeur uitspreken.