STATIK voor Kanban implementaties

Leestijd: 16 min.

STATIK is een op systeemdenken gebaseerd proces voor Kanban implementaties. Een acroniem voor Systems Thinking Approach To Introducing Kanban.

De STATIK methode bestaat uit 8 iteratieve stappen. Per stap zal worden toegelicht wat er in de betreffende stap dient plaats te vinden, gevolgd door een toelichting en een werkvorm. Elke stap eindigt met een voorbeeld van een user story en mogelijk te hanteren criteria.

Zoals bekend is de Kanban methode beschreven door David Anderson. STATIK is zijn benadering voor het (hernieuwd) introduceren van Kanban in organisaties. Mike Burrows heeft het boek ‘Kanban from the inside’ geschreven en beschrijft STATIK als volgt:

‘STATIK is een herhaalbare (en humane) manier om met Kanban te beginnen en een manier om bestaande implementaties nieuw leven in te blazen.’

We gaan er in dit uitgebreide artikel vanuit dat een facilitator je helpt om Kanban te introduceren in jouw werkomgeving. Door dit artikel te lezen, weet je wat de 8 STATIK stappen inhouden.  

Weet je nog niet wat Kanban is? Lees dan eerst het artikel: Wat is Kanban?

STATIK en systeemdenken

Vrijwel iedereen is bekend met het Kanban concept: To Do, Doing en Done, maar dit eenvoudige concept is niet voldoende om een Kanban te implementeren in de organisatie. Kanban is veel dieper en breder dan dit bekende basisconcept.

In het boek ‘The Fifth Discipline’ van Peter Senge adviseert Senge om organisatiepatronen te analyseren vanuit een breed gezichtspunt. Alleen met een integrale aanpak overzie je het geheel. Hij gebruikt daarvoor systeemdenken.

Systeemdenken is een manier om te begrijpen hoe een systeem zich als geheel gedraagt in plaats van analyse van afzonderlijke onderdelen. Het is derhalve een noodzakelijk ingrediënt bij de invoering van STATIK methode in een organisatie.

STATIK biedt 8 stappen die je kunnen helpen om tot een geslaagde Kanban introductie te komen. Als je deze 8 stappen slechts doorloopt om te kunnen produceren, zal je echter niet slagen in je doelen. Want naast het toepassen van systeemdenken is een cultuurwijziging veelal nodig. Denk dan bijvoorbeeld aan een Kaizen cultuur.

Kanban deelt niet het Agile-principe van cross-functionele autonome teams. Binnen Kanban kan een dienst een functionele eenheid zijn, een agile delivery team, een productteam of een groep van teams.

De STATIK methode is een iteratief proces

De STATIK methode bestaat uit 8 stappen, maar dit zijn iteratieve stappen! Het is dus niet noodzakelijk om ze in de straks genoemde volgorde te laten plaatsvinden. Veel belangrijker is dat het geleerde in een bepaalde stap wordt gebruikt in de volgende stap.

Voordat je start met STATIK is het belangrijk om je te realiseren dat de 8 stappen van STATIK bedoeld zijn voor toepassing op één dienst. Beperk je indien mogelijk tot de introductie van deze ene dienst. Het is immers gemakkelijker om met één dienst te starten.

Dit zal in de meeste gevallen niet mogelijk zijn, dus zal je meerdere werkstromen integreren en dan pas je de Kanban in de volledige omvang toe om de vraag en de stroom tussen de verschillende diensten in evenwicht te brengen en voortdurend te verbeteren.

Reverse STATIK is een omgekeerde STATIK. Een begrip van Burrows. Ook dit is een iteratieve aanpak die je kan helpen inzicht te krijgen in de processen die reeds binnen een team bestaan. Het wordt echter ook veel toegepast om op eerdere stappen terug te komen. Voor een validatie, verbinding of verdieping.

STATIK methode voor een Kanban implementatie  

Volgens Anderson start een Kanban implementatie met de 8 stappen van STATIK. Het bijzondere is dat Anderson, start met stap 0 die dan niet mee telt in de overige 8 stappen.

Stap 0 is het Identificeren van diensten en voor elke dienst doorloop je het 8 stappenplan:

1. Begrijp wat de dienst geschikt maakt voor het doel van de klant.
2. Begrijp de bronnen van ontevredenheid (in het huidige systeem).
3. Analyseer de vraag.
4. Analyseer de huidige capaciteit.
5. Modelleer de werkstroom.
6. Identificeer en benoem de classes of service.
7. Ontwerp het Kanban systeem.
8. Socialiseren en onderhandelen over de implementatie.

Bovenstaande stappen is een letterlijke vertaling van de door Anderson beschreven stappen. Mike Burrows, van het eerder genoemde boek, voegt stappen samen.

In dit artikel hanteren we de 8 stappen van Anderson, maar de benaming per stap is krachtiger beschreven.

Een Kanban implementatie in 8 stappen!

Elke stap zal achtereenvolgens beschreven worden. Per stap zal worden toegelicht wat er in de betreffende stap dient plaats te vinden, eventueel een werkvorm en elke stap eindigt met voorbeeld van een story en bijbehorende criteria.

Stap 1: Purpose

De eerste stap van STATIK richt zich op het begrijpen wat de dienst geschikt maakt voor het doel van de klant.

In andere woorden is dit dus het onderzoeken van de ‘fitness of the purpose’. Beter te omschrijven als: Begrijp wie je klant is en wat succes voor hem betekent!

Deze sessie start dus dat het team minimaal de Wie, Wat en Waarom vragen stelt, maar het advies is om alle 5W2H erbij te pakken.

Hou gedurende deze stap goed je doel in de gaten. Je wilt een Kanban systeem neerzetten, derhalve ben je op zoek naar inzichten. Deze stap is echter ook bedoeld om de teamleden het huidige systeem en de systemische relaties te begrijpen. Ook zal men elkaar beter leren kennen.

Dus kijk je in deze stap ook naar het team en laat je het team samen de eerste stap al doorleven. In de meeste gevallen is hier ruimte nodig om het team met elkaar te laten praten over de purpose en wat dit voor hen persoonlijk betekent.

De eerste stap vervult dus meerdere doelen en behoeften, helaas wordt deze stap weleens overgeslagen. Vooral bij minder volwassen teams of beginnende kanban teams. Het lijkt immers zo duidelijk, ‘de purpose’, dat is een gegeven, waarom zouden we daar over hebben?

Het overslaan van het bespreken van de purpose komt vrijwel altijd als een boomerang terug in de opvolgende stappen.

Werkvorm purpose

Om een beeld te geven wat er bijvoorbeeld kan plaatsvinden in deze stap een werkvorm:

• Teampurpose: beschrijf wat het team doet in 5 of 6 woorden en wat het gaat leveren.
• Voor wie doe je het? Wie zijn de stakeholders en welke rol vervullen ze?
• Waarom doen we het? Wat heeft de klant eraan? Het is belangrijk dat je het doet, toch? Beschrijf dus welke impact het op de klant heeft.
• Vervolgens onderzoek je welke criteria de tevredenheid van de klant bepalen. Denk daarbij bijvoorbeeld aan snelheid, kwaliteit, veiligheid en voorspelbaarheid. In deze fase gaat het vooral om de geschiktheidscriteria duidelijk te krijgen. Welke criteria zijn relevant om te kunnen meten, want deze wil je later in het proces in KPI’s of OKR’s kunnen vatten.
• Zodra je deze criteria hebt bepaald ga je onderzoeken welke minimale waarde bij deze criteria hoort. Lees minimaal als aanvaardbaar, goed genoeg of geschikt voor het doel. In menig organisatie is er daarna behoefte aan Service Level Expectations (SLE) of Service Level Agreements (SLA). Deze kun je door het eerdere onderzoek beter bepalen.

Let wel, deze KPI’s, OKR’s, SLE’s en SLA’s zijn slechts een startpunt van het iteratieve proces. Ze behoren niet tot de ‘harde’ eisen, maar dienen gezien te worden als de aanjagers van de verandering.

Hoe ziet de user story er wellicht uit?

User story: purpose

Als teamleden willen we ons doel definiëren en valideren, ons vermogen om dat doel te vervullen beschrijven en de voorwaarden voor succes definiëren, zodat we een sterk gevoel van onze teamidentiteit hebben.

Acceptatie criteria

Het is de bedoeling dat je niet alleen een story opstelt, maar direct ook de criteria benoemd. Een voorbeeld hiervan:

• We hebben een missieverklaring (en team slogan) opgesteld.
• Onze waarden en ondersteunende normen zijn bekend. De bekende zin die je daarbij hanteert is: We geloven in… daarom zullen we…
• We hebben (hoog over) de voorwaarden voor succes gedefinieerd
• We zijn in staat om aan de behoeften van de klant te voldoen

Stap 2: Ontevredenheid

De meeste veranderingen starten door de bronnen van ontevredenheid in het huidige systeem te onderzoeken en te begrijpen. Hierdoor ontstaat de ruimte om de waargenomen realiteit te veranderen naar de gewenste toekomst.

Dit is het moment voor alle teamleden om hun ongenoegen te laten blijken over het huidige systeem. Het is wel de bedoeling dat men interne en externe factoren benoemd.

Bij het benoemen van de interne en externe ontevredenheden komen de eerste signalen hoe het team en de cultuur van de organisatie is. Heel herkenbaar kan dan zijn: de interne gerichtheid of juist niet (bijv. uit angst) of het mogelijk ontbreken van een externe gerichtheid (bijv. geen toegestane ruimte of geen interesse).

Werkvorm ontevredenheid

Een werkvorm die hierbij goed past is te kijken vanuit de klant en pas daarna vanuit de interne organisatie. Dan blijkt tevens dat deze ontevredenheden regelmatig goed met elkaar kunnen worden gecombineerd. Vaak is de oplossing van een klantprobleem, een oplossing van een intern probleem en vice versa.

Om het combineren goed te laten verlopen ga je de ‘ontevredenheden / problemen’ groeperen en prioriteren. Dit is absoluut nodig om focus in de vervolgstappen te behouden.

Deze stap behoeft in de meeste gevallen een facilitator. Het probleem is veelal niet om gezamenlijk tot een priorteitenlijst of een indeling tot stand te brengen, maar in deze stap ontstaat de eerste weerstand. De mogelijk enorme omvang van de verandering wordt nu duidelijk!

User story: Ontevredenheid

Als teamleden willen we ontdekken welke gebieden voor verbetering vatbaar zijn, wat onze klanten en stakeholders zeggen, en met welke leverings- of kwaliteitsuitdagingen we worden geconfronteerd, zodat we klantgerichter kunnen zijn en een backlog kunnen opbouwen voor voortdurende verbetering.

Acceptatie criteria

• We hebben alle relevante bronnen van ontevredenheid en/of zaken waarmee we worstelen blootgelegd
• We hebben zicht op en inzicht in de feedback van klanten en/of stakeholders
• Er is een backlog voor verbetering gecreëerd of geactualiseerd

Stap 3: Analyseer de vraag

Deze derde stap in de STATIK methode is bedoeld om de vraag goed te begrijpen. Eigenlijk is het de eerste stap nogmaals verrichten, maar nu op een kwalitatieve wijze. Je gaat op zoek naar de verwachtingen van de klant. Dit kan dus weer een volzin worden, zoals beschreven in de story  die straks volgt.

Je bent op zoek naar de analyse van de vraag, maar je gebruikt deze stap ook om het begrijpen en beheren van het systeem helder te krijgen. Het is een stap waar systeemdenken van het team een grote stap kan maken, als patronen zichtbaar worden voor iedereen.

Wat in deze stap ook beoogd wordt is een shift in mindset. Wat je aan de ‘zachte kant’ wilt bereiken is dat men van het oppakken van opdrachten en ‘eisen’ doorstapt naar een state of mind waar men een capaciteit hanteert om te anticiperen op verandering, deze te exploreren en daardoor de behoeften op een juiste manier en tijd invullen.

Het is de bedoeling dat men na deze stap begrijpt welke kennis er nodig is in elke stap van het proces en dat een correcte implementatie bestaat uit klantvalidatie, samenwerking met de klant, toewijzingen van gelden en afspraken.

Werkvorm vraaganalyse

Een veel gebruikte werkvorm is dan om ‘work in progress’ te delen. Hiermee vlieg je het op een andere manier aan dan in de eerste stap.

• Je laat iedereen aan de slag gaan met post-its om op te laten schrijven wat men nu doet. Dit wel aan de hand van een bepaalde structuur.
• Deze werkvorm is simpel, laat de antwoorden op onderstaande vragen op post its plaatsen en plaats dit op het bord.
• Start met op te schrijven wat men nu doet!
• Wie is de aanvrager?
• Met welke frequentie dit soort activiteit gevraagd wordt.
• Waarom doen we deze activiteit?

Deze werkvorm dient zonder meer het systeemdenken, maar je hebt ook de aard van de vraag nodig. Stel dus aanvullende vragen als: Wie zijn de in- en externe klanten en hanteer de 5W2H methode om de benodige werkitems te identificeren. Een beperkt aantal voorbeelden:

• Wat is het volume?
• Welke verwachtingen zijn er?
• Kan er onderhandeld worden? Hoezo en door wie?
• Wanneer is de vraag?
• Hoeveel verschillende vragen zijn er?
• Zijn er seizoensinvloeden?

De uitdaging voor het team is veelal het abstractieniveau, hoe diep en hoe breed dien je te gaan. Het is op zoek gaan naar een evenwicht: naar het voldoende voor nu!

Voor deze stap is de volgende story een voorbeeld.

User story: vraag analyseren

Als teamleden moeten we bronnen van de vraag analyseren, inclusief soorten, frequentie en complexiteit van werkverzoeken, zodat we inzicht hebben in de aard en impact op ons werk

Acceptatie criteria

• primaire (zo niet alle) bronnen van vraag (van wie/waar)
• werk item types 
• frequentie
• complexiteit en impact van verzoeken

Stap 4: Analyse van de capaciteit

De vierde stap van STATIK is het analyseren van de capaciteit. Dit omvat het bestuderen van historische gegevens over de levering van diensten. Voorbeelden hiervan zijn: doorlooptijd, kwaliteit, voorspelbaarheid etc.

Eigenlijk start het team met de gap-analyse: wat zijn de huidige verwachtingen van de klanten versus de huidige capaciteit. Je gaat samen met het team eerst onderzoeken wat de prestatie tot nu toe is. Verwacht dus wat spanningen!

Deze spanningen helpen ook om vaardigheden en capaciteiten die we nodig hebben bespreekbaar te maken. Je wilt vertrouwen in het team dat ze het gaan fixen.

Werkvorm capaciteit

Er is veelal een moverende redenen om over te stappen naar een nieuwe werkmethode. Dat men kiest voor Kanban is een logische keuze, maar de aanleiding kan zowel een negatieve als positieve achtergrond hebben.

Een handige werkvorm is om te starten met wat er is geleverd door het team. Doorlooptijden, hoeveelheid, hoeveel tijd het in beslag nam, wat er per week geleverd wordt (over een aantal weken terug kijkend). En nog veel meer.

Stel een oordeel uit, want het doel is om nog beter te begrijpen welke vragen het team heeft gehad. Is er bijvoorbeeld ook feedback geweest?

Hou het primaire doel in het oog: het valideren van de soorten vragen die eerder zijn gedeeld en om het concept van efficiëntie en kanban metrics uit te leggen.

Wees je ervan bewust dat de beschikbare informatie vaak incompleet of vaag is, daarom wordt deze stap vaak overgeslagen. Maar nogmaals, je bent op zoek naar historische gegevens over geleverde diensten. Je wilt samen verbeteren.

Want één ding is inmiddels wel duidelijk: er is in stap 2 een ontevredenheidsanalyse uitgevoerd die vermoedelijk een behoorlijke discussie en inzichten heeft opgeleverd.

Story: capaciteit analyseren

Als teamleden moeten we onze capaciteiten analyseren om te reageren op de werkitems, we hebben inzicht in de vaardigheden en capaciteiten die we nodig hebben, zodat we vertrouwen hebben in ons vermogen om effectief te leveren en ons werk te optimaliseren.

Acceptatie criteria

• Identificeer onze capaciteit om ons te concentreren op het werk dat voor ons ligt.
• Identificeer de kernvaardigheden en -capaciteiten die nodig zijn om te leveren.
• Overeenstemming bereikt over belemmeringen, lacunes of risico’s voor ons vermogen om effectief te leveren.

In onderstaande afbeelding wordt weergegeven hoe de vraag en capaciteiten zich tot elkaar verhouden. Voordat je start met stap 5 de workflow, is het interessant om onderstaande Reverse STATIK techniek eens toe te passen. Is er sprake van balans tussen vraag en capaciteiten?

Stap 5: Workflow

In stap 5 van de STATIK methode wordt de workflow geanalyseerd voor elk type vraag dat eerder is vastgesteld.

Over het begrip workflow is heel veel geschreven en wordt nog steeds gediscussieerd, wellicht is volgende beschrijving toereikend:

Workflow is de opeenvolging van stappen die worden gezet om een bepaalde activiteit af te ronden.

Voor kenniswerkers moet de workflow worden gezien als de opeenvolging van de belangrijkste stappen om iets te weten te komen over een onderwerp waar we mee bezig zijn.

Werkvorm workflow

Laat het team met post-its de workflow in kaart brengen. Breng de de activiteiten in kaart niet de functionele verhoudingen of specialisaties. Dit is een iteratief proces, tijdens deze werkvorm zal regelmatig blijken dat men e.e.a niet helemaal scherp heeft. Dat is juist goed, het geeft nieuwe inzichten.

Het gebruiken van post-its op een brown paper vereenvoudigd het wijzigen tijdens het gesprek, in het geval dat er een digitaal format wordt gehanteerd is het wellicht handig als iemand het proces bewaakt. Anders verschuiven mogelijk de digitale post-its te snel, zonder de benodigde discussie.

Het is echter verstandig om je te focussen op de belangrijkste vraagsoorten. Waarbij je ook nog een prioritering aanbrengt, want dit geeft je meer inzichten, voordat je totale workflow analyseert.

In Kanban is een sterke focus op het werk en wat ermee gebeurt. Men ziet graag dat kanban systemen en borden samenwerking aanmoedigen. Men beoogd daarmee ook voorbij te gaan aan bestaande functionele verdelingen of specialisaties.

Een Kanban workflow is iets anders dan Value Stream Mapping of Gemba Walk. Workflow in Kanban is het in kaart brengen van activiteiten en niet de handoffs tussen mensen.

User story: workflow

Als teamleden moeten we modelleren hoe het werk door ons team en systeem stroomt, zodat we zicht hebben op waar we expliciete beleidslijnen en potentiële knelpunten moeten definiëren als we ons Kanban-systeem ontwerpen

Acceptatie criteria

• Visuele voorstelling van hoe het werk door het team stroomt.
• Activiteiten die de meeste kennis opleveren worden geïdentificeerd.
• Markeer potentiële knelpunten of hiaten die moeten worden opgelost.

Stap 6: Classes of service

In het Nederlands: klassen van diensverlening. De ervaring leert dat Classes of service veel onbekendheid met zich meebrengt. Enige uitleg is veelal gewenst.

Classes of service zijn beleidsregels over hoe een item door het team moet worden behandeld, gegeven zijn kenmerken. Classes toepassen geeft duidelijkheid in prioritering en helpt erg goed bij het inplannen.

Bij minder volwassen teams wordt vaak de prioritering uit stap 4 gehanteerd en slaat men deze stap over, want de classes of service kunnen voor minder volwassen teams verwarrend zijn. De verwarring ontstaat door het prioriteren op hoger niveau versus het prioriteren tussen tickets met verschillende classes.

Deze klassen beschrijven namelijk ook de prioriteit tussen tickets, dit is in Kanban nodig want classes beïnvloeden de workflow. Voorbeelden zijn een (verplichte) extra test, meer controlemomenten, planningsvolgorde of dat deze specifieke klasse de WIP-limit mag overschrijden etc.

Specifieke aandachtspunten bij classes of service

Wat je bij het opstarten van een Kanban methode vaak waarneemt is dat er allerlei onduidelijkheden zijn in het prioriteren. Om onduidelijke redenen krijgt de ene ticket een hogere prioriteit dan een andere ticket.

Transparantie is ook in Kanban een vereiste. Een voorbeeld: een wens van een hoger geplaatste krijgt om onduidelijke redenen voorrang. De consequenties hiervan worden niet of nauwelijks besproken. Vanaf nu  maakt men dat inzichtelijk en stelt men de vraag of dat wel gewenst is.

Het team dient zich terdege bewust te zijn dat er zijn 3 vormen van klassen zijn: verborgen -, impliciete – en (afgesproken) expliciete klassen. In Kanban is de afspraak dat alle klassen expliciet en dus open dienen te zijn.

De gebruikelijk indeling van classes of service

De gebruikelijke klasse indeling die je in Kanban ziet zijn: spoed, vaste datum, standaard en immaterieel. Deze worden in onderstaande afbeelding toegelicht.

Werkvorm classes of service

Als je gebruik maakt van de classes of service dan is de volgende werkvorm interessant:

• Gebruik een whiteboard of een digitale variant hiervan.
• Vraag het team om voorbeelden te noemen per klasse.
• Waarom classificeert deze zich in een van de klassen?
• Vraag een korte toelichting.
• Laat de voorbeelden groeperen.
• Ga daarna circulaire vragen stellen per voorbeeld of groepering om de mening van anderen te horen.
• Het actiepunt is de gemaakte keuzes vast te leggen.

Het doel is om een gemeenschappelijk inzicht te creëren aan welke voorwaarden een klasse indeling dient te voldoen. Vervolgens worden ze vastgelegd als regels (expliciete beleidslijnen), omdat het nieuwe ontwerp van het kanban systeem daar aan dient te voldoen.

User story: Classes of Service

Wederom volgt een story, ditmaal voor de zesde stap van de STATIK methode.

Als teamleden moeten we de verschillende klassen van dienstverlening definiëren die specifieke, expliciete beleidslijnen (regels) vereisen, zodat we in staat zijn om ons Kanban systeem te ontwerpen om de workflow effectief te optimaliseren en iedereen bewust te maken van de “rules of engagement”

Acceptatie criteria

• De belangrijkste klassen van dienstverlening zijn gedefinieerd, inclusief prioritering, afspraken over het serviceniveau, Definition of Done, enz.
• Het team is het eens over expliciete beleidslijnen (regels) met betrekking tot elke Class of Service

Stap 7: Het kanban systeem modelleren

Een mooi moment, we gaan alle verkregen systeemkennis en inzichten samenvoegen om het kanban systeem vorm te geven.

Deze stap bestaat uit 4 elementen: het totale kanban systeem, ticket ontwerp, bordontwerp en afspraken over de ritmieken (kanban cadences).

Laten we dit beperken tot de 2 componenten die toelichting behoeven: het bord en een afspraak over de cadans (de ritmiek).

Bord

Vergeet daarbij nooit het basisprincipe van een bord bij de start van een kanban systeem: visualisatie van het werk!

Een kanban bord geeft inzichten, door de opbouw en de inhoud. Heel herkenbaar zijn de kolommen waar je mee start, want de workflow valt in te delen in aparte stappen. Men hanteert hier vaak twee vormen: naar soort vraag en activiteiten (kolommen) en classes of service (rijen).

In deze stap worden zeer veel beslissingen genomen, het advies is om het team te begeleiden in deze stap. Men heeft veel geleerd, maar het toepassen vraagt enige ervaring. Het gaat namelijk om o.a. workflow, tickets per workitem, de service klasse, de start- en vervaldatum, verstreken tijd, speciale eisen, statussen, risico’s etc.

Kortom, alle inzichten die het team eerder als noodzakelijk heeft benoemd. Bij twijfel of iets echt nu op het bord moet, kan je het team nog even challengen met de vraag of het ‘het onderwerp’ invloed heeft op de selectie of volgorde of planning van werkitems.

Focus het team vooral op de belangrijkste zaken: het onderhanden werk, de items en de bijbehorende status, soorten werk, classes, impediments en eventueel de eerste stap naar WIP-limits. WIP-limits zijn veelal gekoppeld aan de volwassenheid van het team, hou het starten vooral simpel!  

Wellicht is de belangrijkste tip om niet in één keer het ‘perfecte’ bord te willen samenstellen. Men heeft de neiging om ‘alles’ op het bord te willen plaatsen, echter zijn veel zaken nog niet nodig in het nu. Laat het bord iteratief groeien!

Het bord wat je uiteindelijk ziet is een weerspiegeling van voorgaande stappen. Hoe complexer de werkstroom, des te complexer het bord en vice versa. In een aantal gevallen zijn er twee borden nodig, maar dat wordt nu niet verder beschreven.

Ritmieken

Welke ritmieken van de Kanban methode ga je hanteren? Overigens hanteert men in Kanban ‘cadences’ als term. Je gaat nu beslissen welke bijeenkomsten in de nieuwe implementatie worden gehanteerd.

Denk na over welke cadans je kiest, spreek een frequentie en duur af, wie aanwezig moet of mag zijn, welke informatie er door wie dient te worden ingebracht, welke metrics, welke beslissingen en wie faciliteert? Ook hier geldt: start met wat NU nodig is.

User story: ontwerp kanban systeem

Als teamleden hebben we de voorwaarden van ons werk gedefinieerd en geanalyseerd om een kanban-systeem te kunnen ontwerpen, zodat we kunnen beginnen met het beheren en verbeteren van onze nieuwe manier van werken.

Acceptatie criteria

• Alle teamleden stemmen in met een initieel kanban systeem dat hen in staat zal stellen om te beginnen met het beheren en verbeteren van de werkstroom.
• Het kanban systeem is zichtbaar voor iedereen.

Stap 8: Uitrol

In stap 8 van de STATIK methode wordt als eerste het bord door het team gemaakt, hierdoor wordt een nieuwe start gemaakt. Een te markeren momentje voor het team!

De belangrijkste tip hier is om feedback te krijgen van iedereen die een relatie heeft met het systeem (stakeholders) en die niet heeft deelgenomen aan de vorige fasen van de STATIK.

Daarna bereid je het communicatieplan voor. Je wilt namelijk feedback krijgen van iedereen die een relatie heeft met het systeem (stakeholders) en die niet heeft deelgenomen aan de vorige stappen in het STATIK proces. In plaats van werkvormen volgen nu de 2 buy-in sessies.

2 buy-in sessies voor de uitrol

Anderson adviseert 2 ‘buy-in sessies’: een sessie met de opdrachtgever of leider en een sessie met de stakeholders.

Uitrol sessie 1: buy-in met opdrachtgever of leider

Het is raadzaam om de leider of opdrachtgever mee te nemen in de verandering. Een goede leider is al betrokken gedurende de verandering, maar ziet nu wellicht voor de eerste keer het eindproduct. Tijd om commitment te krijgen, het is dus letterlijk een buy-in sessie.

Het team is trots op het vele werk, maar de eerste feedback kan teleurstellend zijn. Anderson benadrukt dat een nederige houding van belang is, men heeft vermoedelijk voorheen een niet toereikende dienstverlening gebracht. Een nieuw bord of werkwijze is ook niet gelijk aan een bewezen verbetering van de dienstverlening, ook al is er ontzettend hard gewerkt.  

De boodschap dient te zijn, dat de manier van werken verandert, dat deze in eerste instantie intern gericht is, maar dat de externe omgeving gaat ervaren dat men anders met hun omgaat. Hier verhaal je het transparant maken van het indienen van verzoeken tot en met de rapportage.

Realiseer je terdege dat de opdrachtgever of leider niet bij alle voorgaande sessies aanwezig is geweest en zeker nog niet op de hoogte is van het hernieuwde en gedeelde inzicht die het team in de voorgaande stappen heeft verkregen.

Vanzelfsprekend legt men uit hoe het bord werkt vanuit het gezichtspunt van de leider.  Je krijgt gegarandeerd feedback, ga daar goed mee om en verander zaken als er aanpassingen noodzakelijk zijn. Neem deze veranderingen mee, pas aan en koppel terug.

Afhankelijk van de verkregen feedback gaat men opnieuw langs bij sommige belanghebbenden om te verifieren dat er voldoende rekening is gehouden met de geuite  zorgen. Als je dit gedaan hebt, ben je klaar om een kick-off meeting te houden met alle stakeholders.

Uitrol sessie 2: buy-in met stakeholders

In deze sessie vertel je eerst over de aangebrachte veranderingen om beter werk te kunnen leveren.

Ook in deze sessie kun je feedback verwachten, besteed dus vooraf tijd aan degenen waarvan de rol of bevoegdheden veranderen. Denk dus op voorhand na over hoe je dit brengt. Idealiter zorg je ervoor dat het geen nieuwe informatie is, die men voor de eerste keer verneemt in deze sessie.

Vervolgens leg je uit dat middelen niet oneindig zijn en dat compromissen moeten worden gesloten. Dat wat goed was blijft en dat men zich richt op te kunnen verbeteren. Leg vervolgens (in detail) het systeem en het bord uit. Tot slot meld je de gewijzigde ritmieken en wanneer en op welke wijze ze kunnen aansluiten.

User story: uitrol

Als team moeten we in staat zijn om te beginnen met het uitvoeren en meten van ons werk en uit te vinden wat onze huidige belemmeringen zijn, zodat we meteen aan de slag kunnen en idealiter in staat zijn om een increment of wijziging in productie te nemen in onze eerste sprint.

Acceptatie criteria

Maak een (digitaal) bord met:

• Tools die we nodig hebben
• Kennis die we nodig hebben
• Omgevingen die we nodig hebben
• Mensen die we nodig hebben
• Identificeer en communiceer belemmeringen voor het leveren van een shippable product increment
• Maak de technische backlog van het team (user stories w / acceptatiecriteria)
• Communicatieplan en feedback loop voor belanghebbenden gereed.

Tot slot

STATIK is een krachtige methode om Kanban te introduceren of de huidige Kanban methode te herijken.

Zoals je verwacht is de methode slechts een deel van het gehele plaatje. Een succesvolle Kanban implementatie is alleen mogelijk met de introductie van een succesvolle Kaizen Cultuur. Lees hiertoe het artikel: Wat is Kaizen?

Binnen een kanban omgeving zijn o.a. de volgende kwalitatieve voordelen haalbaar:

• Verbeterde teamdynamiek o.a. door te werken vanuit vertrouwen
• Toename in voorspelbaarheid.
• Een team dat zichzelf organiseert om het werk te doen.
• Een team met denkers op systeemniveau.
• Hernieuwd leiderschap dat helpt met het verbeteren van het nieuwe proces.

Meer lezen over kanban? Zie de artikelen: Wat is Kanban? of 5 kanban flow metrics of De 6 kanban meetings