Flight Levels in Action van Klaus Leopold

De vierde presentatie van de eerste Agile100 nodigde uit om te vliegen. Klaus Leopold liet met „Flight Levels in Action" zien hoe je een organisatie op verschillende niveaus kunt verbeteren.

Het Flight Levels-model omvat drie niveaus, die zich op de volgende thema's richten:

• Flight Level 1: Operationeel niveau
• Flight Level 2: Coördinatie
• Flight Level 3: Strategisch portfoliomanagement

Klaus legt het uitgebreider uit op zijn slides, die je kunt vinden in de Mai Recap van de Agile100. Daarnaast laat de hieronder opgenomen presentatie mooi zien hoe de Flight Levels in Action werken.

Flight Levels in Action van Klaus Leopold

Meer over Klaus Leopold

Dr. Klaus Leopold is informaticus, Kanban-pionier en uitvinder van het Flight Levels Model. Hij beschikt over jarenlange ervaring als top-management consultant met ongeveer 1000 workshopdeelnemers per jaar. Hij adviseert bedrijven wereldwijd over hoe ze agile kunnen opereren op de markt. Klaus is auteur van de bestseller Rethinking Agile, Practical Kanban en co-auteur van het standaardwerk Kanban Change Leadership.
Hij is medeoprichter van de Flight Levels Academy en deelt zijn actuele inzichten en ervaringen in de wereld van Flight Levels en organisatieontwikkeling op zijn blog www.LEANability.com en zijn Twitter-account: https://twitter.com/klausleopold.

„Theorie zonder praktijk is nutteloos. Praktijk zonder theorie is duur."

Flight Levels in Action (Transcript) Wait, the user asked for Dutch translation. Let me redo this. Flight Levels in Action (Transcriptie)

Als je de video niet in z'n geheel wilt bekijken, hebben we hier een transcript van de volledige presentatie van Klaus Leopold voor je. Veel leesplezier!

Sohrab:

Welkom terug. Het is geweldig om Klaus Leopold vandaag bij ons te hebben. Klaus en ik hebben elkaar eigenlijk nog nooit persoonlijk ontmoet, maar we hebben een heleboel mensen die in zijn cursussen zaten en in mijn cursussen zaten. En in mijn cursussen hadden ze het altijd over Kanban-Klaus, en misschien hadden ze het in zijn cursussen over Scrum-Sohrab, ik weet het niet, misschien kan Klaus daar iets over zeggen. Maar ik ben heel, heel blij dat we Klaus bij ons hebben.

Hij is een van de auteurs die ik al een tijdje volg. Ik vond vooral zijn laatste boek "Rethinking Agile" erg goed, waarin hij over Flight Levels spreekt. Ik weet zeker dat hij daar vandaag het een en ander over zal bespreken. En als je geïnteresseerd bent om meer te weten te komen, ga dan na zijn presentatie – niet tijdens zijn presentatie – naar de stand van zijn bedrijf en wissel van gedachten met een paar van zijn collega's. Ik geloof dat Catherine en Cliff daar zullen zijn. Klaus, het podium is van jou.

Klaus:

Perfect. Cool. Hartelijk dank, Sohrab, voor deze vriendelijke introductie. Ja, nou, "Rethinking Agile", dat is de titel van mijn boek, en dat is ook de titel van mijn presentatie van vandaag. En ik denk dat de ondertitel zo'n beetje de boodschap is die ik heb proberen over te brengen: waarom agile teams niets te maken hebben met Business Agility. Waar gaat het dus om? Nou, ik wil graag een verhaal vertellen. Ik wil een verhaal vertellen over een organisatie. En die organisatie had een aantal problemen. Het belangrijkste probleem was dat ze hun time-to-market wilden verbeteren. Ze zeiden: "Oké, onze projecten duren veel te lang voordat ze af zijn. We moeten dus echt onze doorlooptijd tot aan de markt verkorten."

En, tja, dit soort wensen hoor ik vrij vaak: "We willen onze time-to-market verbeteren." Maar vanuit zakelijk perspectief zit er veel meer achter die verkorting van de time-to-market. In dit specifieke bedrijf ging het er vooral om proactief op de markt aanwezig te zijn. Ooit waren ze marktleider, maar nu proberen ze alleen nog maar de concurrentie bij te houden. Dat is geen fijn gevoel. En ze zeiden: "Oké, we willen weer proactief zijn, we willen kansen benutten." Ik bedoel, ze weten wat er gaande is op de markten. En ze zeiden: "Oké, het probleem is dat als we proberen een van onze projecten op te zetten, de kans al voorbij is." Dus, geen goede zaak.

En natuurlijk wilden ze voorbereid zijn op de discontinue verandering die op dit moment plaatsvindt, toch? We kennen allemaal die nieuwe businessmodellen die opduiken, we doen geen projecten meer, we doen producten, we doen geen producten meer, we doen oplossingen, we doen diensten, we doen ik-weet-niet-wat. Er is blockchain, kunstmatige intelligentie, enzovoort enzovoort. En ze zeiden: "Nou, de toekomst komt hoogstwaarschijnlijk. Maar als we doorgaan zoals vandaag, dan hoogstwaarschijnlijk zonder ons." En ze zeiden: "Oké, we moeten fundamenteel veranderen wat we hier doen." En tja, als je zoiets hoort, wat doe je dan? Het antwoord is simpel, toch? We worden agile, toch? Met agiliteit kunnen we al deze vraagstukken gemakkelijk aanpakken. Nou, en dat is wat ze in feite geprobeerd hebben te doen. Dus begonnen ze een agile transformatie.

Wat was onderdeel van de agile transformatie? Nou, zoals in elk Agile-handboek weten we dat we de functionele silo's moeten bestrijden. Silo's zijn slecht en kwaadaardig, dus moeten we cross-functionele teams vormen. Ze zeiden: "Reorganiseer cross-functionele teams." Wat nog meer? Ze gingen zelfs nog een stap verder en zeiden: "Oké, we moeten productteams hebben. We willen cross-functionele productteams hebben." Dat betekent dat een team altijd maar aan één product werkt. Een goed idee als je erover nadenkt. Wat we dus doen is dat we afhankelijkheden op de een of andere manier verminderen, zodat we rechtstreeks aan de markt kunnen leveren, en dat verkort natuurlijk onze time-to-market. Dus, persoonlijk vind ik dat eigenlijk wel goed.

Ze zeiden: "Laten we niet te dogmatisch zijn als het gaat om welke agile methode de teams gebruiken. Ze mogen hun eigen agile methode kiezen, de voorkeursmethode, er zijn alleen een paar vereisten waar ze op moeten letten. Zo moet elk team een visualisatie hebben, en wel op een bord. We willen zien wat er in de teams gebeurt." Het idee was dus: als ik kan zien wat alle teams doen, kan ik in principe gewoon naar een team toe lopen, een gesprek over hun werk beginnen en hun problemen bespreken. Elk team moet dus het bord hebben, we willen zien wat er in de teams gebeurt. Een andere vereiste waren standaard meetings. Elk team heeft een snel feedbackmiddel nodig waarmee ze kunnen inspelen op dingen die snel opduiken, dus stand-up meetings, elk team.

Elk team moet retrospectives houden, wat eigenlijk een verbetermachine is, en dat is best logisch, toch? We willen ons dus verbeteren. Agile worden is dus niet slechts één verbetering, we willen continu verbeteren. En als laatste punt, en dit vind ik ook wel goed, zeiden ze: "We willen een paar metingen zien." Weet je, het ene is of het goed voelt, het andere is wat het daadwerkelijke resultaat is van wat we hier doen. De doorlooptijd bij het team moet dus dalen, en de doorvoer moet stijgen, toch? Dat waren dus de twee metrics. En als je zoiets bekijkt, en je hebt net een Agile-handboek gelezen, dan denk je nu waarschijnlijk: "Geweldig. Ik bedoel, ze begrijpen echt wat er gedaan moet worden, toch? Ik bedoel, dit is wat je moet doen. Hier kan niets misgaan."

Nou, dat is wat ze geprobeerd hebben. En hoe hebben ze deze transformatie aangepakt? Nou, als allereerste hebben ze een anderhalf jaar durend transformatieproject opgezet. Voel je iets? Dit is een beetje mijn soort humor, toch? We willen agile worden, en het allereerste wat in ons opkomt is het definiëren van een watervalaanpak voor hoe we agile worden. Ik weet niet zeker of dat de beste manier is om dat te doen. Maar, ach ja, oké, zo hebben ze het gedaan. Dus anderhalf jaar projectplanning voor hoe je agile wordt. En een van de allereerste dingen in dat projectplan was, we hebben het hier over 600 mensen, dus niet super groot, maar toch 600 mensen, behoorlijk veel mensen. Ze zeiden: "Al deze mensen, nou, die moeten een soort basistraining in agile krijgen."

Ik denk dat iedereen hier het wel gehoord heeft: agiliteit gaat niet zozeer over de praktijken. Agiliteit gaat veel meer over de mindset. Denk je daar weleens over na? Het gaat om de mindset. Als mensen maar de juiste mindset hebben, dan is alles geweldig. Het gaat dus niet om de praktijken. Het gaat om de mindset. En dat is wat ze gedaan hebben. Ze hebben dus dit eendaagse agile mindset-programma gestart, waar in principe alle 600 mensen doorheen gingen, en daarna konden ze in feite het vakje aanvinken in het projectplan: agile mindset gevestigd. Tja, we kunnen erover nadenken of dat zo werkt, maar misschien heb je een tweedaagse training nodig, toch? Oké, dat is de mindset, één ding. Wat nog meer? De reorganisatie werd doorgevoerd. En wat betekent dat? De mensen werden in feite de lucht in gegooid, ze landden ergens anders in de organisatie in deze cross-functionele productteams, en vervolgens begon men in principe agile teams per team te implementeren.

Dus de Scrum-teams kregen hun Scrum-training, hun Product Owner Training, en de Kanban-teams, die bouwden allerlei systemen op enzovoort. En goed, in het begin werd dit hele proces ondersteund door 16 externe coaches, wat cool is als je een adviesbureau runt. Ik bedoel, dan kun je behoorlijk wat dagen verkopen. Maar als je kijkt naar wat hier aan de hand is – ik bedoel, we hebben het hier over 600 mensen. Dus dat is echt... als je bedenkt hoeveel training en alles hier nodig is, dan heb je waarschijnlijk echt die 16 externe trainers nodig.

Wat nog meer? Op de een of andere manier vind ik dit wel leuk. Ze zeiden: "We moeten interne capaciteit opbouwen." Dus leidden ze 11 interne coaches op, en het idee was: "Oké, we moeten de kennis in onze organisatie houden", want – ik bedoel, ik heb het zo vaak gezien – zolang de externe adviseurs er zijn, is alles min of meer oké. En als de externe coaches en adviseurs vertrekken, dan denken veel mensen: "Eindelijk kunnen we weer terug naar normaal." Tja, je wilt waarschijnlijk niet terug naar de normale situatie als je zoveel geld investeert als zij hier doen. Dat was dus min of meer het plan. Wat was het statusrapport? Het statusrapport na ongeveer een jaar vermeldde dat 80% van de teams volledig getransformeerd was. Ik hou van die formulering, hè? Ze waren volledig getransformeerd. Wat betekent het dus dat 80% van de teams volledig getransformeerd was?

Nou, je zou een heleboel van die checks in je projectplan-retrospective kunnen afvinken. We hebben ze gezien, hun ondersteuning, natuurlijk, standaard meetings, check, check, check. Er was een selectievakje genaamd metrics. En ze zeiden: "Ja, de teams doen aan metrics, maar... oké, we vinken het vakje aan, maar laten we eens naar de metrics kijken. Ik bedoel, dat is de reden waarom we ze hebben." Zo, nu wordt het een beetje interessant. Dit is een zogenaamd Scrum Sprint Velocity Chart. Ik laat je straks deze Velocity Charts en Lead Time Charts zien, en wat je hier ziet zijn teamtrends. Dit is dus een trenddiagram, niet van één team, maar van meerdere teams. En het idee is dat we over het algemeen willen zien of we verbeteren of niet. Het is een maat voor de doorvoer van de filosofie. In feite betekent het hoeveel een team oplevert.

We zien dus de tijdas op de X-as, en op de Y-as zien we de fantasie-story-points, ik geloof dat ze zo heten, van Scrum. Dat is de velocity. En de trend, dat is wat ze verwachtten te zien. Ze wilden zien dat de velocity natuurlijk stijgt. In het begin is er misschien niet zoveel velocity, omdat alles nieuw is, weet je, de teams, ze moeten eerst leren hoe alles werkt, maar daarna moet het zeker omhooggaan. Mooi. Dat is het verwachte resultaat. Het werkelijke resultaat zag er zo uit. Dus, ja, het verbeterde een beetje, maar daarna ging het weer omlaag. Ze vroegen zich af: "Wat is hier aan de hand? Ik weet het niet zeker. Ik bedoel, dit is niet wat we verwacht hadden." En toen, de eerste stemmen, je kon de eerste stemmen in deze organisatie horen, en ze zeiden: "Tja, weet je, we hebben jullie altijd al gezegd dat Scrum niet werkt. Dit is het bewijs, toch? Kanban is veel beter dan Scrum, toch?"

Oké, goed, als Kanban beter is dan Scrum, laten we dan eens naar de Kanban-diagrammen kijken. Dit is het Kanban-doorlooptijd-diagram. Doorlooptijd is in feite snelheid, hoe snel leveren we? Het is weer een trenddiagram van meerdere teams. We zien de trend op de X-as, en op de Y-as de snelheid, hoe snel ze zijn. En natuurlijk wilden ze zien dat de doorlooptijd daalt, toch? En, tja, het verwachte resultaat, het werkelijke resultaat zag er zo uit. Ze zeiden: "Nou, dat is een beetje fantasie. We kunnen zeggen dat het niet slechter wordt. Maar, tja, het is best moeilijk om te zeggen dat dit veel beter is." Dus ze waren een beetje onrustig. Ze zeiden tegen zichzelf: "Oké, we weten niet wat hier aan de hand is." Dat is het probleem met deze diagrammen.

Het probleem is dat het behoorlijk moeilijk is om een diagram te maken, wanneer er geen verbetering te zien is, omdat we het over teamdiagrammen hebben en we het hebben over diagrammen na een reorganisatie. Dat betekent dat deze teams er daarvoor niet waren. Dus, goed, er was die reorganisatie, nu is alles anders, in feite. En ik kan niet vergelijken, omdat de teams er daarvoor niet waren. Maar er was één diagram dat in feite bestond van vóórdat ze agile werden én nadat ze agile werden. En dat is de time-to-market van hun initiatieven. Weet je nog, dat is de reden waarom ze dit allemaal gedaan hebben, omdat de tijd tot marktintroductie was gestegen. En ze voerden initiatieven uit voordat ze agile werden. En ze voerden of voeren nog steeds initiatieven uit nadat ze agile zijn geworden.

Afhankelijkheden en agile interacties

De time-to-market werd dus steeds langer, en ze zeiden: "Oké, we moeten dit veranderen. We moeten die lijn omlaag krijgen." Dat was het verwachte resultaat. Maar het werkelijke resultaat zag er zo uit. En dat doet echt pijn, want wat we hier zien is niet dat er geen verbetering is. Het wordt juist erger. Ze werden dus niet agile, en het duurde langer voordat ze op de markt waren. En toen vroegen ze zich af: "Wat voor fenomeen is hier aan de hand?" Ik bedoel, dat slaat voor hen nergens op, toch? En ja, ze hoorden mij spreken op de conferentie, toen ik het had over lokale optimalisatie versus globale optimalisatie en dat soort dingen. En ze zeiden: "Misschien heeft het iets te maken met waar hij het over heeft."

Dus in feite belden ze mij op en zeiden: "Oké, kun je alsjeblieft komen kijken? We zien hier geen verbeteringen. Misschien heeft het iets te maken met waar je het over had in je conferentiepresentatie." Ik zei: "Natuurlijk. Ik kan ernaar kijken." Wat ik dus in feite deed, was naar hen toegaan en ik bracht, ik denk, anderhalve dag, bijna twee dagen met hen door. En ja, ik was op zoek naar de oorzaken. En het was best cool, want weet je, alle teams waren agile. En dat betekent... of ze gebruikten een van die aanvullende methoden. En dat betekent dat er veel zichtbaarheid was. Ik ging dus in principe naar de teams toe, want daar vond agiliteit plaats in deze organisatie. Ik ging naar de teams en begon gewoon het gesprek met hen.

En in het begin had ik het over de afhankelijkheden en de agile interacties. Toen ik met de teams sprak, is dit de vereenvoudigde visualisatie die ik hier steeds zag, zoiets als dingen die we moeten doen, zoals het backlog. Volgende kolom, de dingen die we al gecommit hebben. Ontwikkelen is, we werken er momenteel aan. En dan is er nog de done-kolom, een vereenvoudigde weergave van een van de teamboards. Er was maar één ding, elk afzonderlijk team had zoiets op hun board: extern wachten. Dat wil zeggen, dit team kan niet meer aan dit werkitem werken, omdat een ander team in deze organisatie eraan moet werken. Het is dus vanuit dit perspectief geblokkeerd, en een ander team moet het vrijgeven. Dus, een afhankelijkheid, toch? Het interessante hieraan is dat elk afzonderlijk team in deze organisatie, en echt 100%, elk afzonderlijk team dit externe wachtprobleem had. En ik dacht: "Oké, wat betekent dat?"

Laten we echt aannemen dat elk afzonderlijk team in deze organisatie zo'n visualisatie heeft, dat zou betekenen dat er ergens een tweede board in deze organisatie is. En als team nummer één deze afhankelijkheid tegenkomt, zoals extern wachten, betekent dat dat het op de een of andere manier een vraag triggert bij team nummer twee. Ze doen een soort van, ik weet niet, magische planning, wat dan ook, en komen tot de conclusie: "Oké, laten we aan dit item beginnen te werken, en als ze daarmee klaar zijn, betekent dat dat wij klaar zijn en het team daarboven dit item kan vrijgeven." Dat is dus in feite wat er gebeurt als we dit externe wachtprobleem zien. Ik vroeg de teams dus hoe vaak dit voorkomt. En op wie wachten jullie? Dus niet slechts één keer in je leven, maar eerder op regelmatige basis.

En wat ik heb gedaan, is dat ik zoiets als een afhankelijkheidsdiagram heb getekend, en dat zag er zo uit. Er zijn dus echt heel veel afhankelijkheden. En ik dacht: "Dat is interessant." En je ziet dat het hier maar acht teams zijn. Dus in het echte leven, 600 mensen, kun je je voorstellen dat het enorm is als je naar dit afhankelijkheidsdiagram kijkt. De vraag is: waarom zijn er zoveel afhankelijkheden? Ik bedoel, ze hebben ontzettend veel gedaan om deze afhankelijkheden te verminderen. Bedenk dat ze cross-functionele teams vormen. Ze bouwen cross-functionele teams op omdat we afhankelijkheden willen elimineren. Het andere punt is zelfs productteams creëren. Dat betekent dat één team alleen aan één product werkt. Ze hebben dus heel veel gedaan om de afhankelijkheden weg te nemen, maar toch komen ze in een situatie als deze terecht. De vraag is: waarom?

Nou, er zijn meerdere redenen, drie redenen. Ik denk dat dit de drie belangrijkste redenen zijn die ik heb ontdekt. Reden nummer één is: ja, dat klopt. Een team werkt alleen aan één product. Dat is prima. Maar meerdere teams werken aan hetzelfde product. Dat betekent bijvoorbeeld dat dit team hierboven alleen aan product A werkt, maar het andere team en het andere team werken ook aan product A. En, wat een verrassing, er zijn afhankelijkheden, toch? Wat nog meer? Een ander probleem is dat de producten niet volledig onafhankelijk van elkaar zijn. Dat betekent dat als je iets in product A wijzigt, je ook iets in product B en in product C moet wijzigen. We hebben dus heel veel afhankelijkheden binnen de producten of tussen de producten.

En goed, uiteindelijk hebben we het over 600 mensen. Persoonlijk heb ik nog nooit een organisatie met meer dan 30 mensen zonder afhankelijkheden in kenniswerk gezien, toch? Het is dus volkomen logisch dat we hier afhankelijkheden zien. En, tja, telkens als ik aan afhankelijkheden denk, verschijnt er een beeld in mijn hoofd, een beeld van een toetsenbord. Laten we zeggen dat onze organisatie een toetsenbord is, en we zijn goed in de schrijfbusiness. Wat we dus doen, is brieven schrijven voor onze klanten. Laten we onze organisatie organiseren: team één, twee, drie, vier, toch? Team één drukt alleen op de cijfertoetsen, team twee Q, W, E, R, team drie A, S, D, F enzovoort, enzovoort. En laten we nu aannemen dat de klant wil dat we een liefdesbrief schrijven. Nou, we moeten bedenken hoe we deze liefdesbrief kunnen afleveren. Maar als je een organisatie bent met 600 mensen, heb je niet slechts vier teams. Je organisatie ziet er waarschijnlijk zo uit.

Voor elke verdomde toets op je toetsenbord is er ergens een team dat op die toets drukt. We hebben een R-team, we hebben een T-team, we hebben een G-team, we hebben een A-team, elke organisatie heeft een A-team nodig, natuurlijk. Anders ben je eigenlijk de klos. En laten we nu aannemen dat we al deze teams optimaliseren. En laten we aannemen dat het lukt. We hebben het beste R-team op deze planeet. We hebben het beste V-team en het beste S-team. En als het D-team begint op de D-toets te drukken, komt er rook uit het toetsenbord. Ze zijn gewoon fantastisch. We zijn de internationale benchmark als het gaat om het bewerken van het toetsenbord, het indrukken van toetsen op het toetsenbord. De vraag is: hoeveel sneller kunnen we onze liefdesbrief afleveren? Nou, misschien niet zo veel sneller, toch?

Het juiste team moet op het juiste moment aan de juiste dingen werken

Het punt is dus dat als het gaat om het bedienen van het toetsenbord, het niet zo belangrijk is dat je elke afzonderlijke toets supernel raakt. Het is veel belangrijker dat ik ervoor zorg dat je de juiste toets op het juiste moment indrukt. Als ik de juiste toets op het juiste moment indruk, kan ik mijn brief veel, veel sneller afmaken. En hetzelfde geldt voor organisaties. Hetzelfde geldt voor organisaties. Het is dus niet zo belangrijk dat elk afzonderlijk team heel, heel snel werkt. Het is veel belangrijker dat we ervoor zorgen dat het juiste team op het juiste moment aan de juiste dingen werkt. Het juiste team moet op het juiste moment aan de juiste dingen werken. Dat is waar het om gaat bij organisatorische prestaties.

En nu, er is een man genaamd Russell Ackoff. Russell Ackoff zei al dat de prestatie van een systeem niet de som van zijn delen is. Het is het product van zijn interacties, het product van zijn wisselwerkingen. Wat betekent dat? Nou, als we dat op de een of andere manier vertalen naar onze huidige wereld, zouden we kunnen zeggen dat de agiliteit van een organisatie er niet om draait dat ze, ik weet niet, veel agile teams heeft. Bij een agile organisatie gaat het er meer om dat er daadwerkelijke interacties tussen de teams bestaan. We moeten dus de interacties agile maken en niet zozeer de teams – dat is waar de organisatorische agiliteit zit. We moeten ervoor zorgen dat het juiste team op het juiste moment aan de juiste dingen werkt. En dat is iets wat in deze organisatie totaal niet op de radar stond. Ze zeiden: "De heilige graal is cross-functionaliteit. We moeten die functionele silo's afbreken, en alles wordt fantastisch."

Begrijp me niet verkeerd. Ik ben een grote fan van cross-functionele teams. Maar het probleem is dat het niet genoeg is om de silo's af te breken, de functionele silo's. Dus wat deze organisatie eigenlijk deed – ja, ze hebben de functionele silo's afgebroken, maar ze hebben cross-functionele silo's opgebouwd. Het punt is dus: het is niet zo belangrijk welke persoon in welk team zit. Het is veel belangrijker dat we op de een of andere manier interactiegaten door de muren van de teams boren. We moeten het dus mogelijk maken dat deze teams op een agile manier met elkaar interacteren. En dat werd in deze organisatie helemaal niet gedaan. Dat was dus bevinding nummer één: er waren helemaal geen daadwerkelijke interacties. Ik heb nog twee problemen voor je. En na de problemen gaan we over naar de oplossingen. Probleem nummer één: geen agile interacties. Laten we naar het, zeg maar, tweede probleem gaan, de tweede bevinding.

Zoals ik al zei, heb ik met de teams gesproken, en ik heb ook met de teams over de flow gesproken. Wat betekent dat? Nou, laten we nog eens naar het toetsenbord kijken. Zo zagen die borden er dus uit. En ik dacht: "Oké, dat is interessant. Jullie ontwikkelen dus, en na de ontwikkeling zijn jullie klaar. Dat betekent dat de klant helemaal tevreden is, alles is super." Ze zeiden: "Nou ja, zo simpel is het niet. Na de ontwikkeling moeten we natuurlijk integreren wat we gemaakt hebben." En ik zei: "Oké, cool. Waarom niet?" Dus bouwen we een extra kolom. Ik bedoel, we willen het toch zichtbaar maken. Dat is toch het hele doel van een visualisatie, toch? Dus bedachten we een kolom voor het wachten op integratie. Prima. Maar toen dacht ik: "Oké, en als de integratie klaar is, dan ben je klaar. Dat betekent dat de klant helemaal tevreden is."

Ze zeiden: "Nee, niet helemaal. We moeten natuurlijk nog een paar acceptatietests doen." Ik zei: "Oké, interessant. Laten we dus een andere kolom toevoegen. Dus we wachten op de acceptatietests. Maar nu heeft de klant het geaccepteerd. Dus de klant is nu helemaal tevreden, toch?" Ze zeiden: "Nee, er zijn, weet je, die releasevensters, en het moet in een releasevenster passen, enzovoort enzovoort. Maar dan zijn we min of meer klaar." Ik zei: "Oké, dat is waardevolle informatie, toch? We hebben nu een bord met een paar extra kolommen." Het gaat dus niet zozeer om de visualisatie. Het gaat meer om wat we van deze visualisatie kunnen leren. En als ik een visualisatie als deze zie, begin ik vragen te stellen zoals: "Oké, wachten we op de integratie? Hoe lang duurt dat? Hoe lang duurt dat? Hoe lang duurt dat?"

En, nou, in dit specifieke geval was het antwoord dat de integratie maandelijks werd gedaan en vier keer per jaar acceptatietests die het releaseproces doorliepen. We willen de time-to-market van onze projecten verbeteren. Ik denk dat ik een paar ideeën heb, toch? Maar ik was hier natuurlijk niet helemaal blij mee, vooral in de softwareontwikkeling weten we vrij precies wat we hier moeten doen. Dus, er is Continuous Integration, Continuous Delivery, Continuous Deployment, Continuous Everything. Ik heb ook naar de voorkant van het bord gekeken. Ik dacht: "Oké, hier is de backlog. Dat betekent dus dat je hier je visie hebt, je productidee, je geweldige feature-idee, en je begint met ontwikkelen."

En ze zeiden: "Nee, nee, nee, zo simpel is het niet. Weet je, als we hier over de backlog praten, hebben we het over de ontwikkel-backlog. Voordat we met de ontwikkeling beginnen, moeten we natuurlijk eerst wat analyses doen." Ik dacht: "Oké, waarom niet? Ik bedoel, dat is toch de reden waarom we dit bord gebouwd hebben, toch? Dus laten we een extra kolom inrichten, zoiets als productpakketten hierboven, analyse, en dan zitten we in de ontwikkel-backlog, en dan kunnen we beginnen. Dat betekent dus dat we hier in de Product Backlog echt onze geweldige ideeën hebben." En ze zeiden: "Nee, eigenlijk ziet ons proces er ongeveer zo uit. We hebben zoiets als een pool van nieuwe ideeën, en we doen een soort triage met die ideeën, dan schrijven we een globaal concept. Dit globale concept wacht op de stuurgroep, dan schrijven we een gedetailleerde business case, die weer wacht op goedkeuring. En nu zitten we eindelijk in de Product Backlog. En we kunnen beginnen met analyseren."

Ik dacht: "Oké, interessant, natuurlijk. En het mooie is, als we een beetje uitzoomen, ziet het proces er zo uit." En ik dacht: "Oké, mooi." En weer, net als eerder, als ik zoiets zie, is het punt dat we weer vragen kunnen gaan stellen. En de vraag was dezelfde als eerder: hoe vaak vindt het plaats? En hoe lang moeten we wachten? En het antwoord was: de triage werd maandelijks gedaan, wat best snel is. Vier keer per jaar was er de stuurgroep, die de globale business cases goedkeurde. En één keer per jaar werden de gedetailleerde business cases goedgekeurd, één keer per jaar. We willen de time-to-market van onze projecten verbeteren. Ik denk dat ik een paar hefbomen heb geïdentificeerd die we kunnen gebruiken. Nou, zij kwamen ook op een idee. Ze zeiden: "Ontwikkeling, probleem ontdekt. We hebben hier wat agile toverpoeder ingestrooid en we zijn zo ongelofelijk agile, het is gewoon fantastisch."

Nou, nee, sorry dat ik het moet zeggen. Dat geloof ik niet. Ik bedoel, natuurlijk kunnen we dat op de een of andere manier sneller maken, maar uiteindelijk bereiken we niet veel als het gaat om sneller naar de markt leveren. Ik bedoel, dat is misschien agile softwareontwikkeling. Prima. Daar heb ik geen probleem mee. Maar Business Agility – dat heeft niets met Business Agility te maken. Dit bedrijf X ligt op de markt als voorheen, er is helemaal geen verandering. En dat was precies het tweede probleem dat ik ontdekte. Er was geen inzicht in en geen management van de waardestroom.

Laten we naar het derde probleem gaan, voordat we ons op de oplossingen richten!

Oké, het probleem, en ik heb nog een probleem voordat we overgaan naar de oplossingen: we kunnen het even hebben over het agile strategisch portfolio. Maar voordat we dat doen, laten we teruggaan naar de teams, oké? Dit was dus een van die teamborden. En wat ik op die borden kon zien, dat waren zoiets als cijfers erop, cijfers als WIP-limieten, denk ik. Jullie hebben allemaal wel eens gehoord van WIP-limieten, zoals Work-in-Process-limieten. Dat betekent dat ze hier slechts twee items mogen starten en een van die items moeten afronden voordat ze een nieuw item beginnen. Dat geldt dus voor de Kanban-teams, maar er waren ook Scrum-teams, en die hadden misschien niet zo'n expliciete beperking. Maar Scrum-teams beperkten hun werk doordat ze met Sprints werken, of ze doen Sprints. Sprint is eigenlijk vergelijkbaar met het beperken van werk in het proces, want wat je doet is simpelweg zeggen: "Oké, ik commit me om deze items binnen de komende twee weken op te leveren. Ik begin niet aan meer items totdat ik deze items heb opgeleverd, en dan kunnen we meer items oppakken." Het is dus ook "stop starting, start finishing".

Ik heb het dus over het creëren van focus, want het creëren van focus is gewoon geweldig. Er zit zoveel theorie achter. En er is zelfs een wiskundig bewijs, zoals Little's Law, dat min of meer alles wat je hier kunt lezen waar is. Dus de switching-overhead daalt, de doorlooptijd daalt, de kosten van vertraging dalen, je systeem is stabiel, wat betekent dat je voorspelbaar bent. Er zijn dus zoveel geweldige dingen als je focus creëert in je organisatie. En ja, er is zelfs één ding: de doorlooptijd gaat omlaag en de time-to-market gaat omlaag. Het punt is dus: als je focus creëert, word je sneller, de time-to-market wordt korter. Maar wat we nu in deze organisatie zagen, was dat de time-to-market juist was gestegen. Hoe is dat mogelijk? Ik bedoel, er zijn wiskundige bewijzen dat dit klopt.

Hebben ze Little's Law dan gewoon vervalst? Nou, nee. Laat me het zo zeggen. Als het gaat om het creëren van focus, is er, laten we zeggen, kleine lettertjes. En ik denk dat 99% van de organisaties die kleine lettertjes nooit heeft gelezen. Hier zijn dus de kleine lettertjes, een beetje groter weergegeven. Het punt is: het gaat er niet om je te focussen op een willekeurig item of een willekeurige eenheid in je organisatie. Wat je moet doen is focussen, je moet focus creëren, je moet die werkitems beperken daar waar je het voordeel wilt zien. Je moet die werkitems beperken daar waar je het voordeel wilt zien. Wat betekent dat? Nou, deze organisatie werkte aan initiatieven, toch? Wat ze deden was de initiatieven opsplitsen in epics. Vervolgens splitsten ze de epics op in stories en de stories in taken. Zo deden ze het. Nou, we moeten verbeteren.

Wat we dus willen zien, is dat we de time-to-market van onze initiatieven willen verbeteren. Wat moeten we beperken? Waarop moeten we ons focussen in onze organisatie? Nou, zoals ik al zei, initiatieven natuurlijk, dus we moeten ervoor zorgen dat de hoeveelheid, het aantal initiatieven in onze organisatie op de een of andere manier beperkt is. Dat is wat we moeten doen. Wat hebben zij gedaan? Nou, agiliteit was een team-aangelegenheid. Agiliteit was dus alleen iets van het team en verder niets. Ik als team, in deze keten, wat kan ik beïnvloeden? Wat kan ik daadwerkelijk beperken? Hoogstwaarschijnlijk niet de initiatieven. Hoogstwaarschijnlijk niet de epics. Dus mijn invloedssfeer zit ergens hier, ik kan waarschijnlijk de stories beperken, ik kan de taken beperken. En ik denk dat dat precies het probleem is. En dat is precies het probleem dat we in deze organisatie zagen.

Wijs niet de dingen die je doet toe aan de strategie, maar doe alleen wat de strategie je zegt!

Het punt is dus: wees niet verrast als je niet de verbetering ziet die je wilt zien. Je moet je dus richten op die werkelementen waarbij je de verbetering wilt zien. En dat zijn duidelijk geen stories. Dat zijn initiatieven. En in deze organisatie repliceerden ze de teams, ze hadden hun Sprint-doelen en alles verdedigd, maar ze werkten nog steeds aan 1000 initiatieven tegelijk. Dus, verrassing, verrassing, geen van de initiatieven werd sneller afgerond. Dat is niet best. Waar kunnen we deze initiatieven begrenzen? Waar kunnen we focus aanbrengen op deze initiatieven? Ik zou zeggen, ergens in een strategisch portfolio, ergens daarboven, wat daarboven ook mag betekenen, maar het is voorbij het teamniveau, toch? Toen we het over de strategie en het strategisch portfolio hadden, was er nog iets anders dat in deze organisatie best interessant was, namelijk het proces van strategieontwikkeling.

In deze organisatie werd de strategie dus op een nogal interessante manier aangepakt. Laat ik het zo zeggen. Laten we een tijdlijn erbij pakken, oké? In deze organisatie werkten mensen ergens aan. Dat is prima. Ik bedoel, daar worden ze voor betaald. En toen was er die strategieaankondiging. De strategie werd dus ergens verkondigd op een... ik weet niet, townhall, lekker eten, drankjes, alles erop en eraan. En ja, dat is allemaal strategie. En het gevolg van de strategieaankondiging was dat mensen aan dezelfde dingen bleven werken. Dus geen groot verschil, toch? En toen, later in het jaar, zagen ze langzaam het einde van het jaar naderen. En toen dachten ze: "Oké, er was iets met strategie, ergens aan het begin van het jaar." En wat je in deze organisatie kon zien, was dat steeds meer mensen nieuwe PowerPoint-documenten begonnen te maken zoals strategievervulling.pptx.

En wat ze in feite deden, was dat ze achteraf probeerden om alles waar ze aan hadden gewerkt toe te wijzen aan de strategie. Ze zeiden dus: "Oké, ik heb aan dit project gewerkt. Dat past in deze strategische emmer. Ik heb hieraan gewerkt, dat past in dit strategiegebied." Ze probeerden dus eigenlijk achteruit te plannen en het te rechtvaardigen op basis van het strategiewerk dat ze hadden gedaan. Maar dat is niet het doel van strategie. Het idee van strategie is dat de strategie bepaalt waaraan we werken. Het is geen rechtvaardigingsmethode, toch? Dat was dus nog iets dat in deze organisatie echt opviel. En ik zal straks bij de oplossing vertellen wat we hieraan hebben gedaan. Oké, dat was dus probleem nummer drie: geen echt strategisch portfoliomanagement in deze organisatie.

We hadden het dus eigenlijk over deze drie problemen: geen daadwerkelijke interacties, de strategie was goed maar het strategiemanagement ontbrak, en geen end-to-end management van de waardestroom. Dat waren dus de drie problemen die ik had ontdekt. Laten we het over oplossingen hebben. Uiteindelijk waren de oplossingen geen raketwetenschap. Dat is het goede nieuws. Toch duurde het even voordat we op het punt waren dat we aan oplossingen konden gaan werken. Maar wat waren de oplossingen? Ten eerste de daadwerkelijke interacties tussen de teams. Weet je nog, er was dat diagram met al die afhankelijkheden. En ja, wat hebben we gedaan? Nou, weet je nog, de afhankelijkheden waren er omdat de teams aan een product werkten, maar meerdere teams werkten aan hetzelfde product.

We hadden dus nog steeds een heleboel afhankelijkheden. Wat we dus eigenlijk hebben gedaan, is dat we vanuit het teamniveau zijn vertrokken en productboards hebben gemaakt. Wat betekent dat? We hebben in feite geïdentificeerd welk team aan welk product werkt. Stel dat deze drie teams aan één product werken. Wat we dan eigenlijk hebben gedaan, is dat we die drie teams samen in een ruimte hebben gezet, en we wilden een visualisatie maken van hoe ze gezamenlijk hun werkstroom beheren. En dat hebben we uiteindelijk voor alle producten gedaan. We hebben dus productboards gebouwd. Het punt is: we zijn gestopt met het optimaliseren van organisatiestructuren. Een team is een organisatiestructuur – ik als klant, het maakt me niet uit of jullie teambezettingen hebben of wat dan ook, het interesseert me niet, toch? Dus zijn we daarmee gestopt en hebben we ons niet meer gericht op het optimaliseren van de organisatiestructuren. Wat we wél deden, was het optimaliseren van de waardelevering.

De klantwaarde ontstaat bij het product

Het product is iets waar de klant een bepaald voordeel van heeft als het klaar is. En dat is wat we gedaan hebben. We hebben dus productboards gebouwd. En vóór de productborden, en dat is het belangrijkste, coördineerden de teams zich. We hadden dus stand-up-meetings en retrospectives tussen de teams vóór dit board. En ik denk dat dit ook iets heel belangrijks is. Het punt is, het gaat niet zozeer om het board. Het gaat veel meer erom dat de mensen, de juiste mensen het juiste gesprek vóór het board voeren. De daadwerkelijke interactie is dus het belangrijkste. En ja, wat we gedaan hebben, zijn product-stand-up-meetings en product-retrospectives. Dat betekent dat de teams vertegenwoordigers stuurden naar de stand-up-meeting, naar de retrospective, ze hadden een stand-up-meeting voor alle teams, daarna gingen ze terug naar hun team en hadden een stand-up-meeting in het team. Ja, dat is één ding.

Als je zoiets doet, daalt het aantal afhankelijkheden, toch? Maar er bleven nog steeds een paar afhankelijkheden over. Deze afhankelijkheden worden nu dus binnen het product beheerd. Maar onthoud, er was nog steeds het probleem dat als je iets in product twee wijzigt, je ook iets in product één moet wijzigen. We hebben dus afhankelijkheden tussen de producten. Wat hebben we dus gedaan om dat te overwinnen? Nou, we hebben iets opgebouwd wat ik tegenwoordig een operationeel portfolio zou noemen. Operationeel portfolio betekent in feite dat we op een of andere manier de producten en diensten identificeren waar veel afhankelijkheden zijn. En we hebben deze boards samengenomen en een extra board gemaakt waarin we deze afhankelijkheden over de producten heen kunnen beheren.

Dit is bijvoorbeeld slechts een illustratie. Dat is product één, product twee, product drie, al deze producten staan op hetzelfde board, en nu nemen vertegenwoordigers van de verschillende producten deel aan onze stand-up-meeting, nemen deel aan onze retrospective, en we kunnen het werk over de producten heen coördineren. Dus nogmaals, het gaat niet zozeer om het board. Het gaat meer om de interactie die vóór het board plaatsvindt. Ja, en dat is in feite wat we gedaan hebben om het probleem van deze afhankelijkheden te overwinnen. We hebben ons dus losgemaakt van de organisatiestructuur en ons gericht op wat voor de klant interessant is, namelijk de waardecreatie. In dit geval waren dat producten en boards waarmee we de afhankelijkheden en alles over de producten, over de teams heen konden beheren, punt nummer één.

Wat hebben we gedaan? Wat was de oplossing voor punt nummer twee? Weet je nog, dat was dat enorme bord, dat enorme proces dat steeds groter en groter en groter werd. Nou, de oplossing is simpel. Als ik hem gewoon aan je presenteer. Maar uiteindelijk hadden we het over anderhalf, bijna twee jaar veranderingsproces om op dit punt te komen. De oplossing ziet er uiteindelijk zo uit. We hebben de upstream op de een of andere manier vereenvoudigd. Bedenk dat we hier niet zoveel stappen hebben voordat mensen daadwerkelijk met het echte werk beginnen. We draaien dus alleen nog een ruw concept dat wacht op goedkeuring. En ja, dan kunnen we al beginnen met werken. En we hebben de business erbij betrokken. Wat betekent het als ik zeg dat we de business erbij hebben betrokken? Nou, dit was een vrij traditionele organisatie, en ze werkten echt als een silo, zoals, er is de business en er is de IT. En vanuit het perspectief van de business is IT alleen maar kosten.

Het is dus beter om niet met die mensen te praten. De echte uitdaging was dus om ze op de een of andere manier samen te brengen, zodat we de hele waardestroom konden managen. En wat we ook deden, weet je nog, dat goedkeuringsproces werd maar één keer per jaar gestart, we hebben dit teruggebracht naar tweewekelijks, elke twee weken konden we nieuw werk starten. Normaal gesproken is nieuw werk starten geen groot probleem in organisaties. Maar het punt is dat we het werkproces hier hebben beperkt. We konden dus alleen nieuw werk starten als het lopende werk was afgerond. En ook hier hebben we daadwerkelijke interacties opgezet, dat wil zeggen, we hebben stand-up meetings en retrospectives gehouden en de business daarvoor uitgenodigd. We hebben dus geen nieuwe meetings uitgevonden, de meetings bestonden al, maar de business maakte er deel van uit.

Oké, ik heb nog één oplossing en dan ben ik ook klaar. Dus, wat hebben we met de strategie gedaan? Nou, weet je nog, het was dat vreemde, achterwaartse mapping-proces. Dus de eerste stap die we probeerden te realiseren was een voorwaarts mapping-proces. Dat wil zeggen, er was een strategie. En op basis van de strategie, wat we deden, was dat we resultaten en acties uit de strategie afleidden. Dat betekent dat de strategie in feite een gesprek op gang bracht: Wat willen we bereiken? En wat moeten we doen om daar te komen, toch? Dat werd dus uit de strategie afgeleid. Vervolgens hebben we de resultaten gemeten, dat we bereikten wat we wilden bereiken. En dat zette natuurlijk het leerproces in gang, dat de strategie verfijnde. Dat was dus de denkwijze. En in feite hebben we dat allemaal op de een of andere manier op een bord afgebeeld. En dat was ons strategiebord. We hebben dus deze strategische punten, toch? Zoals, je weet wel, drie tot vijf jaar, zoals, digitalisering en een aantal culturele thema's, enzovoort.

En wat we hebben gedaan, we hebben in feite resultaten gedefinieerd, wat we binnen het jaar willen bereiken. Dus we hebben de trechter versmald. Vervolgens, als we deze resultaten voor een jaar hebben, zijn we nog een stap verder gegaan, zoals, en wat betekent dat voor de komende 90 dagen? We hebben dus meetbare resultaten voor de komende 90 dagen. We hebben dus een focus gecreëerd over de tijdlijn, 3 tot 5 jaar, 1 jaar, 90 dagen. Je moet je dus echt focussen. Het is behoorlijk moeilijk om vijfjaarsprojecten te prioriteren. Is dit vijfjaarsproject belangrijker dan het andere? Nou, ik weet het niet. We moeten ze allemaal na vijf jaar afronden. Maar als je het op de een of andere manier versmalt, kun je focus creëren. En als we zoiets zouden hebben, zouden we daar acties uit afleiden. En als ik zoiets zie, dan zie ik al het strategiebord. Uiteindelijk is het heel simpel. We hoeven alleen maar een paar rijen toe te voegen en een paar andere rijen te verwijderen. En dat was min of meer het strategiebord waarmee we begonnen te werken.

We hebben hier dus onze resultaten, de jaarlijkse resultaten, en we hebben een schaal van 0% tot 100% waarop we kunnen zien of we vooruitgang boeken. En hier hebben we alleen een zeer vereenvoudigde versie van het bord, een bord van acties en dat is wat we doen. En het punt is, we hebben hier de focus gecreëerd. Dat betekent dus dat we de focus hebben gecreëerd door de tijdtrechter te versmallen, en dan hebben we allemaal de juiste stukjes acties nodig die echt binnen de komende 90 dagen resultaten opleveren. Dat was het strategiebord. En natuurlijk hebben we met zo'n strategiebord ook stand-up meetings gehouden. En we hebben ook retrospectives bij dit bord gehouden. Dat waren dus in feite de drie problemen en de oplossingen die we bedacht hebben. En we gaan even reflecteren op wat we gedaan hebben. Eén ding was... één ding... ik hoor stemmen, ik weet niet of dit een goed moment is.

Eén ding is, als ik de conclusie trek, dat, nou ja, Business Agility is absoluut geen teamsport. Als het gaat om Business Agility, dan is het een bedrijfssport, je moet echt het hele bedrijf meenemen in je denken. En Sohrab heeft het al gehad over Flight Levels. En ik geef je nog een minuutje, want ik denk, als we het over bedrijfssport hebben, wat betekent dat dan? Dus waar in een organisatie kunnen we verbeteringen doorvoeren? Waar moeten we agile worden? En daar gaat Flight Levels precies over. Voor mij is Flight Levels een denkmodel dat me helpt te begrijpen waar in een organisatie ik wat moet doen om te bereiken wat ik wil bereiken. Flight Levels is dus een term uit de luchtvaart, je kunt laag vliegen, of je kunt heel hoog vliegen. Afhankelijk van op welk niveau je vliegt, zie je verschillende dingen. We kunnen in een organisatie heel laag vliegen.

Pas altijd je vlieghoogte aan!

Als we in een organisatie laag vliegen, bevinden we ons op Flight Level One en Flight Level One is het operationele niveau. De teams, de teams die echt het werk doen, we kunnen onze teams agile maken. Normaal gesproken heeft een organisatie meer dan één team, dus zien we meerdere Flight-Level-One-systemen in een organisatie. Wat we ook heel vaak zien, is dat één team alleen niet in staat is om de markt te bedienen. We hebben dus coördinatie tussen meerdere teams nodig om de markt te bedienen. Dat betekent dat we een beetje hoger moeten vliegen. Als we een beetje hoger vliegen, is dat Flight Level Two, de end-to-end-coördinatie. Dat is dus de wereld van de producten, de diensten enzovoort. Wat we dus gaan doen, of wat we hier doen, is dat we ervoor zorgen dat het juiste team op het juiste moment aan de juiste dingen werkt. Zo kunnen we Flight Level Two verbinden met Flight Level One. Het operationele werk wordt op Flight Level One gedaan. En hier coördineren we alleen dat het juiste team op het juiste moment aan de juiste dingen werkt.

En het mooie eraan is dat het me vanuit het perspectief van Flight Level Two niet uitmaakt welke methoden de teams gebruiken. Teams zouden dus kunnen werken met, ik weet niet, met Scrum of teams zouden met Kanban kunnen werken of teams zouden gewoon kunnen werken, dat is ook prima, toch? Zorg er dus gewoon voor dat het juiste team op het juiste moment aan de juiste dingen werkt. Normaal gesproken heeft een organisatie meer dan één product of dienst, dus zien we meerdere Flight-Level-Two-systemen in een organisatie. Als we afhankelijkheden hebben tussen deze Flight-Level-Two-systemen, kunnen we een operationeel portfolio opzetten. Maar dat is nog steeds een Flight-Level-Two-systeem, omdat we het werk over meerdere producten of services heen coördineren. En we kunnen zelfs nog een niveau hoger vliegen, en dat is het strategieniveau.

Het idee van het strategieniveau is dat we het werk in onze organisatie afstemmen op de strategie die we ook hier op het strategieniveau centraal stellen. Natuurlijk kunnen we Flight Level Three en Flight Level Two verbinden, en ook Flight Level Three en Flight Level One. En meestal hebben we niet slechts één strategieboard in een organisatie, maar meerdere strategieboards in een organisatie. Ja. En dat zijn in feite de Flight Levels. En één ding is hier belangrijk: het gaat niet om beter of slechter. Flight Level Three is dus niet drie keer beter dan Flight Level One, maar lost een ander probleem op, toch? Als je teams niet leveren, kun je hierboven de beste beslissingen nemen en de focus en alles op Flight Level Three creëren, de dingen worden toch niet geleverd, toch? Het gaat dus niet om beter of slechter, het gaat erom de juiste hefbomen te vinden die je in je organisatie kunt gebruiken.

En dat is in feite alles. Als je geïnteresseerd bent in meer over Flight Levels, we hebben een stand hier, Catherine, Cliff en ik zullen er iets later zijn. En we hebben natuurlijk ook workshops die je kunt bezoeken. Als je naar flightlevelsacademy.com gaat, zie je het overzicht van alle workshops of het overzicht van de workshops. En wat we doen is dat we in feite praten over wat ik in deze presentatie heb besproken. Dat was het. Bedankt voor het luisteren.

Sociocracy 3.0

=> James Priest & Jeff Cumps praten over [Sociocracy 3.0](/nl/organisatieontwikkeling/sociocracy-3-0-james-priest-jeff-cumps/ "Sociocracy 3.0)

Het agile ministerie

=> Hoe agile zijn de Duitse ministeries? - Een interview met Sebnem Andresen.

Het voordeel van bedrijven die experimenteren

=> Ontdek wat er gebeurt wanneer jouw bedrijf experimenteert!