Kanban vs. scrum: welke agile methode past bij jou?

Samenvatting: Kanban is een framework voor projectmanagement waarvoor visuele taken vereist zijn om workflows te beheren, terwijl scrum een framework voor projectmanagement is dat teams helpt hun werk te structureren en te beheren met behulp van een reeks waarden, principes en werkwijzen.

Agile bestaat uit een set idealen en principes die dienen als onze poolster. DevOps is een manier om de processen tussen softwareontwikkeling en operationele teams te automatiseren en te integreren. Als het gaat om het implementeren van agile en DevOps, bieden kanban en scrum verschillende manieren om dit te doen.

Het is makkelijk om de verschillen tussen scrum- en kanban-werkwijzen aan te wijzen, maar dat betreft voornamelijk de uiterlijke aspecten. Hoewel de werkwijzen verschillen, zijn de principes grotendeels hetzelfde. Beide frameworks helpen je bij het bouwen van betere producten (en diensten) met minder hoofdpijn.

Dus, waar waren we?

Agile is een gestructureerde en iteratieve benadering van projectmanagement en productontwikkeling. Het erkent de volatiliteit van productontwikkeling en biedt een methodologie voor zelforganiserende teams om op verandering te reageren zonder te ontsporen. Agile is tegenwoordig nauwelijks een concurrentievoordeel. Niemand heeft de luxe om jarenlang of zelfs maanden een product te ontwikkelen in een zwarte doos. Dit betekent dat het belangrijker is dan ooit om het goed te doen.

Bij Kanban draait alles om het visualiseren van je werk, het beperken van werk in uitvoering en het maximaliseren van efficiëntie (of flow). Kanban-teams richten zich op het verminderen van de tijd die een project (of userstory) van begin tot eind kost. Ze doen dit door gebruik te maken van een kanban-bord en hun workflow continu te verbeteren.

Scrumteams verbinden zich ertoe een werkbijdrage te voltooien, die mogelijk kan worden geleverd, door middel van ingestelde intervallen die sprints worden genoemd. Hun doel is om leerlussen te creëren om snel feedback van klanten te verzamelen en te integreren. Scrumteams nemen specifieke rollen aan, maken speciale artefacten en houden regelmatig ceremonies om dingen op gang te houden. Scrum wordt het best omschreven in de Scrum Guide.

We bieden Jira-sjablonen waarmee je snel aan de slag kunt, ongeacht welk framework voor projectmanagement het beste voor jou werkt. Bekijk onze scrum-sjabloon of onze sjabloon voor een kanban-bord — beide zijn gratis te gebruiken.

Met scrum belooft je team tegen het einde van elke sprint een waardevolle bijdrage aan het uit te voeren werk te leveren. Scrum is gebouwd op empirisme, gericht op kleine werkstappen die je zullen helpen te leren van je klanten zodat je met een betere onderbouwing verder kunt. De scrumbenadering bestaat uit de volgende elementen:

Scrums worden gekenmerkt door een hoog tempo, met sprints die meestal tussen de één en vier weken duren, die duidelijke start- en einddata hebben. Het korte tijdsbestek betekent dat complexe taken moeten worden opgesplitst in kleinere story's en dat teams snel moeten leren. Een belangrijke vraag is deze: kan je team zo snel bruikbare code leveren?

Sprints zijn onderverdeeld in sprintplanning, sprintreview en retrospective meetings en doorspekt met dagelijkse scrumbijeenkomsten (standups). Deze scrumceremonies zijn algemeen van aard en lopen continu door.

Scrum kent drie duidelijk omschreven rollen.

• De producteigenaar pleit voor de klant, beheert de productbacklog en helpt prioriteit te geven aan het werk van het ontwikkelingsteam.
• De scrummaster helpt het team om recht te blijven doen aan de scrumprincipes.
• Het ontwikkelingsteam kiest het werk dat moet worden gedaan, levert werk in stappen en toont collectieve verantwoording.

Wie beheert het scrumteam? Nou, niemand. Scrumteams organiseren zichzelf en iedereen is gelijk, ondanks verschillende verantwoordelijkheden. Het team is verenigd door het doel om waarde te leveren aan klanten.

Scrumstatistieken zijn datapunten die scrumteams kunnen gebruiken om de efficiëntie en effectiviteit te verbeteren. Ze kunnen bijdragen aan geïnformeerde besluitvorming en teams helpen efficiënter te worden in planning en uitvoering. Tijdens de sprintplanningsfase kunnen teams statistieken gebruiken zoals sprintdoelen, teamsnelheid, teamcapaciteit en soort werk. Tijdens stand-ups kunnen teams ook profiteren van het meten van de voortgang naar sprintdoelen, het beoordelen van een sprintburndown, het begrijpen van de verdeling van de werkdruk en meer.

Teams streven ernaar om te begrijpen hoeveel ze kunnen bereiken binnen de grenzen van hun sprinttijd. Ze verbinden zich tot levering binnen een sprint. Scrumteams kunnen echter feedback van klanten ontvangen die hen aanmoedigt om een andere richting te kiezen en de sprint te veranderen om de meeste klantwaarde te leveren. Tijdens de sprint retrospective moeten scrumteams bespreken hoe veranderingen in de toekomst kunnen worden beperkt, aangezien veranderingen het potentieel leverbare werk in gevaar brengen. Als een team halverwege de sprint regelmatig van scope verandert, kan dit betekenen dat er werk is geselecteerd dat niet voldoende wordt begrepen. Het kan ook betekenen dat het team operationeel/onplanbaar werk heeft dat het plan verstoort.

Zie What Is Scrum? voor meer informatie over scrummethodologieën.

Kanban helpt je werk te visualiseren, werk in uitvoering (WIP) te beperken en werk snel te verplaatsen van 'In uitvoering' naar 'Gereed'.

Kanban is perfect voor teams die veel inkomende aanvragen hebben die variëren in prioriteit en grootte. Terwijl scrumprocessen een hoge controle vereisen over wat er in scope is, betekent kanban meer 'go with the flow'. Laten we dezelfde vijf overwegingen eens nader bekijken om je te helpen beslissen.

Kanban is gebaseerd op een continue workflowstructuur die teams wendbaar en flexibel houdt om zich aan te passen aan veranderende prioriteiten. Werkitems - vertegenwoordigd door kaarten - worden georganiseerd op een kanban-bord waar ze van de ene fase van de workflow (kolom) naar de volgende stromen. Veelvoorkomende workflowfasen zijn Te doen, In uitvoering, In beoordeling, Geblokkeerd en Gereed. Uiteraard kunnen de fasen ook andere namen hebben. Maar dit is verder niet zo interessant.

Het leukste van kanban is het maken van aangepaste kolommen voor hoe je team werkt. Mijn team levert inhoud, dus onze kolommen (simpel gezegd) gaan van Backlog, naar Prioriteit, naar Opzet klaar, naar Schrijven, Ontwerpen, Technische beoordeling en Geleverd. Ons bord heeft ons laten zien dat we ongeveer één stuk inhoud per week leveren, en we weten nu waar onze knelpunten zitten (door de fase Technische beoordeling).

In kanban worden updates vrijgegeven wanneer ze klaar zijn, zonder een regelmatig schema of vooraf bepaalde vervaldatums.

In theorie schrijft kanban geen vaste tijd voor om een taak te voltooien. Als de taak eerder (of later) wordt voltooid, kan deze naar behoefte worden vrijgegeven zonder te hoeven wachten op een release-mijlpaal zoals een sprintreview.

Het hele team is eigenaar van het kanban-bord. Sommige teams roepen de hulp van een agile coach in, maar in tegenstelling tot scrum is er geen 'kanban-master' die alles soepel laat verlopen. Het is de collectieve verantwoordelijkheid van het hele team om samen te werken aan de taken op het bord en deze te leveren.

Doorlooptijd en cyclustijd zijn belangrijke statistieken voor kanban-teams. De deal met de gemiddelde hoeveelheid tijd die nodig is om een taak te voltooien. Verbetering van cyclustijden duidt op het succes van kanban-teams.

Het cumulatief stroomdiagram (CFD) is een andere analytische tool die door kanban-teams wordt gebruikt om het aantal werkitems in elke toestand te begrijpen. CFD's helpen bij het identificeren van specifieke knelpunten die moeten worden opgelost voor een betere doorvoer.

Een andere manier om met knelpunten om te gaan, is door middel van WIP-limieten (Work In Progress, werk in uitvoering). Een WIP-limiet beperkt het aantal kaarten dat zich tegelijk in een kolom kan bevinden. Wanneer je de WIP-limiet bereikt, wordt die kolom door een tool zoals Jira geblokkeerd voor nieuwe kaarten en zet het team alles op alles om die items naar de volgende fase te brengen.

Een kanban-workflow kan op elk moment veranderen. Nieuwe werkitems kunnen aan de backlog worden toegevoegd en bestaande kaarten kunnen worden geblokkeerd of verwijderd op basis van prioritering. Als de teamcapaciteit verandert, kan de WIP-limiet ook opnieuw worden gekalibreerd en de werkitems dienovereenkomstig worden aangepast. Het draait allemaal om flexibel zijn in kanban.

Zie Wat is kanban? voor meer informatie over kanban-methodologieën.

De agile community vindt dat dit gesprek niet over de tools moet gaan. We zien vaak dat de gekozen tool leidend is voor de keuze van het framework en het framework leidend voor de principes die het team hanteert. Wij vinden dat de beslissing de andere kant op moet gaan.

Als je eenmaal bent afgestemd op scrumprincipes en blij bent met het scrumframework, dan is het tijd om een scrum-tool te vinden die daar goed bij past. Hetzelfde geldt voor kanban. We zijn bevooroordeeld, maar als de nummer 1 softwareontwikkelingstool die wordt gebruikt door agile teams, denken we dat Jira de perfecte oplossing is.

Met de speciale projecttypen van Jira voor scrum en kanban, kun je de principes van elk framework realiseren. Daarnaast kunnen we je op weg helpen met de verschillende handleidingen die we hebben geschreven over het toepassen van scrum met Jira Software en over het toepassen van kanban met Jira.

Scrum en kanban volgen 'agile volgens de regels'. Beide frameworks werken op een beproefde manier waar eerlijk gezegd geen woord tegenin te brengen is. Om een slogan van een zeer bekend IT-bedrijf te parafraseren: "Niemand wordt ontslagen door de keuze voor scrum."

Maar je beslissing hoeft niet zo zwart-wit te zijn. Honderden teams gebruiken hybride modellen die worden beïnvloed door zowel scrum als kanban. We wilden teams helpen dit te doen in Jira, daarom hebben we teambeheerde projecten gemaakt.

Teambeheerde projecten, zoals de naam al doet vermoeden, stellen teams in staat om de agile functies te kiezen die voor hen zinvol zijn, of dat nu scrum, kanban of een mix van beide is. In plaats van op dag één te kiezen voor een bepaald framework, stellen teambeheerde projecten je in staat om geleidelijk aan steeds krachtigere functies te implementeren terwijl je ontdekt wat werkt voor je team (en wat niet).

Je kunt met vertrouwen kiezen voor teambeheerde scrum of teambeheerde kanban, wetende dat beide sjablonen kunnen evolueren om aan de behoeften van je team te blijven voldoen.

Wat je ook kiest, geef het een tijdje de kans. Neem wat werk uit de backlog en voltooi het traject helemaal en vraag dan aan je team wat goed is gegaan en wat slecht is gegaan. Door scrum en kanban uit te proberen en deze vragen te stellen, ben je goed op weg naar het agile nirvana.