In de wereld van Agile worden we continu verwend met nieuwe inzichten, modellen, rollen en frameworks. Twee aanhoudende constanten hierin zijn Scrum en Kanban; twee van de meest gebruikte frameworks. Ze bieden beide waardevolle benaderingen voor het beheren van projecten en het leveren van producten met maximale waarde. Maar wat is precies het verschil tussen Scrum en Kanban, en welke methode past het best bij jouw project? In dit artikel zullen we deze twee Agile frameworks vergelijken en hun toepassingen en kenmerken onder de loep nemen.
De Scrum Framework vindt zijn oorsprong in de wereld van softwareontwikkeling, waar het in de jaren 1980 voor het eerst werd geïntroduceerd. Het concept werd bedacht door Hirotaka Takeuchi en Ikujiro Nonaka in hun artikel “The New New Product Development Game” in de Harvard Business Review. Ze beschreven Scrum als een aanpak die lijkt op het spel rugby, waarbij een cross-functioneel team samenwerkt om een doel te bereiken. De focus moest volgens dit artikel komen te liggen op snelheid en op flexibiliteit.
Op basis van dit artikel en met hun eigen ervaringen hebben Jeff Sutherland en Ken Schwaber, twee van de belangrijkste figuren in dit landschap, Scrum ontwikkeld en verder gepopulariseerd. Het idee van Scrum was om softwareontwikkeling te transformeren van een lineair, en ogenschijnlijk voorspelbaar proces naar een flexibel, iteratief en empirisch proces. De nieuwste set aan regels vanuit het Scrum Framework zijn in 2020 gepubliceerd.
Scrum omvat duidelijk gedefinieerde rollen, waaronder Scrum Master, Product Owner en het Ontwikkelingsteam ook wel Developers genoemd. Deze rollen hebben ieder hun eigen verantwoordelijkheden, maar vormen gezamenlijk een team dat samen eindverantwoordelijk is voor het product dat geleverd wordt. Zo is de Product Owner verantwoordelijk voor de afstemming met stakeholders en eindgebruikers om zo een visie van het product vorm te geven en te prioriteren wat de meeste waarde heeft om in het product te bouwen. De Scrum Master focus zich op de volwassenheid van het team en het verwijderen van belemmeringen voor het team om op een effectieve manier het einddoel te realiseren.
In Scrum worden taken gebundeld in vaste tijdseenheden, bekend als Sprints, meestal van 2 tot 4 weken. Het team focust zich op het opleveren van een werkend product aan het einde van elke sprint. Dit werkend product kan een iteratie zijn van een eerder opgeleverd deelproduct of een nieuwe deelproduct (of increment zoals dat in Scrum termen word genoemd). Gedurende de Sprint zijn er verschillende evenementen zoals Sprint Planning, Daily Standup, Sprint Review en Sprint Retrospective. Ieder van deze sessies heeft een eigen focus en een specifieke bijdrage die het levert aan het team om op een gestructureerde wijze waarde toe te voegen terwijl ze flexibel blijven en maximale waarde blijven toevoegen.
De Product Owner beheert de Product Backlog. Dit is een lijst met taken en functies die prioriteit hebben op basis van de waarde die ze toevoegen aan het product. De prioriteit wordt bepaald door de inzichten van de Product Owner op basis van onderzoek en gesprekken met eindgebruikers, klanten, stakeholders en andere geïnteresseerden. Deze lijst wordt continu bijgewerkt en vormt een gezamenlijke werklijst en realiteit voor het team. Dit resulteert uiteindelijk in de Sprint Backlog van waaruit het team de Increment (deelproduct) oplevert.
Kanban vindt zijn oorsprong buiten de wereld van softwareontwikkeling, namelijk in de productie. Het werd voor het eerst geïntroduceerd door Taiichi Ohno, een ingenieur bij Toyota, in de jaren 1950. Het woord “Kanban” komt uit het Japans en betekent “visueel kaartje” of “bord”. In de productiecontext werd Kanban gebruikt om de voorraadniveaus en productiestappen te beheren. Het systeem maakte gebruik van fysieke kaarten om de vraag naar producten en de beschikbaarheid van grondstoffen te reguleren. Zo voorkom je onnodig voorraad en versoepel je het productieproces.
In de loop der jaren is Kanban geëvolueerd en aangepast aan verschillende industrieën, waaronder softwareontwikkeling, waar het bekend staat als “Kanban for Software Development” of gewoon “Kanban”. David J. Anderson is een prominente figuur die Kanban heeft geïntroduceerd in de softwareontwikkelingswereld.
In tegenstelling tot Scrum heeft Kanban geen vaste rollen of voorgeschreven evenementen. Hierdoor kunnen werkzaamheden langer duren dan voorgeschreven staat in het Scrum Framework (namelijk een Sprint met afgebakend timebox). In softwareontwikkeling wordt Kanban vaak gebruikt om bugs en complexere verzoeken te beheren. Dit zijn typisch verzoeken die langer dan een Sprint duren en een langere doorlooptijd kennen door bijvoorbeeld afhankelijkheden met externen of specialisten.
Kanban moedigt een continue werkstroom aan. Taken worden toegevoegd aan het Kanban-bord zodra er ruimte is en worden verplaatst op basis van de voortgang. Er zijn geen time-boxes zoals sprints. Dit betekent dat de enige beperking die je hebt voor je werkvoorraad je eigen werkvoorraad is. Je plant dus niet op basis van de tijd die je neemt voor een Sprint, maar selecteert werk, maakt dat af en pakt daarna pas ander werk op. Vaak zien we dat er afhankelijkheden zijn waardoor men opgepakt werk niet af kunnen maken. De reactie is om ander werk op te pakken tot deze niet meer geblokkeerd wordt door de afhankelijkheid. Om te voorkomen dat er te veel taken in de wachtstand komen te staan wordt een zogeheten WIP-limit (Work In Progress) aangesteld.
Kanban introduceert het concept van Work In Progress (WIP)-limieten. Deze limieten beperken het aantal taken dat tegelijkertijd in uitvoering is, wat overbelasting voorkomt en de doorlooptijd verkort. Als je een redactieteam hebt, kun je een WIP-limiet instellen om aan te geven dat er maximaal drie artikelen tegelijkertijd kunnen worden bewerkt. Hierdoor kan het team zich concentreren op de kwaliteit in plaats van kwantiteit.
Laten we nu eens kijken naar enkele cruciale verschillen tussen Scrum en Kanban:
Scrum biedt een duidelijke structuur met vaste rollen en evenementen die bijdragen aan het opleveren van het product. Dit terwijl Kanban meer flexibel is en zich aanpast aan de behoeften van het team. Dat wil niet zeggen dat Scrum niet flexibel is, maar dat Kanban meer ruimte geeft om het proces anders in te richten.
Scrum gebruikt time-boxing met vaste sprints, terwijl Kanban een continue werkstroom bevordert zonder vaste tijdseenheden. Scrum maakt het mogelijk om je project of product beter in te schatten door een afgebakende tijd eraan te werken en naderhand te beoordelen of je nog steeds op schema bent of dat je andere keuzes moet maken. Aan de andere kant maakt Kanban het mogelijk om continu te blijven werken aan het product en alle incidenten, bijkomsten en bugs op te pakken.
Scrum legt de nadruk op prioriteit en werkt aan een beperkt aantal taken in een sprint. Dit betekent dat je een inschatting maakt van wat je af kunt krijgen als team binnen een afgebakende tijdsperiode en hierop focust. Je prioriteert op basis van klantwaarde en de inschatting die de Product Owner hiervoor maakt. Kanban legt de nadruk op het beperken van werk in uitvoering (WIP) om de focus te behouden en doorlooptijden te verkorten. Als je werkt aan een project waarin de volgorde van taken cruciaal is, zoals het lanceren van een nieuw product, kan Scrum geschikt zijn. In een situatie waarin je continu werk beheert, zoals softwareonderhoud, kan Kanban passender zijn.
Laten we voorop stellen dat zowel Scrum als Kanban ontzettende waardevolle manieren zijn om je werk in te richten als team en effectief samen te werken. Welk van deze methoden je gebruikt is irrelevant, zolang je maar een bewuste keuze hebt gemaakt als team en Agile genoeg bent om hier van af te wijken op het moment dat je signaleert dat het niet zo werkt als dat je gehoopt had. In dit kader zijn er dus ook veel teams die een combinatie zoeken tussen Scrum en Kanban om hun samenwerking effectief in te richten. Dit wordt ook wel Scrumban genoemd. Stel je voor dat je een marketingteam hebt dat zowel strategische projecten als lopende taken beheert. Je zou Scrum kunnen gebruiken om de projecten met duidelijke doelen te plannen en Kanban kunnen toepassen voor de dagelijkse marketingactiviteiten.
De keuze tussen Scrum en Kanban hangt af van de aard van je project, de behoeften van je team en de context waarin je werkt. Het is ook mogelijk om elementen van beide methoden te combineren, afhankelijk van de specifieke uitdagingen waarmee je wordt geconfronteerd. Het belangrijkste is om een aanpak te kiezen die de productiviteit verbetert, de doorlooptijd verkort en de waarde voor klanten maximaliseert. Experimenteer, leer en pas je aan terwijl je groeit in je Agile reis!