safe-kanban-1200

De definitie van Kanban uit wikipedia luidt: Kanban (van het Japanse kan ‘visueel’ en ban ‘kaart of bord’) is een concept gebruikt in lean manufacturing en just-in-timeproductie.

Kanban is een systeem om te signaleren (met bijvoorbeeld kaartjes) wanneer iets nodig is. Kanban kan gebruikt worden om van alles in het leven te organiseren. Kanban is een systeem om de logistieke productieketen te besturen. Kanban werd ontwikkeld door Taiichi Ohno, bij Toyota, om een systeem te vinden waarmee het mogelijk was om een hoog niveau van productie te behalen. Kanban is een van de methoden waarmee JIT (Just in Time) kan worden bereikt.

Kanban werd een effectief middel ter ondersteuning van het beheer van een productiesysteem als geheel. Het bleek tevens een uitstekende manier te zijn om verbeteringen te starten. Probleemgebieden, knelpunten komen namelijk naar voren zodra het aantal kanbankaarten in omloop, en daarmee de hoeveelheid onderhanden werk (WIP limiet), wordt verminderd.

Het meeste bekend is kanban geworden van de borden die bij Scrum worden gebruikt, met bijvoorbeeld de kolommen: ‘backlog’, ‘Doing’, ‘Done’. In SAFe 3.0 werd kanban om voortgang van werk te visualiseren al gebruikt op de portfoliolaag voor de Epic werkvoorraad. Omdat Scrum op de teamlaag werd toegepast is het te veronderstellen dat ook daar kanban werd toegepast, al was dat niet gevisualiseerd op de grote plaat (Big picture).

Kanban als werkwijze versus Scrum

Kanban is, naast de betekenis van het bord om voortgang te visualiseren ook geassocieerd met de werkwijze Kanban. Het wijkt af van Scrum in die zin dat er niet in sprints wordt gewerkt, maar volcontinu de backlog items van de backlog worden ‘ge-pulled’ en binnen WIP (Work in Process) limieten, verwerkt.

Wat mij betreft vergt dit een nog grotere discipline dan Scrum. Dus ik raad teams altijd aan om eerst de discipline van werken in sprints aan te leren met alles wat daaraan vastzit, en dan pas over te stappen op kanban als ze dat willen. Meten en continue verbeteren kunnen anders wel eens ondergeschoven kindjes worden. Ondersteunende teams als het System team kunnen baat hebben bij het werken in kanban. Maar ook die hebben baat bij het eerst leren te werken in sprints, en per sprint hun werk te plannen en reviewen, en zichzelf te verbeteren.

Kanban op alle lagen

Op alle lagen van SAFe 4.0 is nu Kanban als visualisatie van de voortgang van een backlog geplaatst. Dit omdat het gewoon een mooi middel is om voortgang te visualiseren, te communiceren, rapporteren, en om de belasting cq. omvang van het team aan te passen naar behoefte.

Op de value stream laag ziet deze er als volgt uit nu:

value-stream-epic-300x133

Het bovenste deel geeft de mogelijkheid om, ook te werken met value stream Epics, maar is optioneel.

Het onderste deel is gewoon een kanban als op de portfolio laag met een Funnel kolom, Analysis kolom, dan de Value Stream backlog, Implementing en Done Kolom.

Funnel: In de funnel komen vers opgesplitste capabilities binnen, die met WSJF kunnen worden geprioriteerd. Volgens die prioritering worden ze WIP limited opgepakt in Analysis.
Analysis: In de Analysis kolom worden de capabilities gedetailleerd (vanuit one-liner (zie figuren in blog deel 2). Dit werk is WIP limited.
Backlog: Dit is de Value Stream backlog. Hierin staan de capabilities in de WSJF volgorde waarin ze ‘ge-pulled’ kunnen worden door een Release train (Program / Domain level).
Implementing: In deze kolom staan de capabilities die ‘ge-pulled’ zijn, en dus in realisatie, of voorbereiding voor realisatie.
Done: In deze kolom staan de capabilities die de definition of Done voor een Capability hebben bereikt, en dus ook in productie zijn.
In principe wordt nu deze visuele manier van voortgang bijhouden van elke backlog op elke laag gepromoot in SAFe 4.0. Het is aan de medewerkers van de domeinen die ermee werken om het werkelijk te doen. Maar gezien de resultaten die ik tot dusver in de praktijk zie, zeg ik, doen!!!

Argument dat ik wel vaak hoor tegen dit instrument is dat men het al, of ook, digitaal bijhoudt. ‘Dan moeten we alles dubbel bijhouden!!!’, hoor ik dan.

Dan is mijn argument, zoals ik al vaker verwoordde in mijn blogs de volgende:

Het dient twee verschillende doelen:

Visueel: dient voor communicatie en rapportage aan management (‘Gemba walk’, management moet zelf poolshoogte van voortgang nemen op de werkvloer);
Elektronisch: dient voor audit trail, accounting, traceability, gedistribueerd werken, metrics, historie.

Geïnteresseerd in meer kennis over SAFe? Volg de opleiding Leading SAFe ®4.6

 

Heeft u een vraag?

Neem contact op