Er bestaat geen wondermiddel waarmee je het perfecte agile framework voor je agile team kunt uitkiezen. Weet dat agile een teamproces is, of je nu kanban, scrum of een combinatie van de twee gebruikt, zoals scrumban of kanplan. Elk team moet uitzoeken welk framework het beste werkt voor het plannen, volgen en uitbrengen van geweldige software.
Scrumban vs. kanban vs. scrum
Kanban streeft ernaar teamleden net genoeg werk te geven zodat het team consequent op capaciteit werkt. Teams die kanban beoefenen, profiteren van flexibele planning, een duidelijkere focus en totale transparantie omdat alles wat er op het bord staat de hoogste prioriteit heeft. Dat zijn de items waar ontwikkelaars aan werken. Kanban is geweldig voor operationele teams die zich richten op continue levering met veranderende prioriteiten.
Scrum verdeelt het werk daarentegen in een reeks iteraties met een vaste lengte die sprints worden genoemd. Wat er ook gepland staat voor een sprint heeft de hoogste prioriteit van het team (bijvoorbeeld een bepaalde functie of groep functies). Productteams met een duidelijke roadmap en geprioriteerde werkitems profiteren doorgaans het meest van scrum.
Maar misschien heeft je team wel het meeste baat bij een combinatie van scrum en kanban? Of willen ze overstappen van scrum naar kanban? Als dat klinkt als jouw team, is scrumban de oplossing. Deze gemengde methodologie manifesteert zich op verschillende manieren, maar de meest voorkomende trends onder scrumban-teams zijn het gebruik van sprints met een backlog van scrum, en WIP-limieten en cyclustijd van kanban. (Opmerking: cyclustijd is de hoeveelheid tijd die nodig is voor een taak om de workflow van een team te doorlopen.)
Hoe zit het met teams die niet iteratief willen werken, maar toch de mogelijkheid willen hebben om een backlog weg te werken? Kanplan (of het activeren van de kanban-backlogfunctie) in Jira kan het antwoord zijn.
Wat is kanplan?
Kanplan is een gemengde methodologie voor agile softwareontwikkeling. Net als scrumban combineert het functies van zowel scrum als kanban. Kanplan is ideaal voor teams die de mogelijkheid willen hebben om de backlog weg te werken, maar die niet in sprints willen werken.
Waarom kanban een fundament is en geen strikt framework
Het build engineering-team van Atlassian is verantwoordelijk voor een platform dat wordt gebruikt voor het bouwen, testen en leveren van Atlassian-software. Ontwikkelaars zijn afhankelijk van een betrouwbare infrastructuur en snelle continue integratie (CI). Vier jaar geleden ging het om 21.000 builds per maand. Tegenwoordig is dit aantal opgelopen tot 150.000 builds per maand.
Deze mogelijkheid om op te schalen kan worden toegeschreven aan teamgroei, overgang van Subversion naar Git, geautomatiseerd testen en iets minder voor de hand liggend: het besluit om van scrum naar kanban over te stappen. De aard van build engineering (denk aan ad-hoc aanvragen, incidenten, innovatiewerk) paste niet goed binnen een scrumframework. Dus besloot het team scrumban te introduceren, wat al snel kanban werd omdat het team niet graag met sprints werkte. Maar het blijkt dat kanban ook niet het toverdrankje was waar ze op hoopten. Zoals zoveel teams hebben ze het wel geprobeerd. Ze gingen van één bord naar meerdere, een bord voor support engineers, een projectwerkbord en nog andere borden, allemaal met verschillende workflows. Maar het grootste pijnpunt over alle borden gezien? De 'woestenij', zoals een teamlid het noemde, van niet-beoordeelde problemen die moesten worden voorbereid voor de modus Klaar voor werk. Eenmaal in de kolom In uitvoering kon het team aan de slag, maar hun kolom Te doen, de woestenij dus, was precies dat: een woestenij.
Je takenlijst veranderen in een backlog
Ons build engineering-team probeerde hun lange en ongeorganiseerde takenlijst te bestrijden met dagelijkse standups en wekelijkse planningsbijeenkomsten. Maar wat ze echt nodig hadden, was een backlog in plaats van meer meetings.
Omdat kanban-borden traditioneel geen backlog-functionaliteit hebben, gebruiken productmanagers, ontwikkelingsmanagers en teamleiders issues in de eerste kolom om te plannen. Naarmate deze lijst groeit, is het moeilijk om issues te identificeren en prioriteit te geven. Het build engineering-team splitste hun borden op basis van verschillende werkgebieden, maar het gecombineerde teambord bleef overweldigend (er moest veel gescrold worden).
Dus in plaats van verschillende manieren te bedenken om het team of de borden anders in te delen, of het wiel opnieuw uit te vinden, besloot het Jira-team om kanban uit te breiden met backlogs. De kanplan-functie introduceert een brede kolom-backlog met issues in een lijstweergave. Hierdoor wordt het kanban-bord opgesplitst in twee verschillende schermen; de backlog voor het wegwerken van de backlog en het kanban-bord voor het engineeringteam om taken te selecteren en het verplaatsen van taken door de workflow.
Deze functie is niet anders dan de backlog van een scrumbord in Jira. Als je bijvoorbeeld op het backlog-pictogram in de zijbalk klikt, ga je naar een brede kolom met backlog-issues. Nadat je de backlog hebt geordend, kun je issues naar de volgende stap in de workflow slepen.
Deze combinatie van het backlog-scherm uit scrum en het kanban-bord in één agile bord functioneert als een scrumbord-backlog. Wanneer je op een issue klikt, verschijnt er een detailweergave voor de issue. Via gerichte weergaven, zoals de detailweergave van een issue, kunnen teamleden taken sneller uitvoeren met minder afleiding.
Ten slotte is het zo dat niet-scrumteams die epics en vooraf toegewezen versies gebruiken om hun releases te organiseren, kunnen profiteren van tools die te vinden zijn in scrumborden, zoals issues weergeven of snel bewerken. Deze eenvoudige en snelle bewerking geeft productmanagers, ontwikkelingsmanagers en iedereen die in de planningsmodus werkt, de mogelijkheid om epics en versies efficiënt te beheren.
Wil je een backlog toevoegen aan je kanban-bord?
Volg deze tutorial om een backlog te maken in je kanban-project:
Kanplan biedt, zoals een klant het zei, 'het beste van twee werelden'. Je kunt kaarten verplaatsen zonder een sprint te organiseren en taken invoeren in een backlog, zodat je beter kunt gaan plannen. Er is geen sprake meer van de woestenij waarmee het build engineering-team van Atlassian te maken had en kanban-teams hebben toegang tot een planningsmodus die nog niet in een kanban-wereld bestond. Het geeft ook op een nieuwe manier richting aan teams die niet het gevoel hebben dat kanban, scrum of scrumban hen de basis geven die ze nodig hebben om het werk te doen dat ze willen doen.
Door de planningsmodus op een kanban-bord te openen, kunnen teams die al dan niet bekend zijn met kanban manieren vinden om dit agile framework te laten werken in plaats van te proberen best practices te volgen die mogelijk niet van toepassing zijn op het team. Belangrijk: bij agile ontwikkeling heeft continue verbetering prioriteit boven best practices.
