Kanban

Kanban-flow is de basis van agile- en DevOps-methodologieën en verhoogt de efficiëntie door probleemloze taakvoortgang te integreren met gevisualiseerde workflows. Kanban-flow is een weerspiegeling van het vereenvoudigde voorraadbeheer van supermarkten. Het zorgt ervoor dat taken precies in het ontwikkelingsproces worden verwerkt wanneer dat nodig is.

Taken worden op Kanban-borden weergegeven in de vorm van kaarten. Dit maakt het mogelijk om de voortgang op een transparante manier bij te houden en knelpunten snel te identificeren. Door het werk in uitvoering (WIP) te beperken, optimaliseren teams de toewijzing van resources en zorgen ze voor een stabiele workflow. De focus van Kanban op continue verbetering wordt mogelijk gemaakt door statistieken zoals beheerschema's en cumulatieve stroomdiagrammen. Hierdoor kunnen teams hun workflows iteratief verfijnen.

Op het gebied van softwareontwikkeling bevordert Kanban-flow dynamisch taakbeheer, versnelt het de leveringscycli en verhoogt het de klanttevredenheid door teamleden geconcentreerd en ononderbroken te laten werken. In wezen belichaamt Kanban-flow efficiëntie, een harmonieuze mix van transparantie, aanpassingsvermogen en continue verbetering. Hierbij wordt het potentieel van agile methodologieën volledig benut.

Om kanban effectief te implementeren, is het essentieel om een gestructureerde kanban-flow binnen je softwareontwikkelingsteam op te zetten. Dit zorgt voor een soepele taakvoortgang en geoptimaliseerd workflowbeheer. Zo kun je je kanban-flow structureren:

Visualiseer de workflow: Begin met het visualiseren van de workflow van je team op een kanban-bord. Het bord, fysiek of virtueel, moet elke fase van het ontwikkelingsproces weergeven, van het begin tot de voltooiing van de taak.

Standaardiseer de workflow: Definieer en standaardiseer de fasen van de workflow op basis van de processen en vereisten van je team. Veelgebruikte stappen zijn onder meer 'Te doen', 'In uitvoering' en 'Gereed', maar pas ze zo nodig aan om jouw unieke workflow weer te geven.

Identificeer blockers en afhankelijkheden: Zorg ervoor dat je kanban-bord directe identificatie van blockers en afhankelijkheden mogelijk maakt. Deze transparantie zorgt voor snelle oplossingen en voorkomt onderbrekingen van de workflow.

Stel WIP-limieten (werk in uitvoering) in: Implementeer WIP-limieten voor elke fase van de workflow om overbelasting te voorkomen en om een stabiele workflow te handhaven. WIP-limieten helpen de toewijzing van resources te optimaliseren en multitasking te verminderen, wat een hogere productiviteit bevordert.

Stimuleer samenwerking: Stimuleer een samenwerkingscultuur binnen je team, waarbij leden gezamenlijk knelpunten aanpakken en samenwerken om te zorgen voor een soepele voortgang van de workflow. Deze gezamenlijke aanpak bevordert de efficiëntie en versnelt de voltooiing van taken.

Gebruik kanban-kaarten: Geef elke taak weer als een kanban-kaart op het bord, met essentiële informatie zoals de taakbeschrijving, de uitvoerder en de geschatte voltooiingstijd. Met kanban-kaarten kun je de voortgang van taken visueel bijhouden en de transparantie binnen het team bevorderen.

Door je kanban-flow op deze manier te structureren, kun je je softwareontwikkelingsprocessen vereenvoudigen, de samenwerking tussen teams verbeteren en de efficiëntie van taakbeheer maximaliseren.

Kanban is prominent aanwezig in de huidige softwareteams van agile en DevOps, maar dat neemt niet weg dat de Kanban-methodologie meer dan 50 jaar oud is. Aan het einde van de jaren 40 begon Toyota zijn engineeringsprocessen te optimaliseren op basis van hetzelfde model dat supermarkten gebruikten om hun schappen te vullen. 

Supermarkten hebben net genoeg voorraad om aan de vraag van de consument te voldoen. Dit optimaliseert de doorstroming tussen de supermarkt en de consument. Omdat de voorraadniveaus overeenkomen met de consumptiepatronen, wordt de supermarkt aanzienlijk efficiënter in het voorraadbeheer door de overtollige voorraad die het op elk moment moet hebben te verminderen. Ondertussen kan de supermarkt er nog steeds voor zorgen dat essentiële producten altijd op voorraad zijn.

Toen Toyota hetzelfde systeem in zijn fabrieken ging toepassen, was het doel om hun enorme voorraadniveaus beter af te stemmen op het werkelijke verbruik van materialen. Om capaciteitsniveaus in de fabriek (en naar leveranciers) te communiceren, gaven werknemers een kaart, of 'kanban' tussen teams door. 

Toen iemand een bak leegmaakte met materiaal dat op de productielijn werd gebruikt, werd een kanban-kaart doorgegeven aan het magazijn waarin werd beschreven welk materiaal nodig was, de exacte hoeveelheid van dit materiaal, enzovoort. In het magazijn zou een nieuwe bak met dit materiaal klaarstaan, die ze vervolgens naar de fabrieksvloer zouden sturen en op hun beurt hun eigen kanban naar de leverancier zouden sturen. Hoewel dit proces sinds de jaren 40 verder is ontwikkeld, vormt hetzelfde 'just-in-time' (JIT) productieproces nog steeds de kern van de kanban-methodologie

.

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 flexibelere planningsopties, snellere output, duidelijkere focus, en transparantie gedurende de hele ontwikkelingscyclus.

Hoewel de kernprincipes van de Kanban-structuur tijdloos en van toepassing zijn op bijna elke branche, zijn het met name softwareontwikkelingsteams die bijzonder succesvol zijn geweest met de agile-aanpak. In tegenstelling tot het implementeren van Kanban in een fabriek, 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 taakkaarten, en zelfs die kunnen virtueel zijn.

Het werk van alle Kanban-teams draait om een Kanban-bord, een hulpmiddel dat wordt gebruikt om de workflow tussen teams te visualiseren en te optimaliseren. Hoewel fysieke borden populair zijn bij sommige teams, zijn virtuele borden van cruciaal belang in elke agile softwareontwikkelingstool vanwege hun traceerbaarheid, samenwerkingsmogelijkheden en toegankelijkheid vanaf meerdere locaties.

Ongeacht of een team een digitaal of fysiek kanban-bord gebruikt, zorgt een bord ervoor dat het team hun werk visualiseert, hun workflow standaardiseert en onmiddellijk alle blokkades en afhankelijkheden identificeert en oplost. Een eenvoudig kanban-bord heeft een workflow van drie stappen: Te doen, In uitvoering en Voltooid. Afhankelijk van de grootte, structuur en doelstellingen van een team kunnen ze de workflow echter aan hun unieke processen aanpassen.

Omdat de kanban-methodologie gebaseerd is op volledige transparantie van het werk en realtime communicatie, fungeert het kanban-bord als de enige bron van waarheid voor het werk van het team.

De letterlijke vertaling van 'kanban' uit het Japans is 'uithangbord'. Kanban-teams vertegenwoordigen elk werkitem als een aparte kaart op het bord. Het belangrijkste doel van het weergeven van werk als een kaart op het Kanban-bord is om teamleden de voortgang van het werk op een zeer visuele manier te laten bijhouden in de workflow. 

Kanban-kaarten bevatten cruciale informatie over projecttaken, waardoor teams inzicht krijgen in wie verantwoordelijk is voor welke taken. Ook bevatten de kaarten een korte beschrijving van de taken en hoe lang ze naar schatting duren. Kaarten op virtuele Kanban-borden bevatten vaak ook screenshots en andere technische details die waardevol zijn voor de uitvoerder. 

Teamleden in staat stellen om op elk moment de status van elke taak en relevante informatie te bekijken, bevordert een verhoogde focus, uitgebreide traceerbaarheid en snelle identificatie van blockers en afhankelijkheden.

Kanban is een van de meest populaire methoden voor softwareontwikkeling die agile teams tegenwoordig gebruiken. Kanban biedt extra voordelen voor taakplanning en -doorvoer voor teams van elke omvang.

Flexibele planning

Een kanban-team richt zich alleen op het werk dat actief wordt uitgevoerd. Zodra het team een taak heeft voltooid, kiezen ze de volgende taak uit de backlog. Het staat de producteigenaar vrij om werk in de backlog opnieuw te prioriteren zonder het team te verstoren, omdat wijzigingen buiten de huidige werkitems geen invloed hebben op het team. 

Zolang de producteigenaar de belangrijkste werkitems boven aan de backlog houdt, kan het ontwikkelteam er zeker van zijn dat ze maximale waarde terugleveren aan het bedrijf.

Kortere tijdcycli

De cyclustijd is een belangrijke statistiek voor Kanban-teams. De cyclustijd is de hoeveelheid tijd die een werkeenheid nodig heeft om de workflow van het team te doorlopen, vanaf het moment dat het werk begint tot het moment dat het wordt geleverd. Door de cyclustijd te optimaliseren, kan het team met vertrouwen de levering van toekomstig werk voorspellen.

Overlappende vaardigheden leiden tot kortere cyclustijden. Wanneer slechts één persoon over een aantal vaardigheden beschikt, wordt die persoon een knelpunt in de workflow. Daarom passen teams beste praktijken toe, zoals codebeoordeling en begeleiding, om zo kennis te helpen verspreiden. Dankzij gedeelde vaardigheden kunnen teamleden heterogeen werk aannemen, waardoor de cyclustijd verder wordt geoptimaliseerd. 

Bovendien stelt deze aanpak het hele team in staat om knelpunten op het werk gezamenlijk aan te pakken, waardoor een snelle oplossing wordt vergemakkelijkt en een soepele workflow wordt gegarandeerd. De verantwoordelijkheden op het gebied van testen gaan bijvoorbeeld verder dan QA-ingenieurs en omvatten ook ontwikkelaars, wat een gezamenlijke inspanning bevordert om de efficiëntie te behouden. In een Kanban-systeem zorgt het hele team ervoor dat het werk soepel verloopt tijdens het proces.

Minder knelpunten

Multitasking is funest voor de efficiëntie. Een verhoogde werkdruk leidt er tegelijkertijd toe dat er vaker van context wordt gewisseld, waardoor de voortgang van taken naar voltooiing wordt belemmerd. Daarom is een essentieel principe van het Kanban-proces het beperken van het werk in uitvoering (WIP, work in progress). Door WIP-limieten worden knelpunten benadrukt in het proces van het team, als gevolg van een gebrek aan focus, mensen of vaardigheden.

Een doorsnee softwareteam kan bijvoorbeeld vier workflowstatussen hanteren: Te doen, In uitvoering, Codebeoordeling en Gereed. Een team kan ervoor kiezen om een WIP-limiet van 2 in te stellen voor werkitems met de status Codebeoordeling. Dit lijkt wellicht 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 andermans werk. Door een lage limiet wordt het team aangemoedigd om speciale aandacht te besteden aan problemen in de beoordelingsstatus en het werk van anderen te bekijken voordat ze hun code ter beoordeling indienen. Hierdoor wordt uiteindelijk de totale cyclustijd verkort.

Visuele statistieken

Een van de kernwaarden is een sterke focus op het continu verbeteren van de efficiëntie en effectiviteit van het team bij elke iteratie van het werk. Diagrammen bieden teams een visueel mechanisme om ervoor te zorgen dat ze blijven verbeteren. 

Wanneer het team gegevens kan zien, is het makkelijker om knelpunten in het proces te herkennen (en deze te verwijderen). Twee rapporten die veel worden gebruikt door Kanban-teams, zijn controlediagrammen en cumulatieve stroomdiagrammen. Zo toont een controlediagram de cyclustijd voor elke issue en een voortschrijdend gemiddelde voor het team.

Een cumulatief stroomdiagram toont het aantal issues in elke toestand. Het team kan gemakkelijk blockers ontdekken aan de hand van het aantal issues dat in een bepaalde fase is toegenomen. Issues in tussenliggende fasen zoals 'In uitvoering' of 'Wordt beoordeeld' worden nog niet aan klanten geleverd. Een blocker in deze fasen kan de kans op ernstige integratieconflicten vergroten wanneer het werk upstream wordt samengevoegd.

Continue levering

Continue levering (CD) beschrijft het proces waarbij regelmatig werk aan klanten wordt vrijgegeven. Continue integratie (CI) is de werkwijze waarbij gedurende de dag automatisch stapsgewijs code gebouwd en getest wordt. Samen vormen ze een CI/CD-pipeline die essentieel is 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 gericht zijn op het just-in-time (en één tegelijk) leveren van waarde. Hoe sneller een team innovatie op de markt kan brengen, hoe concurrerender hun product zal zijn. Kanban-teams richten zich precies daarop: het optimaliseren van de workflow naar klanten.

Kanban en scrum delen enkele van dezelfde concepten, maar maken gebruik van een compleet verschillende aanpak. Ze moeten dus niet met elkaar worden verward. 

Sommige teams combineren de idealen van de kanban-methode en scrum in een 'scrumban'. Ze nemen sprints en rollen van een vaste lengte over van Scrum en richten zich op de WIP-limieten en de cyclustijd vanuit Kanban.

Voor teams die net beginnen met agile, raden we ten zeerste aan om één methodiek te kiezen en daar een tijdje mee aan de slag te gaan. Als je team klaar is om de kanban-methodologie te gebruiken, gebruik dan vandaag nog onze gratis kanban-bordsjabloon!