Shifting the Burden – Systeem Denken helpt bij high-performing teams

/in , , /door

Systeem Denken (Systems Thinking) geeft ons nuttige inzichten in hoe organisatorische systemen werken. De inzichten zijn vaak verrassend in de wijze waarop ze veel voorkomende problemen in organisaties helpen verklaren. Het is jammer dat, buiten het veld van organisatie management wetenschappers, systeem denken nauwelijks bekend is. Systeem Denken is een integraal onderdeel van Agile, al zijn de meeste agilisten zich daar niet van bewust. Agile scaling frameworks als LeSS en SAFe noemen Systeem Denken zelfs expliciet in hun onderliggende principes. En toch kom ik zelden een agile coach tegen met meer dan middelmatige kennis van ST. De meesten hebben er zelfs nog nooit van gehoord. Als je de barrières van agile in organisaties echt wilt begrijpen, dan is kennis van System Denken en van Complexity Theory, ook al niet zo bekend, cruciaal. Want zelfs agile coaches, of moet ik zeggen juìst agile coaches, vallen in de valkuil van lokale optimalisatie en symptomatische oplossingen. Laten we daarom eens kijken hoe Systeem Denken bijvoorbeeld kan helpen bij het ontwikkelen van high-performing teams.

Als je hoofdpijn hebt en je neemt een paracetamol en de hoofdpijn gaat weg, dan ben je hier wellicht tevreden mee en vraag je je nauwelijks af waar die hoofdpijn vandaan kwam. De volgende keer dat je hoofdpijn hebt, neem je weer paracetamol, want dat werkt. Na een tijdje raak je hier aan gewend en zorg je ervoor dat je altijd paracetamol bij je hebt, en ga je niet meer op zoek naar de fundamentele oplossing van je hoofdpijnen. Het steeds innemen van paracetamol maakt het steeds onwaarschijnlijker dat je je gezondheid en manier van leven gaat aanpassen om überhaupt hoofdpijn te voorkomen.

Systeemdenkers hebben patronen van oorzaak-gevolg relaties ontdekt in organisaties die ze archetypes noemen. Shifting the Burden is zo’n archetype, en ons verhaal over hoofdpijn is er een voorbeeld van. Shifting the Burden betekent zoiets als: ‘de last verschuiven naar een ander of iets anders’. Het werkt als volgt: We hebben een symptoom van een probleem, bv hoofdpijn. Er is een fundamentele oplossing voor het probleem, al moet je die vaak ontdekken en zit er vaak een vertraging in de werking ervan. De fundamentele oplossing wordt vaak over het hoofd gezien door korte-termijn denken, druk vanuit de organisatie om met een snelle oplossing te komen, en onvoldoende begrip van het verband tussen oorzaak en gevolg. In plaats daarvan ‘verplaatsen we de last’ door andere oplossingen toe te passen, een snelle fix die prima lijkt te werken. Helaas werken we nu alleen met het symptoom en niet het onderliggende probleem. Het onderliggende probleem woekert onopgemerkt door omdat het gecamoufleerd wordt door de symptomatische oplossing. We passen de quick fix oplossing steeds vaker toe omdat deze leek te werken, waardoor de druk om naar een fundamentele oplossing te zoeken nog verder wordt verlaagd. Uiteindelijk wordt het vermogen van de organisatie om een fundamentele oplossing te vinden ernstig ondermijnd.

Een ander veel voorkomend voorbeeld in de agile wereld is een manager die probeert zijn team te empoweren door middel van delegeren. Maar als het team ergens mee worstelt, grijpt hij in en helpt ze, met alle goede bedoelingen. Na een tijdje vermindert dit het vermogen van het team om zelf oplossingen te vinden. In plaats daarvan worden ze steeds afhankelijker van de manager, precies het tegenovergestelde van wat hij probeerde te bereiken. De over-beschermende scrum master is nog zo’n voorbeeld. Want ja, de boekjes zeggen immers dat de scrum master het team tegen hun omgeving moet beschermen. Ondanks dat dit type scrum master vaak de hemel in geprezen wordt voor de sterke band die hij of zij met het team heeft en de fantastische sfeer die hij/zij heeft weten op te bouwen, is het gevolg dat de scrum master uiteindelijk onbedoeld de leider van het team is geworden. En iedereen is afhankelijk van hem of haar geworden.


Het bovenstaande diagram is wat we een causaal loop diagram noemen dat het generiek Shifting the Burden archetype uitlegt. Het diagram toont de quick fix oplossing (symptomatische oplossing) die tijdelijk het probleem symptoom vermindert, en de fundamentele oplossing die ook tot een verbetering leidt, maar vaak met een vertraging. Je ziet ook een bij-effect van de symptomatische oplossing dat laat zien dat we steeds afhankelijker worden van de symptomatische oplossing en steeds minder in staat zijn om het onderliggende probleem adequaat aan te pakken.

Nu wordt het tijd om naar ons team te kijken. Ik ben veel van dit soort teams tegen gekomen die zelf blijven volhouden dat ze een sterk team zijn: ze vertellen elkaar veel verhalen over hun privé leven, ze nemen regelmatig een drankje samen, en organiseren af en toe een team event. Maar als je het team wat beter observeert merk je op dat de meeste gesprekken behoorlijk oppervlakkig zijn, iedereen is aardig tegen elkaar. De reactie van het team op conflict is het bedekken ervan. Hierdoor leert het team niet om met conflict om te gaan. Op een verantwoorde manier met conflict kunnen omgaan is een onmisbaar ingredient van high-performing teams. Des te meer het team teruggrijpt op de symptomatische oplossing van het in de kiem smoren van conflicten, des te minder zijn ze in staat om aan een fundamentele oplossing te werken. Een fundamentele oplossing zou kunnen zijn om de cohesie in het team te versterken door het opbouwen van vertrouwen, het coachen van het team in conflict-hantering, en het creëren van een gemeenschappelijk gevoel van accountability voor resultaten. Dit wordt beschreven in het tweede diagram in causale loops B12 en B13.

Maar het wordt ingewikkelder. In een complex systeem zijn alle delen met elkaar verbonden. Een verandering in een klein element, kan onbedoeld tot problemen ergens anders leiden. Vaak zien we een serie van shifting-the-burden patronen die met elkaar verbonden zijn: de ene fundamentele oplossing is de symptomatische oplossing voor een ander probleem.

Hoe kan een fundamentele oplossing nou een symptomatische oplossing voor een ander probleem worden? Als we de team cohesie versterken, wordt er steeds meer een team identiteit ontwikkeld. Langzaam ontwikkelt het team een ‘wij-tegen-hun’ mentaliteit naar andere teams of andere delen van de organisatie. Mensen buiten het team beginnen het team te zien als naar binnen gekeerd, vooral met zichzelf bezig, zelfs als dit niet in het belang van de rest van de organisatie is. Er beginnen nu conflicten met de rest van de organisatie te ontstaan. Bekend fenomeen?

De fundamentele oplossing van het bouwen van team cohesie voor het conflicten-binnen-het-team probleem wordt nu een symptomatische oplossing voor een nieuwe probleem: conflict met de rest van de organisatie (causale loop B15). Het team probeert met deze conflicten om te gaan door het sluiten van de rijen, terugvallen op elkaar. Uiteindelijk vermindert dit hun vermogen om op een constructieve manier met de rest van de organisatie om te gaan.

Dus nu moeten we op zoek naar een fundamentele oplossing voor dit probleem. Zo kunnen we proberen het team te helpen om beter te begrijpen wat hun plek in het grotere geheel is (causale loop B16). We zouden het team kunnen aanmoedigen om een deel van hun team doelen expliciet te beschrijven als bijdrages aan hogere organisatiedoelen. Dit is een erg krachtig middel om met de erfenis van de hedendaagse silo organisatie om te gaan: geef teams en afdelingen een doel dat ze niet alleen kunnen behalen maar slechts in samenwerking met anderen.

Deze praktijk is enigszins in tegenspraak met de populaire agile praktijk om teams hun eigen domein te geven om op te focussen. Wij zijn hier tegen. De logica hierachter is om teams aan te moedigen eigenaarschap te nemen op hun domein. Maar teams werken niet in isolatie. Ze zijn onderdeel van een groter geheel, en deze praktijk leidt uiteindelijk tot lokale optimalisatie en  naar binnen gekeerde  teams. Domein-georiënteerde teams is in feite een oplossing om teams te versterken dat weer een symptomatische oplossing vormt voor een ander probleem, namelijk conflicten met de rest van de organisatie. Systeem Denken helpt je dit te begrijpen en te voorspellen.

We hebben in dit artikel slechts een enkel archetype behandeld en slechts een fractie van de concepten en principes van Systeem Denken. En met een heel simpel voorbeeld. Toch zijn hier al waardevolle lessen uit te trekken voor agile coaches die je kunnen helpen bij veel complexere problemen:

  • Focus altijd op de fundamentele oplossing in plaats van de symptomatische oplossing. Weersta de druk van de organisatie om met snelle oplossingen te komen. Er zijn geen quick fixes voor complexe problemen.
  • Wees bewust dat een fundamentele oplossing vaak ontdekt moet worden. In veel gevallen is het geen kwestie van analyse maar van ontdekken door middel van experimenten.
  • Wees bewust dat hoe vaker je een symptomatische oplossing toepast, hoe minder men in staat zal zijn om tot een fundamentele oplossing te komen.
  • Realiseer je dat een fundamentele oplossing tegelijkertijd weer een symptomatische oplossing kan zijn voor een ander probleem.
  • Pas op voor de valkuil van lokale optimalisatie.

Wil je meer weten wat Systeem Denken kan doen voor jouw team of organisatie? Volg dan een van onze Management 3.0 workshops.

Bronnen:
[Martin Knapovsky. Shifting the burden archetype. https://www.knapovsky.com/shifting-the-burden-archetype/]
[Daniel Kim. Shifting the burden revisited: Turtles all the way down. https://thesystemsthinker.com/shifting-the-burden-revisited-turtles-all-the-way-down/]
When your only tool is a hammer

Als je enige gereedschap een hamer is…

/in , , , , /door

De omgeving van organisaties verandert met een toenemende snelheid. Complexiteit en onzekerheid vieren hoogtij. Maar de toolset die management gebruikt voor het managen en vormgeven van hun organisaties verandert maar heel langzaam. Er is een toenemend gat tussen de toepasbaarheid van de gebruikte tools en de probleem domeinen van moderne organisaties. Hoe kunnen we vaststellen in welk domein we zitten en of we passende tools gebruiken?

Er is geen ontkennen aan dat organisaties opereren in een wereld van onzekerheid en continue verandering. Windows of opportunity openen en sluiten steeds sneller. Een concurrentievoordeel voor langere tijd vasthouden is tegenwoordig behoorlijk lastig. Het lijkt ook duidelijk dat de meeste organisaties slecht toegerust zijn om te gaan met snelle veranderingen. Een indicatie daartoe is de gemiddelde levensverwachting van organisaties. Die lijkt in een alarmerend tempo af te nemen. Professor Richard Foster of Yale University leidde een Innosight onderzoek dat aantoont dat een 61 jarige levensverwachting voor het gemiddelde bedrijf in de S&P 500 index in 1958 afnam tot 25 jaar in 1980, tot slechts 18 jaar nu. Sterker nog, in dit tempo zal in 2027 meer dan 75% van de S&P 500 uit bedrijven bestaan waar je nu nog nooit van hebt gehoord. Dat klinkt best alarmerend toch?

Er is duidelijk werk aan de winkel voor organisaties. Zelfgenoegzaamheid is je grootste vijand in deze wereld, en is een één-richting straat naar irrelevantie. Het bedrijvenkerkhof ligt vol met bedrijven die of te laat of helemaal niet op verandering gereageerd hebben. We pretenderen niet het wondermiddel in handen te hebben dat elke organisatie omtovert tot een veerkrachtige adaptieve organisatie die alles aankan. Maar de eerste stap is om te beoordelen in welk probleemdomein we zitten en of de tools die we nu gebruiken daar eigenlijk wel geschikt voor zijn. Helaas blijven veel organisaties hardnekkig vasthouden aan de tools die ze kennen zoals hiërarchie, centralisatie, focus op efficiency, regels en procedures, lineaire planning, etc. Er is op zich niks mis met deze tools, maar ze zijn ontworpen voor organisaties die 100 jaar geleden bestonden. Veel managent tools zijn min of meer nog steeds de erfenis van Frederick Taylor’s Scientific Management en Henri Fayol’s functies en principes van management. De wereld is echter behoorlijk veranderd sindsdien. In Westerse economieën zijn er niet veel branches meer waar deze tools nog goed werken.

Elke organisatie, afdeling, team, of proces bevind zich in een specifiek probleemdomein, elk met zijn eigen passende aanpak en tools. Dus hoe kunnen we vaststellen in welk domein we ons bevinden? Een nuttige tool hierbij is het Cynefin framework. Cynefin onderscheid vier hoofddomeinen, en een vijfde die disorder heet, die elk context beschrijven in termen van de relatie tussen oorzaak en gevolg. De vier hoofddomeinen heetten obvious (I geef nog steeds de voorkeur aan de oude term ‘simple’), complicated, complex, and chaotic. Het disorder domein is bedoeld voor als je niet kunt vaststellen in welk domein je bent.

Voor een gedetailleerde beschrijving van het Cynefin framework verwijs ik naar het uitstekende Harvard Business Review artikel van de bedenker van het framework, Dave Snowden. Voor dit artikel houden we de uitleg kort: In het Obvious domein kunnen we het probleem eenvoudig categoriseren en dan de juiste checklist of procesbeschrijving erbij pakken. Omdat de omgeving in dit domein redelijk stabiel en voorspelbaar is, kunnen we ons richten op het optimaliseren van best practice processen. Een eenvoudig lening aanvraagproces is een goed voorbeeld hiervan.

In het Complicated domein is het allemaal niet zo simpel en voorspelbaar. We hebben experts nodig die de situatie analyseren voor we kunnen reageren. Dit is het domein van de experts en kenniswerkers. Meestal is er nog steeds een significant verband tussen oorzaak en gevolg, maar oorzaak en gevolg kunnen in plaats en tijd van elkaar gescheiden zijn, wat het lastig maakt het verband te zien. Dit wordt versterkt door typische management structuren zoals silo’s en KPI’s. We nemen een beslissing in één silo, laten we zeggen de afdeling Verkoop, dat een ongewenst effect als gevolg heeft op een andere silo, laten we zeggen Operations. We zien de relatie tussen oorzaak en gevolg echter niet omdat het in een andere afdeling gebeurt (plaats), en misschien met een vertraging (tijd). Onze focus op verkoop, versterkt door een KPI die slechts verkoop als output meet, zorgt er nog meer voor dat we het negatieve effect op een andere afdeling missen, omdat je die alleen kunt meten met een andere KPI dan degene waarop wij worden afgerekend.

De Obvious en Complicated domeinen worden de geordende domeinen genoemd. Veel organisaties denken zich in de geordende domeinen te bevinden, terwijl een toenemend aantal situaties in organisaties, teams, en processen eigenlijk in het complexe domein valt, wat een geheel andere aanpak vereist. Want in het Complexe domein werken ‘good’ of ‘best practices’ niet. De omgeving is niet stabiel noch voorspelbaar, en daardoor kunnen we niet simpelweg aannemen dat wat in het verleden werkte ook nu, in een andere context, zal werken. En we kunnen de toekomst ook niet plannen in het complexe domein. We kunnen het alleen ontdekken door te experimenteren. De relatie tussen oorzaak en gevolg kan er wel zijn, maar is meestal pas achteraf te constateren. Dit gaat tegen de intuïtie van veel managers in die dit dan ook maar moeilijk kunnen accepteren. Er is een dominante tendens om de toekomst te kunnen willen controleren en voorspellen, zelfs in situaties waar dat niet mogelijk is, en zelfs als we keer op keer constateren dat onze zorgvuldig opgestelde plannen al heel snel niet uit blijken te komen.

Laten we het factureringsproces als voorbeeld nemen. De meeste organisaties verkopen iets, dus facturering is een gebruikelijk proces. Je zou kunnen denken dat facturering een stabiel voorspelbaar statisch proces dat makkelijk kan worden afgehandeld en geoptimaliseerd door een geautomatiseerd proces. En dat klopt. Maar het gevaar is dat management nu alleen nog maar op regels e processen als middel gaan vertrouwen. Het gaat niet om de 95% aan facturen die correct verwerkt worden, de grootste impact ligt in de 5% waar iets mis gaat of die uitzonderlijk zijn. Dit zijn de gevallen die de meeste tijd kosten, en die een gevaar zijn voor de reputatie van het bedrijf als ze niet adequaat afgehandeld worden. Je kunt de uitzonderingen niet op dezelfde manier behandelen als de voorspelbare gevallen. Maar dat is wel wat de meeste organisaties doen. Als er een uitzondering gevonden wordt, dan creëren we een nieuwe regel. Als de klant klaagt over een foute factuur, dan passen we het proces aan. Tot de volgende uitzondering. En de volgende. Op deze manier worden de systemen langzaam steeds moeilijker te doorgronden en te onderhouden, steeds lastiger aan te passen aan nieuwe situaties, en erg kostbaar. En dan nog worden we telkens weer verrast door nieuwe uitzonderingen die nog niet afgedekt worden door regels. Wat de situatie nog erger maakt is dat de afhandeling van klachten van klanten over foute facturen hetzelfde probleem kent: Klantenservice medewerkers volgen over het algemeen een strikt script dat standaard situatie prima afdekt. Maar de frustratie van klanten komt niet van de standaard gevallen, maar van de uitzonderingen en het onvermogen van klantenservice medewerkers het probleem snel op te lossen

Klinkt dit bekend? Het is een continue bron van zendtijd voor consumentenprogramma’s op tv: telecombedrijven, energiemaatschappijen, en verzekeringsmaatschappijen die doorgezaagd worden over hun onvermogen om niet-standaard situaties, die echter voor klanten en de kijker zo duidelijk lijken, op een adequate manier af te handelen. Het is een klassiek voorbeeld van de verkeerde tool voor het probleemdomein. En toch lijken deze bedrijven er nooit van te leren. Wat is het standaard antwoord van de woordvoerder of manager die dapper genoeg is om voor de camera te verschijnen als hun gevraagd wordt hoe ze dit soort problemen in de toekomst gaan vooromen? “We gaan het proces analyseren en verbeteren”. Zucht…

En dat brengt ons bij het belangrijkste leerpunt van dit artikel: als je niet weet in welk domein je situatie zich bevind, dan zul je het waarschijnlijk behandelen als het domein van je voorkeur of ervaring. En in veel gevallen blijkt dat de verkeerde. Je zult dan tools gebruiken die op zich niet fout zijn, maar niet geschikt voor het betreffende probleem. Ten slotte, als je enige gereedschap een hamer is, dan lijkt elk probleem op een spijker…

Commentaar op SAFe 4.5: puur cosmetisch?

/in , , /door

SAFe 4.5 is pas uitgekomen. Natuurlijk kun je heel veel informatie over wat er nieuw is in SAFe 4.5 vinden bij SAI zelf, dus zal ik niet alles in detail hier behandelen, maar vooral hier en daar wat commentaar geven over het belang en nut van de wijzigingen, of het ontbreken daarvan.

Cosmetische chirurgie is niet altijd slecht

Laat me beginnen met iets dat misschien vooral cosmetisch lijkt, maar voor mij de meest belangrijke verbetering is, namelijk het feit dat de ‘Big Picture’ niet groter of gecompliceerder is geworden deze keer. Van SAFe 3.0 naar 4.0 ging het framework van drie lagen naar vier. In mijn SAFe trainingen grap ik nog steeds dat ik hoop dat SAFe 5.0 straks geen vijf lagen heeft. Ik besteed behoorlijk wat tijd om uit te leggen dat je die extra  Values Stream laag niet moet overwegen tenzij het een heel grote en complexe SAFe implementatie betreft. Natuurlijk is het coördineren van meerdere ARTs in een Value Stream een reële uitdaging. Echter SAFe’s oplossing in de Value Stream laag helt wel erg over naar processen als je even stilstaat bij de Agile Manifesto waarde Individuals and Interactions over Processes and Tools. Wat dat betreft waardeer ik het meest basic coördinatie mechanisme in LeSS erg: Just Talk. We kunnen hier een heel eind mee komen voordat het echt nodig is om formele processen te definiëren. En dit is in feite een valkuil voor veel grotere bureaucratische organisaties die zichzelf in een meer agile organisatie willen omvormen: ze hebben de neiging om alles in processen te modelleren in plaats van mensen te vertellen dat ze ook gewoon met elkaar kunnen gaan overleggen als er iets afgestemd moet worden.

Dus gelukkig is de Big Picture deze keer niet groter geworden. In feite is het een stuk cleaner geworden. De meest significante bijdrage daaraan is de nieuwe configurabiliteit van de Big Picture. SAFe heeft nu vier basis configuraties die elk op een eigen specifieke context zijn gericht. Elke configuratie toont alleen die elementen die relevant zijn voor die configuratie. En hierdoor is de Big Picture een stuk overzichtelijker en makkelijker te begrijpen. De vier configuraties zijn: Essential SAFe, Portfolio SAFe, Large SAFe, en Full SAFe. Een configuratie selecteren en de Big Picture zien aanpassen is eigenlijk best leuk en leerzaam. Ten tweede heeft de Big Picture een make-over gekregen en is daardoor veel minder druk en beter leesbaar. SAI claimt dat ze eigenlijk meer elementen hebben toegevoegd dan weggehaald, dus Kudos aan de visual designer. Ten slotte is de Value Stream laag hernoemd naar Large Solution. Dit lijkt ook weer puur cosmetisch, maar zoals ik al eerder schreef besteed ik veel tijd om mensen uit te leggen dat je niet alles dat op de Big Picture staat moet implementeren alleen maar omdat het erop staat. Door het Large Solution te noemen wordt het denk ik een stuk gemakkelijker te begrijpen dat je een Grote Oplossing alleen nodig hebt bij … een groot probleem.

Nu vraag je je wellicht af waarom ik zoveel aandacht besteed aan cosmetische wijzigingen. De reden hiervoor is dat de ‘compleetheid’ van de Big Picture zowel een zegen is, je kunt immers op alles klikken en een schat aan informatie krijgen, als een vloek. Organisaties hebben de neiging om alles op de Big Picture te implementeren omdat ze denken dat het nodig is. Een cleanere Big Picture kan helpen. Daarbij kan de overvolle Big Picture best overweldigend overkomen en afschrikken in eerste instantie. Maar een andere belangrijke reden is dat het SAFe een makkelijke prooi maakt voor die soms tamelijk luidruchtige groep aan agilisten die, comfortabel vanaf de top van Mount Stupid, naar beneden schreeuwen dat SAFe helemaal niet Agile is, en dat terwijl hun ervaring ermee over het algemeen niet veel verder rijkt dan het bekijken van de Big Picture op scaledagileframework.com. Ja, natuurlijk zou ik ze gewoon kunnen negeren, maar helaas hebben deze lui de neiging hun verhalen ook aan klanten te vertellen. Als je nog nooit van Mount Stupid, ook wel het Dunning-Kruger effect genoemd, hebt gehoord, dat is het fenomeen waarbij die mensen die het minst van een onderwerp afweten zich het meest comfortabel schijnen te voelen om hun mening erover te verkondigen. Klinkt bekend?

Lean Startup

Natuurlijk zijn er ook meer substantiele wijzigingen. Maar daar kun je alle details over lezen op de SAFe website.

Een ervan is de integratie van Lean Startup. Een zeer welkome aanvulling, dat zeker, maar om eerlijk te zijn was er natuurlijk in SAFe 4.0 al niets dat je in de weg stond om Lean Startup praktijken te gebruiken binnen SAFe. Ik promoot al vanaf het begin dat alles een hypothese behoort te zijn die we zo snel mogelijk moeten zien te valideren. Ik heb organisaties ook Alexander Osterwalder’s Business Model canvas en Value Proposition design zien gebruiken binnen SAFe; of Ash Maurya’s Lean Canvas. We hoeven het daarvoor niet per se op de Big Picture te hebben staan. Maar de adviezen zijn natuurlijk erg welkom.

Andere wijzigingen

De rol van DevOps neemt steeds meer toe in SAFe en dat is iets goeds. Veel meer dan dat kan ik er niet over zeggen. Continuous Delivery wordt ook meer benadrukt en krijgt wat meer substantie. Mooi, maar we wisten natuurlijk allemaal al lang dat we Continuous Delivery zeer serieus moeten nemen in elke (geschaalde) Agile omgeving.

Nu weten we ook allemaal dat delivery en release niet hetzelfde zijn, maar wel aan elkaar gerelateerd. Je wil op elk moment kunnen ‘deliveren’, maar niet per se tegelijkertijd ‘releasen’. Er is een enigszins opmerkelijke wijziging in 4.5 als het gaat om releasen: het ging van Release on Demand (v3.0) naar Release Anytime (4.0), en nu weer terug naar Release on Demand in v4.5. Make up your minds guys. 😉

Wat nog meer? De The Implementation Roadmap is er, maar eerlijkheid biedt te zeggen dat die al geruime tijd voor 4.5 uitgekomen is. De Implementation Roadmap is overigens wel een flink stap vooruit ten opzicht van het belachelijke 123 model dat van de Big Picture lijkt te zijn afgevallen. Gelukkig maar. De roadmap biedt veel nuttige informatie maar er blijft een belangrijk mankement: het is nog steeds min of meer een lineair proces. Ik hecht er sterk aan dat een veranderproces ook iteratief moet zijn, gebaseerd op experimenten, en korte feedbackloops. Ik kan je aanbevelen om te kijken naar Lean Change Management en dit te combineren met de Implementation Roadmap.

Conclusie

Dus, ondanks dat er veel nuttige toevoegingen en wijzigingen in SAFe 4.5 zitten, kunnen de meest belangrijke wijzigingen op het eerste gezicht puur cosmetisch lijken. Ik denk dat deze wijzigingen echter erg belangrijk zijn om te helpen voorkomen dat organisaties in een aantal geniepige valkuilen stappen.
[/av_textblock]