Efficiënter werken aan de hand van de Scrumban methode

Een lange tijd werkten wij volgens de Agile Scrum methode. Scrum is een manier om vaak met een wat groter team projecten aan te pakken. Het is een effectieve en flexibele manier van werken, die het voor een team mogelijk maakt om projecten op een productieve wijze op te leveren en eventuele problemen snel te tackelen. Wil je meer weten over het werken volgens de Scrum-methode? Lees dan even deze blog die wij eerder schreven.

Een tijdje geleden is ons development team overgegaan op het werken volgens een andere methode, namelijk Scrumban. Wat dit precies is en waarom we hiervoor gekozen hebben, leggen we je allemaal in dit artikel uit. Wellicht is het voor jouw bedrijf ook wel een efficiëntere manier van werken, dan de huidige manier.

De Scrum werkwijze

Scrum is een methode die erg is toegespitst op het werken aan één product en één project. Bij Index werken we vaak tegelijk aan meerdere projecten en producten. Werk je met scrum dan wordt er commitment gevraagd van het hele team bij het plannen en verdelen van het werk. Dit kost veel tijd en hierdoor ben je minder flexibel. Daarnaast moet je na een aantal weken een werkend deel af hebben, wat vaak onnodig stress oplevert. Zeker wanneer dit er constant is doordat er aan meerdere projecten tegelijkertijd wordt gewerkt.

Wat is de Kanban methode?

Kanban is een populair framework dat wordt gebruikt om agile softwareontwikkeling te implementeren. De kracht van Kanban zit vooral in het onzichtbare zichtbaar maken en in de kunst om niet alles tegelijk op te pakken, maar juiste in delen aan projecten te werken.

Werkitems worden visueel weergegeven op een Kanban board, zodat teamleden op elk moment de status van het werk kunnen zien. Het voordeel van het gebruik van Kanban is dat er gewerkt wordt volgens een continue flow met als doel het eindresultaat. In plaats van dat het hele team de belangrijkheid van issues bepaald, doet bij Kanban de product owner van een project dit. Hij/zij bepaald wat de belangrijkste issues zijn en plaatst deze bovenaan in het board. Dit kost voor de product owner wat meer tijd, maar geeft het team juist meer development tijd.

Deze hybride vorm van Scrum en Kanban geeft het team meer flexibiliteit en verkort de tijd die gemiddeld aan meetings wordt verspild.

Waarom kiezen voor de combinatie tussen Scrum en Kanban?

Sinds kort werken wij volgens de Scrumban methode, een combinatie tussen Scrum en Kanban. Vanwege de vele projecten die wij naast elkaar draaien, is dit een passende oplossing. Deze hybride vorm van Scrum en Kanban geeft het team meer flexibiliteit en verkort de tijd die gemiddeld aan meetings wordt verspild. Bij Scrumban gebruiken we de rollen en events van Scrum, met uitzondering van de sprintplanning. In plaats van het plannen van een sprint, zorgt de Product Owner dat de Product Backlog altijd geprioriteerd is, voor wanneer er ruimte is voor het oppakken van een nieuw product. Het werk wordt opgedeeld in brokken van min-of-meer gelijke grootte. Dit zorgt ervoor dat de output van het team inzichtelijk wordt.

WIP (Work In Progress) Limiet

Het belangrijkste is dat het werk wordt afgemaakt. Bij Scrum loopt de druk vaak op en processen komen overvol te zitten, waardoor dit niet altijd lukt. Een WIP-limiet, onderdeel van de Kanban methode, creëert een ‘pull’ model waarbij werk kan worden opgepakt als daar capaciteit voor vrijkomt. Er wordt dus pas een nieuwe opdracht opgepakt als een oude af is.

Van Scrum naar Scrumban

Een belangrijk verschil tussen Scrum en Kanban is dat er bij Kanban limieten aan de lanes zijn gekoppeld. Dit zorgt ervoor dat er nooit meer issues zijn, dan dat er opgepakt kunnen worden door de developers. Bij Scrumban moet je iets zo snel mogelijk van links naar rechts verplaatsen op een board. Belangrijk is om af te maken waarmee je start en daarnaast kun je elkaar helpen als iemand vastloopt.

Bij Scrumban wordt er in tegenstelling tot bij Scrum, vooraf geen inschatting meer gedaan op de issues. Hoelang het gaat duren is dus niet concreet bekend. Wel meten we hoeveel issues er gemiddeld in bijvoorbeeld een week, een maand of een jaar afgerond (kunnen) worden. Op basis van deze gemiddelde snelheid (velocity) kunnen we globale planningen afgeven voor nieuwe projecten. Door het aantal issues van het project te vermenigvuldigen met onze gemiddelde doorlooptijd per issue, krijgen we een goed beeld van de totale ontwikkeltijd van een nieuw project.

Voor een bedrijf van onze omvang werkt deze manier beter en besparen we kostbare tijd en verhogen we onze productiviteit. Zo kan er met een één team effectief aan meerdere projecten gewerkt worden.

Wil je graag meer informatie over hoe wij deze nieuwe methode geïmplementeerd hebben, hoe je dit het beste binnen jouw bedrijf kunt toepassen of heb je andere vragen/opmerkingen? Neem dan even contact op.