Tag Archief van: Agile

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/]