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 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 tool die wordt gebruikt om werk te visualiseren en de workflow binnen het team te optimaliseren. Hoewel fysieke borden populair zijn bij sommige teams, zijn virtuele borden een cruciale tool voor agile softwareontwikkeling vanwege hun traceerbaarheid, eenvoudigere samenwerking en toegankelijkheid vanaf meerdere locaties.

Een digitaal of fysiek Kanban-bord zorgt ervoor dat het team hun werk visualiseert, hun workflow standaardiseert en direct alle blockers en afhankelijkheden identificeert en oplost. 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 kunnen ze de workflow in kaart brengen om aan hun unieke processen te voldoen.

De Kanban-methodologie is gebaseerd op volledige transparantie van het werk en communicatie van de capaciteit in realtime. 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.' Kanban-teams vertegenwoordigen elk werkitem als een aparte kaart op het bord. Het belangrijkste doel van het weergaven van werk als een kaart op het Kanban-bord is om teamleden de voortgang van het werk te laten bijhouden door de workflow op een zeer visuele manier weer te geven.

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 populairste methodologieën voor softwareontwikkeling die tegenwoordig door agile-teams worden gebruikt. Kanban biedt extra voordelen voor taakplanning en capaciteit voor teams van elke omvang.

Een Kanban-team is alleen gericht op het werk dat in uitvoering is. Zodra de teamleden een taak hebben voltooid, selecteren ze de volgende taak uit de backlog. De producteigenaar kan werk in de backlog een andere prioriteit geven zonder het team te verstoren, omdat veranderingen 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.

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 kortere cyclustijden. Wanneer slechts één persoon een set vaardigheden bezit, wordt die persoon een knelpunt in de workflow. Teams gebruiken daarom eenvoudige beste praktijken zoals codereview en mentoring om de aanwezige kennis te verspreiden. Gedeelde vaardigheden betekenen dat teamleden heterogeen werk kunnen aannemen, wat de cyclustijd verder optimaliseert.

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 handhaven. In een Kanban-systeem zorgt het hele team ervoor dat het werk soepel verloopt tijdens het proces.

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

Een doorsnee softwareteam kan bijvoorbeeld vier workflowfasen 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 dan dat ze tijd besteden aan het beoordelen van andermans werk. Een lage limiet moedigt het team aan om speciale aandacht te besteden aan issues in de beoordelingsstatus en het werk van anderen te bekijken voordat ze hun codebeoordelingen verhogen. Hierdoor wordt uiteindelijk de totale cyclustijd verkort.

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 (CD) is het proces waarbij regelmatig werk wordt vrijgegeven aan klanten. Continue integratie (CI) is het proces waarbij code automatisch wordt gebouwd en incrementeel wordt getest gedurende de dag. 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 zijn gericht op de just-in-time (en één voor één) levering van waarde. Hoe sneller een team innovatie op de markt kan brengen, des te competitiever hun product gaat zijn. Kanban-teams richten zich precies daarop: het optimaliseren van de workflow 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 combineren de idealen van Kanban en scrum tot 'scrumban.' Ze combineren bijvoorbeeld de sprints met vaste lengte en functies van Scrum met de focus op WIP-limieten (werk in uitvoering) en de cyclustijd van Kanban.

Voor teams die net beginnen met agile, raden we echter ten zeerste aan om één methodologie te kiezen en er een tijdje mee te experimenteren. Als je team klaar is om aan de slag te gaan met de Kanban-methodologie, gebruik dan vandaag nog het gratis Kanban-bord-sjabloon!