Recensie The Lean Tech Manifesto - Leren van sotwarebedrijf Theodo

Bij Scrum ontwikkelt een team software stapsgewijs, met continue feedback van de klant. Dit is niet alleen Agile (wendbaar), maar sluit ook aan bij Lean. De hoeveelheid verspilling – functionaliteit die niet aansluit bij de klantbehoefte – wordt namelijk geminimaliseerd.

Maar wat te doen in een grote organisatie met Scrum-teams die van elkaar afhankelijk zijn? Oplossingen zoals het Scaled Agile Framework (SAFe) introduceren veel vergaderingen die de wendbaarheid verminderen.

Is er een andere, meer zelfsturende manier om agile teams op elkaar af te stemmen? Ja, zeggen Fabrice Bernhard en Benoît Charles-Lavauzelle in hun boek The Lean Tech Manifesto:

1. Houd de Scrum-teams zo onafhankelijk mogelijk, door ze modulaire softwareblokken te laten ontwikkelen. Elke onnodige communicatie tussen de teams is namelijk verspilling. De autonomie van de teams wordt verder vergroot door het stimuleren van probleem-oplossend vermogen.
2. Pas Lean-principes toe, zoals visueel management, om alle resterende communicatie te vergemakkelijken. Denk daarbij aan informatie-uitwisseling:
   - om te werken aan interfaces tussen softwareblokken
   - voor het definiëren en delen van best practises
   - om de voice of the customer (de klantwens) overal te laten doorklinken

Klinkt als een geweldig idee! Het vraagt ​​echter wél veel meer van de managers! Het Kanji-symbool op het boek, een lopend persoon, geeft een hint. Managers moeten hun Gemba (werkvloer) zeer frequent bezoeken, en teamleiders krijgen coaching-taken.

The Lean Tech Manifesto is een prima boek, zij het dat het een zwart-witte versie van Lean bepleit, met One Piece Flow productie. Ik vraag me af hoe ze op die manier maatwerk-software bouwen in Theodo Inc., het bedrijf van de auteurs.

Grote softwareprojecten mislukken vaak vanwege de lange doorlooptijd. Als de klant dan eindelijk de resultaten ziet, blijkt het product niet zoals verwacht. Of het is geen adequate oplossing meer voor het probleem dat de klant oorspronkelijk had, omdat de wereld is veranderd!

Sprints
Sinds de publicatie van het Agile manifesto in 2001 is er een veel beter alternatief: Ontwikkel software in kleine en snelle stappen, sprints genoemd, uit te voeren door Scrum-teams (waarbij de naam Scrum verwijst naar het nu en dan kort samenkomen van de teamleden).

De klant geeft feedback na elke stap. Zo wordt softwareontwikkeling een proces van hypothesevorming en leren, en kan het product onderweg worden aangepast aan wat een klant echt wil.

Deze incrementele, en daardoor Agile oftewel wendbare softwareontwikkeling, wordt gedaan door een klein en autonoom multidisciplinair Scrum-team. Eén van de rollen daarin is de producteigenaar. Als ‘stem van de klant’ beheert hij of zij een ‘backlog’ aan ‘user stories’. Elk van die gebruikersverhalen wordt vervuld door een nieuwe software-sprint.

Stapsgewijze software-ontwikkeling met continue klant feedback werkt prima als één (Scrum) team dit doet. Maar wat als Agile-teams afhankelijk van elkaar zijn? Dit is dé uitdaging in grote software-bedrijven zoals Theodo, het bedrijf van de auteurs van The Lean Tech Manifesto

Problemen
Agile werkt vaak goed binnen één team. Maar als een organisatie groter wordt, beginnen de problemen! Dan komen er meerdere softwareteams, die van elkaar afhankelijk zijn. Ook staat dan niet ieder team meer in contact met de klant.

Daardoor hoor ik (de schrijver van dit artikel) regelmatig klagen over Agile: ‘mijn werk gaat langzamer, omdat we zo werken’.

Hoe onlogisch klinkt dat! Scrum zou namelijk juist moeten zorgen voor meer autonomie en flexibiliteit. Wanneer er echter veel teams zijn, moeten die vaak wachten tot anderen klaar zijn. Of tot er een bijeenkomst is om de werkzaamheden van teams op elkaar af te stemmen. Bovendien raakt de cyclus van feedback vertroebeld, omdat contact met de klant er vaak slechts indirect is.

Soms ontbreekt zelfs de reden om stapsgewijs te werken! Als mensen niet begrijpen waarom al die sprints en bijbehorende Scrum-rollen nodig zijn, is het geen wonder dat ze zeggen: “wat een gedoe, Agile werken!”. Of ze maken die methode belachelijk, door het bombastische jargon ervan te benadrukken.

Controleren
Controleren of mensen wel hard genoeg werken, lijkt soms de reden om Scrum simpelweg overal in een organisatie te implementeren. Dan wordt Scrum een ​​doel op zichzelf. Het is dan geen oplossing meer om je snel aan te passen aan nieuwe inzichten.

Voor de rest van dit artikel ga ik ervan uit dat het zinvol is om Agile te werken: er zijn dan projecten die wensen van klanten moeten vervullen, die vooraf niet helemaal duidelijk zijn. Dan is het logisch om die projecten stapsgewijs uit te voeren, met continue feedback van de klant.

Steeds meer organisaties, ook als die geen software maar tastbare producten maken, hebben deze situatie. Onze wereld verandert snel, en software is steeds vaker een cruciaal onderdeel van producten. Vooral software kan in stukjes worden ontwikkeld en geleverd, variërend van kleine wijzigingen in bijvoorbeeld apps, tot minimal viable (levensvatbare) producten, bedoeld om er zo snel mogelijk achter te komen of potentiële klanten die waarderen.

Team-of-teams
In grotere bedrijven die software ontwikkelen is de grote vraag: hoe creëer je een Agile organisatie die zich gedraagt ​​als een team-of-teams, waarbij het idee levend wordt gehouden dat:

1. Elk team (redelijk) autonoom op klantbehoeften kan inspelen
2. De organisatie continu leert over de wensen van nieuwe en toekomstige klanten.

De meest populaire oplossing hiervoor, 20.000 bedrijven gebruiken het, is het Scaled Agile Framework (SAFe).

SAFe verbindt en synchroniseert Agile-teams horizontaal in zogenaamde ‘treinen’ per te ontwikkelen product, Daarnaast is er, met betrekking tot de productenportfolio, verticale afstemming via tactische en strategische bijeenkomsten. Het idee is dat huidige én toekomstige product‘treinen’ zo optimaal de wensen van de markt vervullen. Zie het kader hieronder.

Scaled Agile Framework (SAFe)
Elke organisatie met zelfsturende teams heeft structuur nodig om chaos te voorkomen. Het Lean Tech Manifesto, zoals besproken in het hoofdartikel, biedt een dergelijke structuur. Er zijn echter veel alternatieven, zoals Holacracy, Squads en Scrum@Scale.

Om het werk van Scrum-teams op elkaar af te stemmen is het Scaled Agile Framework (SAFe) het populairst. Het zorgt voor alignment op vier niveaus, variërend van operationeel tot strategisch. Op elk niveau zijn er rollen die vergelijkbaar zijn met die in een Scrum-team.

SAFe verbindt Scrum-teams die aan hetzelfde klantverhaal werken in 'treinen'
(Saiilant detail: NS werkt zelf ook Agile)

Net zoals het Lean Tech Manifesto past SAFe Lean tools toe, zoals synchronisatie en Kanban. De menselijke kant van Lean, respect for people en het ontwikkelen van probleemoplossend vermogen, lijkt bij SAFe echter afwezig. Bovendien lijkt SAFe veel controlerender en bureaucratischer: het dicteert mensen wat ze moeten doen, in plaats van teams te voorzien van informatie voor zelfmanagement (zoals bij Lean).

Dit zijn de vier niveaus van SAFe:

Operationeel niveau: Dit is het niveau van de individuele Scrum-teams

Tactisch niveau 1: Scrum-teams die aan hetzelfde project werken, vormen een team-of-teams, in een zogenaamde Agile Release Train (ART). Elke 8 tot 12 weken is er een bijeenkomst om de koers en de backlog (de softwareblokken die nog ontwikkeld moeten worden) van elke producttrein bij te stellen. Aanpassingen worden voorgesteld door de 'machinist' van de trein. Deze business owner vertegenwoordigt de klant.

Tactisch niveau 2: Zeer grote projecten vergen samenwerking van meerdere ART’s, je krijgt dan een trein-der-treinen-aanpak.

Strategisch niveau: In de treinmetafoor is dit vergelijkbaar met beslissingen in een spoornetwerk: welke producttreinen gaan er in de toekomst rijden, en welke treinen die nu rijden moeten aangepast worden.

Elke nieuwe trein heeft een EPIC als eindbestemming: een groot (episch) verhaal om klanten te bedienen. Om zo'n ​​EPIC te vervullen, wordt dat verhaal opgesplitst in doelen voor respectievelijk producttreinen op tactisch niveau, en subdoelen voor individuele Scrum-teams (‘wagons’) op operationeel niveau. Deze cascadering van doelen lijkt op Hoshin Kanri (kompas voor management) uit Lean. Subdoelen zijn features (producteigenschappen) die korte gebruikersverhalen moeten gaan invullen. Dit met software die de Scrum-teams ontwikkelen tijdens hun sprints.

Verspilling
Vanuit een Lean-oogpunt zijn de vele extra managementvergaderingen en bijpassende rollen in SAFe verspilling, omdat ze niet direct waarde toevoegen voor klanten.

Maar de situatie is nog erger, zeggen Fabrice Bernhard en Benoît Charles-Lavauzelle in hun boek The Lean Tech Manifesto.

Om dit te begrijpen zoomen ze in op de activiteiten van één Scrum-team in een SAFe-netwerk. Dat team verliest de autonomie om hun werk aan te passen, wanneer dit nodig is om aan klantbehoeften te voldoen!

Ik citeer uit het boek: ‘De Scrum-teams implementeren uiteindelijk alleen nog maar features (opgedragen producteigenschappen, red.) uit een backlog’.

Op die manier vernietigt SAFe de kern van Agile: wendbaarheid. Het management krijgt er controle mee over wat de ontwikkelteams doen, maar hiervoor wordt een hoge prijs betaald. Een groot deel van de mogelijkheid van de teams om software te ‘pivoteren’ (af te stemmen) naar de klantwensen wordt namelijk overgedragen aan het management.

En de betreffende managers staan ​​vér van de plek waar het eigenlijke werk gebeurt, en waar de interactie met de klant zou moeten plaatsvinden.

Benoît Charles-Lavauzelle (links) en Fabrice Bernhard, auteurs van The Lean Tech Manifesto. Zij zijn tevens respectievelijk CEO en CTO van softwarebedrijf Theodo

Inflexibel
Ik ben geen expert op het gebied van SAFe, maar ben het grotendeels eens met Bernhard en Charles-Lavauzelle.

SAFe in volle omvang lijkt dermate bombastisch, dat het softwareontwikkeling net zo inflexibel maakt als in de afgelopen eeuw.

De organisatie van productontwikkeling in ‘producttreinen’ is bijvoorbeeld niet erg wendbaar. Want wat als een team zijn ‘wagon’ wil aanpassen, of merkt dat er andere ‘wagons’ nodig zijn? Daar kan dan pas op worden gereageerd nadat hun ‘trein’ een flinke afstand (tot de eerstvolgende afstemmings-vergadering) heeft afgelegd.

Dit gezegd hebbende, maken veel bedrijven slechts gebruik van bepaalde aspecten van SAFe. Ook bestaan er minder bureaucratische alternatieven, zoals Scrum@Scale, die niet in het boek worden genoemd. Verder er zijn nog andere relatief eenvoudige manieren om zelfsturende teams op één lijn te brengen, zoals Holacracy en Squads.

Alternatief
Voor hun eigen snelgroeiende Amerikaans/Britse bedrijf Theodo, dat met 700 mensen software zoals apps maakt voor b.v. modemerken, bedachten CTO Bernhard en CEO Charles-Lavauzelle een alternatief voor SAFe. Ze noemen dit The Lean Tech Manifesto, de naam van hun boek

De centrale gedachte achter het Lean Tech Manifesto:

1. Zoveel mogelijk autonomie behouden in de Scrum-teams
2. Werkzaamheden van de teams alleen als het echt nodig is op elkaar afstemmen, en dit op een zelf-sturende manier.
3. Alle teams direct of indirect verbinden met de voice of the customer.

En bovenal: veel minder ‘controlerend’ management! Het is meer ‘let it go’, of misschien is het beter om te zeggen: ‘let it flow’.

Een organisatiestructuur opgebouwd volgens Lean beginselen maakt deze veel hogere graad van zelfsturing mogelijk. Denk daarbij aan Lean-principes zoals visueel management, Jidoka, quality first, first-time-right, just-in-time, pull-productie, respect for people, en continu verbeteren.

The Lean Tech Manifesto beschrijft een veel minder bureaucratische en meer zelfsturende wijze om Agile-teams op elkaar af te stemmen, dan het Scaled Agile Framework

Gemba
Dit betekent echter niet, dat het werk van de managers in een Lean Tech netwerk eenvoudiger is vergeleken met een SAFe netwerk. Integendeel!

Zij moeten bijvoorbeeld zeer regelmatig de Gemba, Lean-terminologie voor de plaats waar het werk wordt gedaan, raadplegen. Dit om voeling te houden met de behoeften van zowel de Scrum-teams als de klanten. Let op dit laatste aspect! Managers verzamelen op de Gemba dus ook informatie voor eventuele aanpassing van de bedrijfsstrategie.

De auteurs waarschuwen wel om niet simpelweg alle nieuwe software-functionaliteit te ontwikkelen die klanten wensen, maar om eerst een stapje terug te doen. En dan na te denken over de wens die eráchter zit, het “het werk dat klanten gedaan willen krijgen”. Dit was wat Henry Ford deed, toen hij een auto ontwikkelde als antwoord op de vraag naar snellere paarden.

De Gemba is ook de plek om te horen hoe mensen écht over Agile denken: functioneert het systeem goed of niet.

Uitdagender
Het werk van de Scrum master cq teamleider wordt ook een stuk uitdagender. Zij krijgen als extra de rol van Lean sensei (leraar), die de leden van een Scrum-team helpt om steeds betere probleemoplossers te worden.

Je zou kunnen zeggen dat er in een Lean Tech bedrijf geen klassieke managers zijn. Leiderschap is verspreid over het bedrijf. Er is niemand die nooit ‘vuile handen’ krijgt. Figuurlijk gesproken dan, aangezien het werk softwareontwikkeling is.

Den aan de oude grap van het ei-met-spek waarbij de kip slechts op afstand is betrokken, terwijl het varken er letterlijk IN zit. De managers, de teamleiders en hun teamleden raken nu allemaal net zo betrokken als het varken. Er zijn geen ‘kippen’ meer, die op afstand hun 'ei' leggen!

Boektitel: The Lean Tech Manifesto
Ondertitel: Learn the secrets of tech leaders to grasp the full benefits of Agile at scale

Aanvullende informatie: McGraw Hill, ca. 230 pagina's, mei 2024.

Auteurs: Fabrice Bernhard en Benoît Charles-Lavauzelle. Zij zijn respectievelijk de CFO en CEO van Theodo. Dit bedrijf ontwikkelt klant specifieke software, en doet dat op Agile wijze. Dus stapsgewijs, met continue klantfeedback, en al lerende onderweg.

Pro’s en con’s:
++ Heldere beschrijving hoe je voor Agile software-ontwikkeling een team-of-teams organisatie kunt bouwen, gebaseerd op Lean beginselen. De belangrijkste toegepaste Lean-principes zijn visueel management, Jidoka, quality first, first-time-right, just-in-time, pull-production, respect for people, en continu verbeteren.

+ Goed geschreven, veel ideeën in beknopte vorm.

+ Gebaseerd op een echte business case: Agile opschalen bij softwarebedrijf Theodo

o Om het boek volledig te begrijpen, moet je op basisniveau bekend zijn met Lean, Agile én met softwareontwikkeling.

- De voorgestelde Lean synchronisatie van werkstappen met One Piece Flow en takt tijden is veel te zwart-wit voor een organisatie die klant-specifieke producten maakt. Gedetailleerde voorbeelden van het managen van softwareprojecten binnen Theodo ontbreken, die dit aspect hadden kunnen verhelderen.  

Bestellen:
Dit kan onder meer bij Amazon en Bol.com

> Alle boekbesprekingen

Laat waarde stromen
Het idee om Lean-principes te gebruiken om, via het netwerk van Scrum-teams, waarde naar de klanten te laten stromen, is logisch.

Ten eerste zijn de wortels van Scrum Lean: continu en al doende leren. Ten tweede is het voornaamste doel van Lean om productiestappen, met weinig tussenvoorraden daartussen, op elkaar af te stemmen. Lukt dat niet dan wordt dit zichtbaar gemaakt als een op te lossen ‘probleem’. Door dit continu te doen en dus steeds beter te worden, wordt de doorlooptijd sterk verkort. Als meerdere Scrum-teams samen een stukje waarde aan een klant leveren wil je dat ook, omdat het de feedback-cyclus versnelt.
Ten derde februikt Lean ook dezelfde aanpak als Agile om te verbeteren: hypothesevorming, testen en waar nodig aanpassen.

Tot nu toe enkel goed nieuws. Echter: Lean is oorspronkelijk ontwikkeld voor assemblagelijnen met vaste werkplekken, met standaardwerk op elke plek, en zelfs een gestandaardiseerde inhoud van het werk. Dit is NIET de situatie bij een bedrijf dat software op maat maakt. Dan heb je juist veel variatie in het type producten en de inhoud van het werk!

Software-ontwikkeling op de werkvloer van Theodo. Helaas worden in het boek geen projecten als voorbeeld behandeld, om de uitwerking van Lean daar de praktijk te zien.

QRM
Voor deze situatie met veel variatie bestaat er een aangepaste versie van Lean, genaamd Quick Response Manufacturing (QRM). Deze methode creëert flow in een netwerk van productieteams, met variabele routes daartussen.

Herinner je je de inflexibele ‘productietreinen’ in SAFe nog? QRM zou een ‘wagon’ (Scrum-team) pas aankoppelen zodra dat nodig is, en dan een ‘vrije wagon’ kiezen (een team met de capaciteit om het werk te doen)

QRM wordt door de auteurs van het boek echter niet genoemd. Wel passen ze een belangrijk aspect van die methode toe: vorming van multidisciplinaire teams, ook wel mini-ondernemingen genoemd.

Bij softwareontwikkeling zijn dit zogenaamde DevOpsBus-teams, teams die software ontwikkelen, onderhouden én die in contact staan ​​met de eindgebruikers.

One Piece Flow
Toen ik het boek begon te lezen, dacht ik dat de auteurs enkel de (vele!) bruikbare Lean-principes zouden gebruiken, die flow stimuleren in een netwerk van teams met variërende werkinhoud. Tot mijn verbazing pleiten ze echter ook voor One Piece Flow met takt-tijden, om werkstukken just-in-time als op een lopende band door de organisatie te laten stromen.

Zelfs in bedrijven met assemblagelijnen, zoals bijvoorbeeld in de auto-industrie, heb je altijd buffers nodig. Best-in-class Lean bedrijven onderscheiden zich, doordat ze per buffer precies weten waarom die (nog) nodig is.

Als dit al zo is bij productie in een keten met gestandaardiseerde stappen, hoeveel meer buffers heb je dan wel niet nodig in een Scrum-netwerk? Ik zie het gewoon niet voor me, One Piece Flow en takt-tijden in die situatie!

Als de softwareontwikkelaars van Theodo wél overweg kunnen met One Piece Flow, roept dit de vraag op: is hun werk zo eenvoudig? Naar mijn mening is het schrijven van softwarecode namelijk kenniswerk dat je niet als een robot kunt doen, waarbij je bijvoorbeeld één keer per dag op een vast tijdstip je werk aflevert. Soms doe ik zelf codeer-werk. Er zijn dan gevallen waarin ik pas een oplossing voor een bepaald probleem vindt, na een nachtje slapen.

One Piece Flow productie bij Scania. Een productieteam werkt aan een product (de vrachtwagen), en na een vaste (takt) tijd schuift die door naar het volgende productieteam. Bij assemblage werkt dit prima. Bij software-ontwikkeling lijkt dit onhaalbaar

Case
Toch is het creëren van zoveel mogelijk flow een universeel doel voor alle soorten organisaties.

Dus misschien is dát de boodschap van auteurs? Ik daag ze uit om een case toe te voegen over hoe een softwareproject in Theodo wordt afgehandeld. Op die manier kan het zwart-wit beeld van One Piece Flow gecorrigeerd worden. Of niet, maar dan zou ik zéér verrast zijn!

Het boek beschrijft het Lean Tech Manifesto op een heldere maar abstracte manier. Misschien wilden de auteurs niet al hun geheimen prijsgeven. Hun Manifesto zou immers gebruikt kunnen worden door concurrerende softwarebedrijven.

Deze kritiek kan de indruk geven dat ik het The Lean Tech Manifesto geen goed boek vind. Maar integendeel, ik vind het een prima stuk werk. Mits je het ziet als een verzameling principes die grote softwarebedrijven efficiënter en klantgerichter kunnen maken. Ik zie het niet als een recept of sjabloon. Kies dus de ideeën die het beste bij jouw organisatie passen, mix die met andere Agile organisatie-vormen die aansluiten, en creëer zo via trial-and-error jouw eigen ‘manier van werken’.

Mix
Het Lean Tech Manifesto zélf is namelijk ook zo’n mix: ​​van Lean-principes, van ingrediënten uit organisatorische* Agile-benaderingen, en van werkwijzen in succesvolle Agile-bedrijven zoals Amazon en Google.

Tot slot, om een ​​globaal idee te krijgen, laat ik enkele van de Lean-principes de revue passeren, waarop je een ​​Agile organisatie als een team-of-teams kunt bouwen. Een organisatie dus die voortdurend verbetert, leert over de wensen van haar klanten, en waarin iedereen de autonomie heeft om persoonlijk bij te dragen aan maximale klantwaarde!

Misschien is het beste principe om mee te beginnen het minimaliseren van de behoefte aan communicatie tussen de Scrum-teams. Zoals de auteurs zeggen: ‘elke communicatie die tussen de teams nodig is, is verspilling’.

Multidiscilplinaire teams
Hoe minder communicatie namelijk nodig is, hoe autonomer de teams blijven. Eén manier om dit te bereiken is de vorming van multidisciplinaire teams, zoals de mini-bedrijfjes in QRM, of teams vergelijkbaar met de eerder genoemde DevOpsBus-teams. Naarmate je meer expertise in je team hebt, heb je immers minder expertise van anderen nodig!

Multidisciplinaire Scrum-teams kunnen in een vaste samenstelling softwareprojecten voor vergelijkbare klanten of voor vergelijkbare doeleinden uitvoeren.

Daarnaast moet alle software zo modulair en herbruikbaar mogelijk zijn, vergelijkbaar met plug-and-play samenstelbare Lego-blokken. Dan kan een Scrum-team autonoom een ​​nieuw softwareblok ontwikkelen, dat onmiddellijk werkt wanneer het wordt aangesloten op een standaard application programming interface (API) van een ander, reeds bestaand blok.

Tech-enabled Network of Teams
Soms moeten er API’s van softwareblokken aangepast worden of moeten er nieuwe worden ontwikkeld. Scrum-teams worden op dat moment onvermijdelijk afhankelijk van elkaar, en moeten dan alsnog communiceren c.q. overleg voeren.

Als oplossing daarvoor komen de auteurs met de term Tech-enabled Network of Teams.

Met behulp van softwaretools zoals github kan zichtbaar worden gemaakt wie aan welke delen van de software werkt. In zekere zin is dit een digitale versie van visueel management in Lean: maak de werkstroom zichtbaar.

Standaardwerk, zoals best practices voor coderen, verhoogt de kwaliteit van de software en maakt die gemakkelijker leesbaar voor anderen. Dit kan gecombineerd worden met een digitale vorm van 5S om de software ‘schoon’ te houden: eliminatie van onnodige code.

Wij danken onze partners/adverteerders, door hen kunnen wij onafhankelijke artikelen maken!
Ontdek bijvoorbeeld hoe onderstaande partij Agile in de praktijk helpt brengen!

De AlignmentPuzzel

Door belabberde interne samenwerking verliezen bedrijven veel tijd, capaciteit en slagkracht. Daardoor verdampt er veel geld en vertrekken gemotiveerde medewerkers. Het kan anders! Het boek De AlignmentPuzzel beschrijft een nieuwe stijl van bedrijfsvoering op basis van drie uitgangspunten.
1. Het doel is de cashflow op lange termijn, niet korte-termijnwinst
2. Ontwerp een bedrijf vanuit het primaire proces, niet vanuit (afdelings)functies
3. Stuur op alignment, niet op afdelingsresultaten

Bestel het boek De AlignmentPuzzel via de link

> Naar website

> Toon andere adviseurs categorie Agile

Visueel management
Visueel management (VM) is verreweg de meest toegepaste Lean-tool in het boek, om het (digitale) werk op elkaar af te stemmen. VM wordt ook gebruikt om de voice of the (future) customers binnen het bedrijf te verspreiden, bijvoorbeeld via Obeya‘s (dit zijn overleg- en afstemmingsruimtes met korte- en langetermijndoelen op verbeterborden).

VM, in dit geval met behulp van Kanbans, wordt ook toegepast om onderhanden werk en prioriteiten zichtbaar te maken. Dit is extra belangrijk omdat je met software geen verspilling (voorraad) op de fabrieksvloer ziet.

De essentie van visueel management is mensen laten zien wat ze moeten doen, op een manier dat ze ook begrijpen waarom. Dit is wat The Lean Tech Manifesto doet. Dit in plaats van mensen simpelweg op te dragen wat ze moeten doen, wat geen interne motivatie opwekt.

Jidoka
Wanneer iemand een probleem tegenkomt, wordt dit via het Jidoka-principe gesignaleerd. Wanneer je weet of zelfs vermoedt dat er een (kwaliteits)probleem is: stop je daarbij de productie en vraag je om hulp.

Problemen die je zelf niet kunt oplossen, worden geëscaleerd naar een hoger teamniveau en indien nodig verder naar het (top)management, totdat het probleem is opgelost. Dit gebeurt op zodanige wijze dat de oorzaak wordt weggenomen, om te voorkomen dat hetzelfde (of een soortgelijk) probleem zich opnieuw voordoet.

Om het Jidoka-systeem te laten functioneren is een sociaal veilige omgeving essentieel. Met leiders die problemen zien als kansen om te verbeteren, en met leiders die competent, zorgzaam en ondersteunend zijn.

Sensei
De interessantste discussies op de Gemba beginnen volgens de auteurs met opmerkingen die op het eerste gezicht klein lijken. Om problemen steeds beter op te kunnen lossen, moeten mensen gecoacht worden. Hiertoe krijgen teamleiders de rol van een Lean sensei (leraar). Die stimuleert mensen om tot de kern van een probleem te komen. Dit door het stellen van Socratische vragen.

Dit sluit aan bij de Toyota Way, de organisatorische kant van Lean, ook wel respect for people genoemd. Respect betekent hier dat we de talenten van iedereen moeten gebruiken om te helpen verbeteren, en tegelijkertijd de probleemoplossende vaardigheden van iedereen moeten verbeteren. Het resultaat is een organisatie die continu leert.

Voor nog veel meer bruikbare Lean-principes kunt u The Lean Tech Manifesto zelf lezen. Een aanrader voor iedereen die in een tech(software)bedrijf werkt!