-

Is kanban het nieuwe scrum?

De hoogtijdagen van scrum lijken voorbij te zijn. Kanban is het nieuwe toverwoord voor organisaties die agile willen werken. Maar is dat terecht?

Scrum is een lightweight softwareontwikkelingsmethode die vanaf 2009 populair werd in Nederland. Het is een uitgewerkt framework met duidelijke omschrijvingen van de rollen, processen en rituelen die erbij komen kijken. Veel bedrijven meenden dat het de silver bullet was, de oplossing voor alles wat met softwareontwikkeling te maken had. Dat is het natuurlijk niet – er kan veel misgaan.

Scrum is een revolutie voor je bedrijf. Je stopt met wat je doet en implementeert scrum, met alles wat erbij hoort. Een van de redenen dat je de laatste tijd steeds vaker teleurgestelde geluiden hoort over scrum, komt door een gebrekkige implementatie van het framework en de bijbehorende processen en rituelen. Nederlanders zijn eigenwijs en denken na een aantal sprints dat ze het zich al kunnen veroorloven om het proces of de rituelen aan te passen of zelfs te schrappen. Vaak blijven na een tijdje alleen de stand-up meeting over en het sprintritme over en is het dus alleen nog SINO – Scrum In Name Only. Het scrum framework is echter gebaseerd op jarenlange ervaring. Alle elementen hebben hun waarde. Als je te snel de regels loslaat, realiseer je simpelweg de te verwachten resultaten niet.

Product owner onderschat

Een tweede reden waarom scrum vaak niet werkt zit hem in de uitvoering van de rol van product owner. Deze persoon zet de stip aan de horizon, maakt plannen en business cases en zorgt ervoor dat het scrum team hier iteratief naartoe werkt. Hij of zij onderhoudt de contacten met de stakeholders – denk aan de directie, afdeling IT, marketing, juristen, enzovoorts – en zorgt ervoor dat die tevreden blijven. Dit is verreweg de belangrijkste rol in de scrum-methode en dat wordt vaak onderschat. Mensen hebben de product owner-rol vaak naast hun normale werk en hebben daardoor te weinig tijd om het goed te doen. Dat haalt de effectiviteit uit het proces.

De derde negatieve ervaring bij scrum is de stress omtrent de sprint deadlines. Een sprint wordt gevuld met user stories die door het scrumteam zijn ingeschat. Daar zijn allerlei technieken voor, maar feit blijft dat softwareontwikkeling geen exacte wetenschap is. Pas bij de realisatie kom je erachter hoeveel tijd een user story echt kost. Het komt dus geregeld voor dat een scrumteam in de laatste paar dagen voor het afronden van de sprint alle zeilen bij moet zetten om tot afronding te komen. En soms lukt het dan nog niet, waardoor de volgende sprint wordt begonnen met een achterstand. Als dit te vaak gebeurt en om redenen waar het scrumteam zelf geen invloed op heeft, zoals ziekte, dan ontstaat er stress en – op de lange duur – sprintmoeheid.

kanban board

Kanban als alternatief voor scrum

Terecht of niet, de teleurstellende ervaringen met scrum hebben als gevolg dat bedrijven op zoek gaan naar een andere werkmethode. Kanban is in deze context in opkomst. Het is eveneens een agile manier van werken, gebaseerd op het ‘just-in-time’ productiemodel van Toyota.

Kanban draait erom inzichtelijk te maken welke stappen je nu al onderneemt om software te ontwikkelen, op basis van bestaande processen, rollen en verantwoordelijkheden binnen het bedrijf. Door deze stappen uit te schrijven en te visualiseren op een kanbanboard, waarbij elke stap in het proces een kolom krijgt, ontstaat een transparant beeld van het proces. De user stories plot je op dat board op volgorde van prioriteit en in de juiste kolom. Tot zover niets nieuws. Vervolgens ga je aan de slag en meet je hoelang een user story in elke kolom staat. Zo wordt na verloop van tijd duidelijk waar knelpunten in het proces zitten. Samen met alle procesbetrokkenen worden die knelpunten een voor een opgelost. Het proces wordt zo steeds efficiënter. Kanban is in dit opzicht een evolutie, geen revolutie zoals scrum.

Er is geen product owner bij kanban, maar het proces dient uiteraard wel te worden voorzien van input. De user stories moeten worden opgesteld en uitgewerkt. Ook hier gaat kanban in eerste instantie uit van het bestaande proces. Net als het ontwikkelingsproces wordt het proces om tot een user story te komen uitgeschreven en weergegeven op een kanbanboard. Het meten van de doorlooptijd per stap is in dit geval minder relevant. Waar het om gaat is te zorgen dat er altijd voldoende user stories in de laatste kolom staan (‘user story ready’) zodat het ontwikkelteam er voldoende op voorraad heeft om bezig te kunnen blijven.

Een ander groot verschil is dat kanban niet tijdgebonden is, het is een continu proces. De stress die sommige scrumteams ervaren bij het afronden van een sprint, is er bij kanban niet. Als er meer tijd nodig is om een user story af te ronden dan verwacht, is dat geen enkel probleem. Dan wordt gewoon pas later aan de volgende user story begonnen.

Bereidheid om te veranderen

Het is niet zo dat als scrummen mislukt is binnen je bedrijf, kanban de aangewezen weg is. Behalve de verschillen zijn er namelijk ook veel overeenkomsten tussen de twee. Bij beide staan samenwerking, continu evalueren en het omarmen van veranderingen centraal, alleen gaan die bij kanban geleidelijker. Het bedrijf moet dus wel bereid en in staat zijn om te transformeren. Verder is er bij zowel scrum als kanban discipline nodig om het goed uit te voeren. De belangrijkste verschillen zijn dat scrum voorschrijvend is en gericht op resultaat, terwijl kanban laagdrempelig is en focust op processen. De een is niet beter dan de ander. Beide hebben veel potentie om de productiviteit te verhogen en tot betere resultaten te komen. Mits goed uitgevoerd natuurlijk.

Deel dit bericht

3 Reacties

Jacques Peters

Probleem is de ‘mens’ zelf. Welk systeem/methode je ook kiest.

Rob Eijgelshoven

Hoi Jacques,
Het klopt dat ‘de mens’ zelf vaak de zwakke schakel is in een systeem. Vandaar ook het engelse gezegde ‘A fool with a tool is still a fool’. Met andere woorden: iemand die niet begrijpt wat hij/zij met een systeem moet doen, zal dat systeem niet optimaal gebruiken.

Naar mijn mening zijn er twee momenten waarop ‘de mens’ het systeem teniet kan doen. Dat is op de eerste plaats bij de adoptie van het systeem (weerstand voor verandering) en op de tweede plaats bij de uitvoering van het systeem (discipline om het systeem te gebruiken/juist uit te voeren).

In het geval van scrum heeft de adoptie van het systeem een veel grotere impact op een organisatie dan bij kanban. De weerstand vanuit ‘de mens’ zal dan ook (in theorie) groter zijn. Daar staat tegenover dat het wel een heel duidelijk systeem is, waardoor iedereen weet wat van hem/haar verwacht wordt. Dat neemt een hoop onzekerheid weg. Het succes van scrum staat of valt met het uitvoeren van de bijbehorende rituelen. Als je als organisatie de discipline op kunt brengen om dit goed te blijven uitvoeren, dan zal scrum zeker waarde opleveren. Scrum is dus een heel fijn framework als alle huidige processen binnen een bedrijf geen, of niet de juiste, resultaten opleveren.

Kanban is wat laagdrempeliger dan scrum, omdat het uitgaat van bestaande processen en verantwoordelijkheden. De weerstand bij adoptie van het systeem zal (in theorie) dus ook lager zijn. Doel van kanban is echter wel om continu kleine veranderingen aan het proces te doen, om efficientie en effectiviteit te verhogen. En al die veranderingen moeten weer door de veranderweerstand van ‘de mens’ heen. Gelukkig zijn de veranderingen binnen kanban vaak klein.
Kanban is nuttig om te gebruiken wanneer de bestaande processen binnen een bedrijf wel degelijk waarde opleveren/toevoegen, maar er ook zeker nog ruimte is voor verbetering.

Tot slot, over ‘de mens’: Daniel Kahneman heeft een interessant boek geschreven over de manieren waarop ons brein werkt. Dit verklaart voor een groot deel de weerstand bij verandering en hoe je hier als manager mee om kunt gaan. Het boek heet ‘Thinking, fast and slow’ en is in het Nederlands vertaald met als titel ‘Ons feilbare denken’. Aanrader als je ‘de mens’ beter wilt leren begrijpen.

Ton Martens

Als scrum-master heb ik het artikel met belangstelling gelezen. Ik ben onbekend met het toepassen van Kanban en ben benieuwd hoe bepaalde zaken in Kanban worden ‘opgelost’, waar dit in Scrum doorgaans duidelijk is:

– Hoe komt de ‘Definition of Done’ tot stand? Wellicht bestaat deze term niet in Kanban, maar de developers zullen toch moeten weten wat er verwacht wordt en wat niet.
– Als je in Kanban niet weet op welk moment iets is afgerond (geen Sprint), hoe kun je dan een release doen?

Ik krijg de indruk dat de keuze Scrum/Kanban vooral bepaald zou moeten worden aan de hand van de voorspelbaarheid van het project. Zoals aangegeven, Kanban is door Toyota ‘bedacht’. Ik kan me van een productielijn voorstellen dat er veel terugkerend, herhalend werk is. Maar bij veel software-projecten is er een noodzaak om user story’s te bespreken om de Definition of Done duidelijk te krijgen. De planningsmeeting dus.

Bovendien, een sprint bij Scrum moet/kan worden gezien als een iteratie waar de klant voor betaalt. Deze klant mag dus aan het einde van de sprint verwachten dat hij daadwerkelijk krijgt waarvoor is betaald. Bestaat iets dergelijks ook in Kanban?

Deze overwegingen in aanmerking nemend, lijkt de keuze voor Scrum, voor wat betreft het gemiddelde software-project logischer dan Kanban. Klopt dat?

Plaats een reactie

Uw e-mailadres wordt niet op de site getoond