Een Android of misschien toch de nieuwe IPhone? Pizza of Friet? Euro of Bitcoin? Dagelijks passeren dit soort fundamentele vragen de revue. En zo ook binnen de zakelijke markt…
Daar waar sommige bedrijven nog altijd ‘struggelen‘ met de vraag of Waterval of Agile de beste aanpak is voor hun beoogde doelstelling zien we bij de meer Agile bedreven bedrijven juist vragen ontstaan welke Agile methodiek een beste fit is voor hetgeen zij beogen te realiseren. Gaat men voor de ’O zo’ populaire Scrum methodiek of is er sprake van een dergelijk groot traject dat schaalbaarheid noodzaak is. Dan is wellicht Scaled Agile (SAFe), LESS of het Spotify model meer voor de hand liggend.
In deze blog behandelen we de overeenkomsten en verschillen tussen de methodieken Scrum en Kanban en geven daarmee inzicht om een gedegen afweging te kunnen maken en de keuze stress mogelijk te verminderen. Hoewel beide methodieken hevig leunen op het Agile gedachtegoed, zijn ze in de basis fundamenteel anders.
Scrum
Te beginnen met Scrum. Een redelijk bekend weetje is dat de naam Scrum afkomstig is uit de Rugby sport en beschrijft de situatie waarbij twee teams in voorovergebogen houding tegen elkaar induwen. Een minder bekend weetje is waarschijnlijk dat de term ‘Scrum’ al in 1986 voor het eerst overgenomen werd voor een management paper geschreven door Takeuchi en Nonaka. De term moest het belang van teamwork benadrukken. Later, in de vroege jaren 90, namen de welbekende oprichters Jeff Sutherland en Ken Schaber de naam Scrum over en introduceerde een methodiek gebaseerd op het empirisme, ofwel de hedendaagse Scrummethodiek.
Figuur 1: Scrum tactic, Wikipedia
Het empirische besturingsproces staat voor opgedane kennis en ervaring door te doen en op basis van deze ervaringen (betere) beslissingen te kunnen nemen.
Kenmerkend voor Scrum is de aanwezigheid van een vaste cadans, de sprintlengte (2-4 weken), vaste rollen (Scrummaster, Product Owner en teammember) en events (Daily stand-up, sprintplanning, demo/review en retrospective).
Daarnaast leunt Scrum op een stevig fundament, te noemen 3 pijlers: Transparantie, Inspectie en aanpassing.
Onder transparantie wordt verstaan dat de voortgang en daarmee de onderhanden werkzaamheden te allen tijde inzichtelijk moeten zijn voor het hele team. Deze transparantie zorgt voor de juiste discussies binnen het team en vergroot de gezamenlijke gedragenheid. Een logisch vervolg is de inspectie waarbij continue gekeken wordt in hoeverre zaken naar behoren verlopen. Mochten zaken onverhoopt niet soepel lopen dan is het team in staat hier aanpassingen op te doen. Let op: Hiermee wordt niet bedoeld dat het gecommitteerde werk binnen de sprintplanning verandert. Enkel de manier waarop het team heeft besloten samen te werken kan gewijzigd worden.
Een veelgehoorde opvatting over Scrum is dat dit framework over het algemeen eenvoudig te begrijpen is maar moeilijk om perfect uit te voeren.
Figuur 2: Illustratie door Linda van Sinten, Creatieve Elephant.
Kanban
Kanban’s oorsprong komt voort uit de historie van Toyota. Naast het feit dat Toyota Lean heeft ontwikkeld hebben zij ook het Kanban board uitgevonden als onderdeel van hun Just In Time (JIT) productieproces. Het woord Kanban is Japans en betekend vrij vertaald uithangbord. Het idee achter het Kanban bord is dat de visuele kracht ervan een positieve bijdrage levert aan het productieproces en de efficiëntie ervan.
Kanban is, zeker vergeleken met Scrum, veel meer simplistisch. Er is geen sprake van sprints, is de daily stand-up geen verplichting (tov Scrum) en bestaan rollen als een Scrummaster of productowner niet.
Figuur 3: Voorbeeld Kanban Board. Bron: Wikipedia
“Je bent gedoemd om keuzes te maken. Dat is de grootste paradox van het leven”
Maar wat is dan de beste keuze voor jou? Je project, je afdeling of je bedrijf? Hier zijn enkele afwegingen die je zou kunnen maken in je besluitvorming.
Als je:
- Plannen en inschatten van werk wilt verbeteren;
- Multifunctionele teams aan het werk wilt hebben;
- Als je sub- doel voornamelijk bestaat uit software codering;
In deze gevallen is scrum HET Agile framework passend bij jouw doelstelling.
Mocht je:
- Workflow willen verbeteren binnen je project of organisatie;
- Cross functionele samenwerking willen stimuleren;
- Het team voornamelijk bezig laten zijn met ad-hoc werkzaamheden;
- Continue levering hoofdzaak vinden;
- Een framework willen implementeren dat eenvoudig en snel te realiseren is;
In dat geval past het gebruik van Kanban beter bij jouw team of onderneming.
Verdere differentiaties tussen beide frameworks zijn:
|
|
Kanban |
Scrum |
|
Prioritering |
Kanban gebruikt een pull mechanisme om ervoor te zorgen dat nieuwe taken opgepakt worden nadat de huidige taak/taken zijn afgerond. |
Scrum gebruikt ook een pull mechanisme maar niet op taak niveau maar op batch niveau voor de eerstvolgende iteratie. |
|
Leveringen/tijdslijnen |
Werkpakketten worden continu opgeleverd op elk gegeven moment. |
Werkpakketten worden iteratief opgeleverd aan het einde van iedere sprint. |
|
Rollen en verantwoordelijkheden |
Er zijn geen vooraf gedefinieerde rollen voor een team. Hoewel er misschien nog steeds een projectmanager is, wordt het team aangemoedigd om samen te werken en bij te dragen wanneer iemand overweldigd raakt. |
Elk teamlid heeft een vooraf gedefinieerde rol, waarbij de Scrummaster tijdlijnen dicteert, Product Owner doelen en doelstellingen definieert en teamleden het werk uitvoeren. |
|
Veranderingen |
Maakt het mogelijk om mid-stream wijzigingen aan te brengen in een project, waardoor iteraties en continue verbetering mogelijk zijn voordat een project is voltooid. |
Veranderingen tijdens de sprint worden sterk afgeraden. |
|
Productiviteit meten |
Meet de productie met behulp van "cyclustijd", of de hoeveelheid tijd die nodig is om een volledig stuk van een project van begin tot eind te voltooien. |
Meet de productie met behulp van snelheid door sprints. Elke sprint wordt back-to-back en/of gelijktijdig opgesteld, zodat elke extra sprint afhankelijk is van het succes van de sprint ervoor. |
|
Beste toepassing |
Het beste voor projecten met sterk uiteenlopende prioriteiten. |
Het beste voor teams met stabiele uitvoering die in de loop van de tijd misschien niet zo veel veranderen. |
Conclusie; Beide frameworks zijn goed in staat werkpakketten te volgen en om ontwikkelaars op schema te houden voor levering. Maar welke je ook kiest hangt af van je behoeften, het team en de doelen. Choose wisely!
Toch liever het beste uit twee werelden? Dan kun je altijd nog gaan voor zogenaamde Scrumban. Dit is letterlijk het samensmelten van de twee methodologieën Scrum en Kanban. Scrumban kan het beste worden toegepast bij team die zowel Scrum als Kanban ervaring hebben. De ervaring die ze hebben zal hen enige bekendheid geven wanneer ze de Scrumban-methodologie gaan gebruiken.
Figuur 4: Scrumban visualisatie. Bron: ora.pm
Het werk in Scrumban wordt georganiseerd in kleine stukjes, vaak ook wel mini-sprints genoemd. Deze werkpakketten worden gevisualiseerd op een Scrumban-bord. Het Scrumban board is in feite een Kanban board met een extra laag. Om het werk op gang te krijgen, worden on- demand planningsvergaderingen gehouden wanneer het nodig is om te bepalen welke user stories en taken in de volgende sprints moeten worden voltooid. Typerend voor scrumban is het feit dat er sprake is van korte, middel en lange termijn planning. Zie onderstaande illustratie.
Figuur 5: De 3 container planning. Bron: ora.pm
Ook het ontbreken van een team hiërarchie is uniek voor Scrumban. Dit houdt in dat iedereen dezelfde beslissingsbevoegdheid heeft als de ander. Dit maakt het team volledig “self- managing". Recapitulerend; De keuze is reuze but it’s entirely up to you.
