Waarom innovatie continu moet zijn

/in , , /door

Innovatie is een hot topic op het moment. Veel organisaties investeren tegenwoordig in een of andere vorm van een innovatie lab, of een intern accelerator programma. Of ze starten kleine startup-achtige bedrijfjes, los van de hoofdorganisatie, om nieuwe producten of diensten in de markt te zetten. Of ze nemen een startup over. Velen experimenteren met concepten als lean startup, business model innovation, of design thinking om hun innovatiekracht een boost te geven. Wat deze bedrijven gemeenschappelijk hebben is dat ze zich realiseren dat hun business model niet eeuwig houdbaar is en dat verandering steeds sneller gaat. Wat ze vaak ook gemeenschappelijk lijken te hebben is de gedachte dat je innovatie ‘extern’ van de rest van de organisatie kunt organiseren. Dat lijkt ook samen te hangen met de gedachte dat je  maar één keer (tegelijk) succesvol hoeft te innoveren om weer een tijd veilig te zijn. Maar is dat wel zo?

De meeste beslissingsmakers zijn het er wel over eens dat hun business model onder druk staat of op enig moment onder druk zal komen te staan. Ze beseffen dat ze een vorm van innovatie nodig hebben. Toch zijn er vele voorbeelden die aantonen hoe lastig het is om op tijd te innoveren. Toen de iPhone werd geïntroduceerd vertelde RIM’s CEO Jim Balsillie aan een Reuters verslaggever dat de introductie van  Apple’s iPhone geen grote bedreiging was, maar niet meer dan de volgende concurrent die de smartphone business instapt. We weten allemaal hoe het met RIM, de maker van de Blackberry, is afgelopen. Toys ‘R US voelde voor mij altijd als een solide naam. Ik besefte me niet eens dat het bedrijf al uit de vijftiger jaren van de vorige eeuw stamt. En toch vroeg het bedrijf in september 2017 faillissement aan. RadioShack was tientallen jaren een bekende naam in de US en toch ging het bedrijf in in 2017 voor de tweede keer failliet. Wat deze bedrijven gemeenschappelijk hebben is dat ze eens zeer succesvol waren, maar er om een of andere reden niet in slaagden om snel genoeg het roer om te gooien teneinde relevant te blijven.

Een andere naam uit vervlogen tijden is Palm. Wat de case van Palm extra interessant maakt is dat ze niet begonnen als een hardware bedrijf. Ze ontwikkelden software voor de dices van anderen. Devices die grotendeels commercieel faalden. Maar Palm slaagde erin zichzelf opnieuw uit te vinden en stonden haast synoniem voor de populariteit van de PDA. Ze hebben zelf meerdere pogingen gedaan zichzelf opnieuw uit te vinden gedurende hun bestaan zoals met de opkomst van de smartphone en met de introductie van het WebOS platform. Maar geen van deze pogingen kwam in de buurt van het succes van hun eerste reïncarnatie. De geschiedenis van Palm lijkt te suggereren dat om op lange termijn te overleven je jezelf op tijd opnieuw moet uitvinden. Eén keer is echter niet genoeg, omdat elk business model op den duur aan zijn einde komt. Dat zou betekenen dat de sleutel naar lange termijn succes niet zozeer het vermogen om te innoveren zelf is, maar het vermogen om dit continu te doen. Dus het is niet de innovatie zelf die telt, maar het vermogen steeds weer nieuwe wateren te verkennen; het groeien van nieuwe succesvolle businessmodellen, en op tijd je weer terug te trekken ten faveure van nieuwe veelbelovende business modellen.

Continue innovatie is relevant als de levenscyclus van een businessmodel kort, of onvoorspelbaar is. Of allebei.

Continue innovatie is pas echt relevant als de levenscyclus van een businessmodel kort, of onvoorspelbaar is. Of allebei. Naar onze mening is dat tegenwoordig het geval in de meeste branches. Laten we onderzoeken hoe dat komt. De belangrijkste overkoepelende reden is dat barriers of entry voor nieuwkomers dramatisch verlaagd zijn:

  • Toegang tot informatie en kennis is vrijwel gelijk voor iedereen tegenwoordig. Je markt beschermen door middel van superieure marktkennis was ooit een standaard manier om je concurrentievoordeel te verdedigen. Maar dit gaat nauwelijks meer op.
  • Toegang tot talent is veel gemakkelijker. Mensen kunnen tegenwoordig overal werken. We hoeven niet per se elke dag bij elkaar te komen in hetzelfde kantoorgebouw.
  • Kapitaal is makkelijker verkrijgbaar. Ondanks dat investeringsmaatschappijen tegenwoordig hogere eisen lijken te stellen, zijn er nog genoeg andere mogelijkheden zoals accelerator programma’s, startup boot camps, en corporate incubator programma’s. Angel investors zijn ook een goede optie voor velen, en crowd-funding platforms groeien nog steeds.
  • Kapitaal is niet alleen makkelijker verkrijgbaar, je hebt er ook minder van nodig. Het ontwikkelen van een product of dienst, vooral online, is nog nooit zo goedkoop geweest.
  • Volgens Ash Maurya kun je een bedrijf tegenwoordig vanaf elke plek ter wereld starten en laten groeien. Geografische grenzen zijn er nauwelijks meer. Sterker nog, je kunt zelfs een globale speler zijn. Hal Varian, Chief Economist at Google, zegt hierover:

Als het einde van de 20e eeuw het tijdperk van de multinational was, dan is de vroege 21e eeuw het tijdperk van de micro-multinationals: kleine bedrijven die mondiaal opereren.

Het concurrentie landschap is hierdoor behoorlijk op z’n kop gezet. Maar de meeste organisaties zijn ontworpen om een langdurig concurrentievoordeel te verdedigen. Ze zijn ontworpen om het laatste restje efficiëntie uit een business model te persen voor het op te geven. Als gevolg hiervan zijn ze slecht toegerust voor snelle en herhaaldelijke innovatie. Dit verklaart mede de populariteit van het extern organiseren van innovatie, weg van de kern van de organisatie, afgeschermd van de gebruikelijke bureaucratie. Maar er is een nog belangrijkere consequentie die business leiders zullen moeten begrijpen en accepteren als ze ook maar een kans willen hebben om hun organisaties langdurig success te blijven bezorgen:

Een duurzaam langdurig concurrentievoordeel bestaat niet meer…

Laat dat even bezinken…. Een concurrentievoordeel wordt over het algemeen omschreven als het vermogen van een organisatie het beter te doen dan zijn concurrenten. De Engelse term hiervoor, Competitive Advantage is ook de titel van een boek uit 1985 van Michael Porter, onmiskenbaar het standaardwerk op dit onderwerp. Het grootste probleem met Porter’s model is zijn aanname dat een concurrentievoordeel duurzaam kan zijn, wat inhoudt dat je je voordeel langdurig succesvol kunt verdedigen. In de hedendaagse wereld van snelle veranderingen en hoge complexiteit is dat een gevaarlijke aanname. Het bedrijvenkerkhof ligt vol met ooit bekende en succesvolle bedrijven die te lang vasthielden aan die aanname. Rita Gunther McGrath, een bekend expert op dit gebied, zegt het als volgt:

When competitive advantages don’t last, or last for a much shorter time than they used to, the strategy playbook needs to change.

Het tempo van verandering is simpelweg te hoog voor een strategie, gebaseerd op duurzame concurrentievoordelen, om bij te blijven. De verlaagde toegangsbarrières maken het heel moeilijk om een concurrentievoordeel langdurig successful te verdedigen. Daarbij, wil wil er nu altijd in de verdediging zijn? Daarom moet innovatie continu zijn. Maar dat brengt ons terug bij de vraag of het verstandig is om innovatie te externaliseren. Ik denk dat je mijn mening inmiddels wel kunt raden. Dat is het niet. Een accelerator programma kan best een aantal waardevolle ideeën opleveren. En een interne startup kan best de levensvatbaarheid van een business model aantonen. Maar tegelijkertijd is er niets fundamenteels veranderd in de organisatie. Terwijl een klein agile deel van de organisatie met nieuwe ideeën komt, is de rest van de organisatie nog steeds gericht op het verdedigen van een langdurig concurrentievoordeel, op maximalisatie van efficiëntie, en op schaalvoordelen. Het is nog steeds dezelfde trage olietanker. Wat gebeurt er als nieuwe businessmodellen uiteindelijk geabsorbeerd worden door de moederorganisatie? Op termijn heb je weinig bereikt. Wat er nodig is, is wat wij een Adaptieve Organisatie noemen:

De Adaptieve Organisatie is in staat zichzelf continu opnieuw uit te vinden.

Natuurlijk is het goed nieuws dat organisaties het initiatief nemen voor innovatie programma’s. Ik ben echter bang dat de tijd zal uitwijzen dat de huidige trend van het externaliseren van innovatie, uiteindelijk tot teleurstellende resultaten zal leiden. Het voelt ook alsof senior management niet 100% aan boord is: ze leunen nog altijd op de huidige organisatie zoals die is, en innovatie is een show die zich deels achter de coulissen afspeelt en makkelijke geannuleerd kan worden als de populariteit achteruit gaat. Ik zou willen eindigen met een quote van de beroemde Peter Drucker:

Because the purpose of business is to create a customer, the business enterprise has two–and only two–basic functions: marketing and innovation

Meer weten over continue innovatie? Volg onze training Continuous Innovation of neem vrijblijvend contact met ons op.

 

Bronnen:

[Dabrowski, W. (2007). “Update 1-RIM Co-CEO doesn’t see threat from Apple’s iPhone”. Reuters.]

[Hal Varian (2011). Micro-multinationals will run the world. http://foreignpolicy.com/2011/08/15/micromultinationals-will-run-the-world/]

[McGrath, Rita Gunther. (2013). The end of competitive advantage. Harvard Business Review Press. p. 4.]

Why innovation needs to be continuous

/in , /door

Innovation is a hot topic nowadays. Many organisations are investing in some form of innovation lab or internal accelerator program. Or they separate new business ventures from the main organisation by starting a startup-like small company. Or acquire one for that matter. Many are experimenting with concepts like lean startup, business model innovation, or design thinking to give their innovation powers a boost. What these companies have in common is they realize their business models won’t last for ever. What they also seem to have in common most often is the idea that you can successfully externalize innovation from the rest of your organisation. This seems to tag along with the idea that you only need to innovate once (successfully) to be safe for a while again. But is this true?

Most decision makers agree their business models are or will be under pressure. They need some form of innovation. Yet there are plenty of examples that illustrate how hard it is to innovate in time. Upon the introduction of the iPhone, RIM’s CEO Jim Balsillie, told a Reuters reporter that the launch of Apple’s iPhone wasn’t a major threat, simply the entry of yet another competitor into the smartphone market. We all know how that ended.  Toys ‘R US always seemed like a rock solid name to me. I didn’t even realize the company dated back to the fifties. Yet, the company filed for bankruptcy in September 2017. RadioShack was a household name for decades in the US after it filed for bankruptcy for the second time in 2017. What these companies have in common is that they were once highly successful, but didn’t manage to turn the ship around fast enough to survive or stay relevant.

Another faded name is Palm. What is interesting about Palm was that they did not start out as a hardware company. They first provided software for other brands devices. Devices that largely failed commercially. But somehow Palm reinvented themselves in-time and popularized the PDA. They actually tried to reinvent themselves a couple of times during their period of existence with the rise of smartphones, and with the introduction of their WebOS platform. But none of those attempts rivaled the success of their first reincarnation. The history of Palm seems to suggest that in order to survive in the long run a company must reinvent itself in time. But one time is not enough as the new business model will eventually fade as well. This would mean that the key to long term success is not so much the ability to innovate but the ability to do it continuously. So it is not the innovation itself that counts, but the ability to continuously test new waters; grow and nurture successful business models, and pull out in time in favor of new more promising opportunities.

Continuous innovation makes sense when the life-cycle of a business model is either short, or unpredictable. Or both.

Continuous innovation only makes sense if the life-cycle of a business model is either short, or unpredictable. Or both. We argue this is the case in most industries nowadays. Let’s investigate why. One of the major reasons is that barriers of entry for newcomers are dramatically lowered:

  • The access to information and knowledge is now almost equal for anyone. Protecting a market by superior knowledge once was a standard way to protect your competitive advantage.
  • Access to talent is easier. People can work everywhere nowadays, we don’t necessarily have to gather in the same office building everyday anymore.
  • Capital is more easily obtainable. Although investment funds seem to have raised the bar lately, there are still many accelerator programs, startup boot camps, and corporate incubator programs. Angel investors are a valid option for many, and crowd-funding platforms are still growing.
  • Access to capital is not only easier, companies typically also need less of it to start. Launching a product or service, especially online, has never been faster and cheaper.
  • According to Ash Maurya you can launch and grow a business from anywhere these days. Geographic borders are down. Even more, you can be a global player too. As Hal Varian, Chief Economist at Google, puts it:

If the late 20th Century was the age of the multinational company, the early 21st will be the age of the micro-multinationals: small companies that operate globally.

The competitive landscape has been majorly disrupted because of this. However, most companies are designed to defend their business models over a long period of time. They are designed to squeeze the last bit of efficiency out of a business model before giving up. As a consequence they are ill equipped for fast and repeatedly innovation. This explains the popularity of organizing innovation away from the core of the organization, shielding it from the slow bureaucracy of the organisation.  There is an even more profound and important consequence that business leaders need to understand and accept in order to have a decent chance to lead their organizations to long-term success:

A sustainable competitive advantage no longer exists.

Let that sink in for a minute… Competitive Advantage is mostly described as the ability of an organization to outperform its competitors. It is also the title of the 1985 book from Michael Porter, undeniably the textbook on this subject. The biggest problem of Porter’s model lies in the assumption that a competitive advantage can be sustainable, that is: you can successfully defend your competitive advantage over long periods of time. In today’s world of fast change and high complexity, that is a dangerous assumption to bet on. The business graveyard lies full of once well-known and relevant names of companies who held on to that belief for too long. Rita Gunther McGrath, a renowned expert in this field, puts it this way:

When competitive advantages don’t last, or last for a much shorter time than they used to, the strategy playbook needs to change.

The pace of change is just too high for a strategy based on sustainable competitive advantage to keep up. The lowered barriers of entry make it very hard to successfully defend a competitive advantage, and besides, who wants to be on the defense forever? Therefore, innovation needs to be continuous. But that brings us back to the question whether it is a good idea to externalize innovation. I think you can guess my answer by now. It is not. While an accelerator program can come up with some promising new business ideas, and a startup like separate company can prove some viability in a new opportunity, nothing has fundamentally changed to the core of the organisation. While a small nimble part of the organisation comes up with new ideas, the rest of the organisation is still aimed at defending a competitive advantage, at maximizing efficiency, and gaining economies of scale. It is still a slow bureaucratic oil tanker. What happens if the new business models eventually are absorbed into the mother organisation? In the end you have gained little. What’s needed it what we call an adaptive organisation:

The Adaptive Organization has the core ability to continuously reinvent itself.

Although it is applaudable that companies take initiative in innovation programs, I am afraid that the current prevailing strategy of externalizing it, will bring disappointing results in the long run. It also feels like senior management is not all in: they still bank on the current main organisation, and innovation is still a separate show that can easily be canceled once its popularity starts fading. Let’s finish with a quote of the famous Peter Drucker:

Because the purpose of business is to create a customer, the business enterprise has two–and only two–basic functions: marketing and innovation

If would want to learn more about continuous innovation, you can attend one of our Continuous Innovation workshops. Or contact us for a talk.

 

Sources:

[Dabrowski, W. (2007). “Update 1-RIM Co-CEO doesn’t see threat from Apple’s iPhone”. Reuters.]

[Hal Varian (2011). Micro-multinationals will run the world. http://foreignpolicy.com/2011/08/15/micromultinationals-will-run-the-world/]

[McGrath, Rita Gunther. (2013). The end of competitive advantage. Harvard Business Review Press. p. 4.]

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

Shifting the Burden – Using Systems Thinking to build high-performing teams

/in , , /door

Systems Thinking provides us with useful insights how organizational systems work. The insights are often surprising in the way they help explain common dysfunctions in organizations. It is a pitty that beyond the field of organizational scientists it doesn’t seem to be very well known. Systems Thinking is part of the foundation of Agile: Agile scaling frameworks like LeSS and SAFe both explicitly mention Systems Thinking in their underlying principles. Yet, rarely do I come across agile coaches that even have a mediocre understanding of ST. Most have even never heard of it. If you really want to understand the barriers of agile in organizations, both Systems Thinking and Complexity Theory, also not that well-known, are crucial. Because even agile coaches or should I say especially agile coaches, fall into the traps of local optima and symptomatic solutions. So let’s explore how Systems Thinking can help in building high-performing teams.

If you have a headache and you take an aspirin and the headache goes away, then you might just be happy with that and not worry about why you had a headache in the first place. Next time you get a headache, you just take another aspirin, because it worked the first time. Pretty soon you will get used to it and always keep aspirin around and never look for a more fundamental solution to headaches. Taking aspirin will make it less and less likely that you actually adjust your health so that your body works right in the first place.

Systems Thinkers discovered patterns of cause-effect relationships in organizations that are called archetypes. Shifting the Burden is one such archetype, and the headache story above is an example of it. Here’s how it works: We have a problem symptom. There is a fundamental solution to the problem, although it usually works at a delay. The fundamental solution gets overlooked very often because of short-term thinking, pressure within the organization to come up with a quick fix, and a poor understanding of the relationship between cause and effect. Instead we ‘shift the burden’ to other solutions, easy fixes that seem to work well. Unfortunately we only deal with the symptom and not the underlying problem. Covered up by the symptomatic solution, the underlying problem grows worse unnoticed. We use more and more of the quick fix solution because that seemed to work, further reducing the pressure to seek a fundamental solution. Eventually the organization’s ability to solve the underlying problem gets undermined.

Another common example in the agile world is a manager that is trying to empower teams by delegation. But as the team struggles he steps in to help them, with all good intentions. Over time this reduces the ability of the team to solve issues themselves. Instead they increasingly get more dependent on the manager. The overprotective scrum master is another well-known phenomenon in this category. Although often praised for the good relationship he or she has with the team and the great atmosphere in the team, the scrum master unintentionally effectively has become the leader of the team, with everyone depending on him or her.


The picture above is a causal loop diagram that explains the generic Shifting the Burden archetype. The diagram depicts the quick fix solution that temporally lowers the problem symptom, and the fundamental solution that would lower the symptom as well, although usually at a delay. There’s a side effect loop that shows we get more dependent on the quick fixes as we use them undermining our ability to address the actual underlying problem.

Now let’s get back to our team. I have seen many teams like this where the team itself insists they are a strong team: they tell each other lots of stories about their private life, they have drinks together and organize the occasional team event. But if you observe the team a little closer you will notice most conversations are quite shallow, everybody’s playing nice to each other. The teams reaction to conflict is to cover it up. As a result the team does not learn how to deal with conflict. The more they revert to the symptomatic solution of smoothing things over, the less the team will be capable of working on a fundamental solution, which could be working on team cohesiveness by creating trust, coaching the team in conflict resolution and a shared sense of accountability for results. This is described in the first part of the diagram: causal loops B12 and B13.

In a complex system however all parts of the system are interconnected and a change in one part can inadvertently lead to a problem elsewhere. We often find series of interconnected shifting-the-burden structures where one fundamental solution is another problem’s symptomatic solution.

So how does the fundamental solutions become the symptomatic solution of another problem? While team cohesiveness grows a team identity starts getting developed.  They slowly develop a ‘them-against-us’ mentality towards other teams or the surrounding organization. People outside of the team start perceiving the team as inward-thinking, taking care of only themselves, even if not in the interest of the larger organization. Conflict with the rest of the organization starts to grow.

The fundamental solution of building team coherence to the conflicts-within-the-team-problem has now become a symptomatic solution of a new problem: conflict between the team and it’s environment (causal loop B15). The team tries to deal with the new conflict by closing their ranks, sticking together, which in the ends only decreases their ability to fundamentally deal with the rest of the organisation in a constructive manner.

So now we need to look at a fundamental solution to his problem, like helping the team to build a better understanding of the part they play in the larger organization (causal loop B16). You could encourage the team to explicitly define some of their team goals as contributions to higher organisational goals. This is actually a very powerful way to deal with the issues we inherit from today’s silo organisations: give teams or departments a goal they cannot achieve by themselves, but only by collaborating with others.

This practice is in contrast with the popular agile practice of giving teams their own domain to focus on. We are strongly apposed to this. The logic behind it is to encourage teams to take ownership of their own area. But teams don’t work in isolation. They are part of a bigger whole, and this practice will unavoidably lead to local optimization and inward-focusing teams. Systems Thinking can help you understand and predict that.

Note that we covered only one Systems Thinking archetype in this article and only a fraction of the concepts behind Systems Thinking. Nevertheless there are valuable lessons for agile coaches or anybody working on high performing teams:

  • Always focus on the fundamental solution vs a symptomatic solution. Withstand organizational pressure for quick solutions. There are no quick fixes to complex problems.
  • Note that a fundamental solution often needs to be discovered. In many cases it is not a matter of analyzing, but of discovery through experiments.
  • Be aware that the more one applies a symptomatic solution the less one becomes able to come up with a fundamental solution.
  • Realize that a fundamental solution can at the same time be a symptomatic solution for another problem.

Do you want to know more on what Systems Thinking can do for your team and organization? Attend one of our Management 3.0 workshops.

Notes:
[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/]

SAFe Meetup: Is SAFe een IT-feestje?

/in /door

22 Mei organiseerde Trivorto weer een Scaled Agile Meetup sessie. Deze keer waren we te gast bij Transavia op Schiphol. Een inspirerende locatie met een geïnspireerde en enthousiaste groep deelnemers. Het thema van de avond was “Is SAFe een IT-feestje?“. Een ietwat retorische vraag natuurlijk, want waar iedereen het al snel over eens was is, dat alignment tussen business en IT cruciaal was.

De avond werd afgetrapt door Gregor Heidinger die een prikkelende uitlag gaf over het concept valuestreams, of waardeketens. Trivorto ziet valuestreams als HET middel om vanuit de business te denken, ipv vanuit IT. Een valuestream is immers de keten van alle activiteiten en betrokken mensen die nodig zijn om waarde te leveren aan de klant. Cross-business dus. Echter, SAFe maakt een onderscheid tussen twee soorten waardestromen: de operationele waardestroom, en een ondersteunende development waardestroom. En het is de laatste waar SAFe zich op richt. Wat ons betreft is dat een gemiste kans. De operationele waardestroom is de echte waardestroom, daar vinden alle waardetoevoegende activiteiten plaats. Gregor nodigde de deelnemers uit hier over na te denken bij de implementatie van SAFe.

Dagvoorzitter Dave Boere nam de groep daarna mee in een uitgebreide workshop om gezamenlijk de officiële SAFe Implementation Roadmap tegen het licht te houden in het kader van IT-business alignment. Biedt de roadmap daartoe juist kansen, of ook risico’s? De gezamenlijke denkkracht van een dertigtal deelnemers werd ingezet om op deze vraag een antwoord te geven. Verdeeld in drie groepen ging men aan de slag, en na enige tijd werd een uitgebreide lijst aan risico’s en kansen aan elkaar gepresenteerd.

Vervolgens ging de groepen aan de slag met het bedenken van een aantal opties waarmee de geïdentificeerd kansen benut, of de risico’s gemitigeerd konden worden. De groepen werden uitgenodigd om voor enkele opties een experiment te beschrijven met een duidelijke hypothese, waarmee je bij wijze van spreken morgen aan de slag kunt. Een paar interessante experimenten werden gepresenteerd en er ontstond een mooie levendige discussie rond deze experimenten.

Al met al was het een weer een geslaagd event, zeker ook volgens de deelnemers. Met name Thalicia en Nicoline van Transavia hartelijk bedankt voor de gastvrijheid, de verzorging van een mooi inspirerende locatie, de geweldige catering.

Mocht je ook aan een SAFe Meetup sessie willen deelnemen, je bent van hart welkom. Hou de Meetup site in de gaten voor de agenda.

Trivorto spreekt op PPM Jaarcongres 30 Mei 2018

/in /door

Op 14 Mei wordt het 14e Project Portfolio Management Jaarcongres gehouden in congrescentrum Figi in Zeist. Het thema is: “Wie wordt de transformatie regisseur?”.

Trivorto medeoprichter Gregor Heidinger verzorgt een van de keynote sessies. In zijn sessie over Agile Portfoliomanagement deelt Gregor zijn ervaringen en aanpak met betrekking tot het inrichten van portfoliomanagement. Prikkelende onderwerpen zijn o.a. decentrale budgettering, en het afschaffen van projecten.

Wil je meer weten? Kijk dan op de PPM jaarcongres website.

Een agile training kiezen: Gimme the tools!

/in , , , /door

Als je op zoek gaat naar een geschikte aanbieder van een (agile) trainingen en workshops, dan let je er  uiteraard op dat de training vooral praktisch is. Je wil veel nieuwe tools aangereikt krijgen. Liefst niet veel theorie. Toch? Nou…dat lijkt wel de impuls van velen, maar is dat eigenlijk wel terecht? Welke balans tussen theorie en praktijk is nou eigenlijk verstandig?

Wij geven veel trainingen en workshops. We zien deelnemers van allerlei pluimage, maar één ding hebben de meesten gemeenschappelijk: een duidelijke voorkeur voor praktijk en tools t.o.v. onderliggende theorie. En dat snappen we ook wel. Je wilt ten slotte het geleerde meteen in de praktijk brengen. Dus uiteraard zijn onze trainingen voor het grootste deel op de praktijk gericht, met heel veel praktijkvoorbeelden, en oefeningen. En tools. Maar toch vinden wij het belangrijk een goede balans aan te brengen tussen praktijk en theorie.

“Gimme the tools!” Dat lijkt het credo als we inventariseren wat de wensen en verwachtingen van de training zijn. Wij framen die verwachting direct bij de start: “Ja, we bieden veel tools. Maar het is cruciaal dat je begrijpt waarom de tools werken, zodat je ze kunt aanpassen aan je eigen lokale context.” Tools zonder begrip zijn trucjes. Niks mis mee op zich. Het probleem is alleen dat trucs alleen werken in stabiele voorspelbare omgevingen. Elke keer als je de truc toepast, krijg je dan hetzelfde resultaat. Fantastisch! Niet meer over nadenken! Helaas bevinden we ons tegenwoordig nauwelijks meer in stabiele voorspelbare omgevingen. En de hele gedachte achter agile werken is juist dat we moeten leren omgaan met niet stabiele, niet voorspelbare omgevingen. Dus heb je geen trukendoos nodig, maar een gereedschapskist. Met de bijbehorende vakkennis om te weten welk gereedschap je waarvoor gebruikt. En waarom…

En daarom besteden we ook ruim aandacht aan de onderliggende principes. Waarom werken de tools nou eigenlijk? En in welke context? Zodat je het gebruik ervan kunt aanpassen op jouw situatie. Zodat je de onderliggende theorie kunt gebruiken om tools te combineren en nieuwe tools te ontdekken. We laten de deelnemers ruimschoots zelf met de materie werken en met elkaar van gedachten wisselen hoe en wanneer iets toe te passen.

Instemmende knikjes als we onze uitleg over balans tussen theorie en praktijk geven. En toch zien we steeds dezelfde sticky notes weer bij de tussentijdse evaluaties: “Nog meer tools graag!” De wens naar praktische tools is diepgeworteld. Zie het als het verschil tussen het volgen van een receptenboek en een chef. Een recept volgen is een trucje. Zolang de omstandigheden hetzelfde blijven, kun je prima scoren met je favoriete gerecht. Maar een chef kun je een setje losse ingrediënten geven, en hij schotelt je een fantastisch nieuw gerecht voor. En dat is wat wij graag willen bereiken met onze workshops: we willen mensen helpen een chef te worden op hun gebied, geen receptenboekvolger.

De wens naar tools is een begrijpelijke. Ook wijzelf betrappen ons er regelmatig op. Maar het is ook een potentiele valkuil waarvan je je bewust moet zijn. Dus de volgende keer dat je je innerlijke stemmetje “Gimme the tools!” hoort roepen, neem dan even gas terug en probeer te beredeneren waarom en wanneer iets werkt en wanneer niet. Spar erover met collega’s. In onze workshops krijg je daar in elk geval volop ruimte voor.

Scaled Agile Framework Meetup groep voorbij de 250 leden

/in /door

Trivorto organiseert de Meetup groep rond het Scaled Agile Framework (SAFe) in Nederland. Leden van de groep zijn vertegenwoordigers van organisaties die met SAFe werken, die interesse hebben in SAFe, en agile coaches. Regelmatig komen de leden bij elkaar om ervaringen uit te wisselen over diverse onderwerpen op het gebied van agile scaling.

Wij zijn er trots op dat de Meetup groep inmiddels het ledenaantal van 250 gepasseerd is. Het is mooi om te zien dat het onderwerp zo leeft en dat mensen zo bereid zijn elkaar te helpen met tips en ervaringen. De sessies worden goed bezocht en de interactieve manier van kennis uitwisselen wordt zeer gewaardeerd.

We zien het als een belangrijke rol voor ons om die kennisoverdracht te faciliteren om zo bij te dragen aan het op een hoger niveau tillen van grootschalige agile transformaties. Wil je hier ook aan bijdragen? Wordt dan lid van de Meetup groep en bezoek een van onze bijeenkomsten: https://www.meetup.com/nl-NL/Netherlands-Scaled-Agile-Framework-SAFe-Meetup/

Verandermanagement 3.0: Ook de manier van veranderen verandert!

/in , , /door

Er is geen tekort aan methodes, boeken, en meningen over het onderwerpen van verandering in organisaties. Of we nu een agile manier van werken willen adopteren, of er nu een grote reorganisatie aan de gang is, of innovatie verbeterd dient te worden, of we ondergaan een fusie of overname, verandering is alom. En ondanks alle kennis en expertise over verandermanagement in de wereld, lijkt het toch elke keer weer een martelgang. Maar daarnaast is er nog iets met het concept van verandering zelf aan de hand dat ervoor zorgt dat de manier hoe we veranderingen managen ook moet veranderen: Organizaties en processen worden steeds complexer, het lijkt steeds moeilijker om een businessmodel voor langere tijd concurrerend te houden, en grote ondernemingen worden aan alle kanten bedreigd door lenige startups. Organisaties opereren in een tijd van veel onzekerheid en een hoog tempo van verandering en aanpassingsvermogen is vereist.

Er zijn natuurlijk veel verschillende manieren hoe organisaties omgaan met verandering, maar er zijn wel enkele gemeenschappelijke kenmerken die we gewoonlijk tegenkomen: Verandering is vaak planmatig en gaat er van uit dat we van tevoren een plan kunnen formuleren dat we ook zo kunnen uitvoeren, het wordt top-down uitgevoerd, en het is veelal een lineair proces. Laten we eens nagaan hoe deze kenmerken passen binnen de huidige eisen aan het faciliteren van verandering.

De grootste fout die we zien in het omgaan met verandering is dat verandering wordt gezien als een tijdelijke status tussen de huidige en de nieuwe gewenste situatie. We plannen de verandering, voeren het uit, en dan zijn we klaar. Toegegeven, dat is een wat vereenvoudigde weergave van de werkelijkheid, maar het punt is dat verandering geacht wordt om de naar een nieuwe gewenste staat te brengen, waarna op een gegeven moment de verandering afgerond is. Verandering wordt dan gezien als een project met een begin en einddatum. Wij zijn van mening dat, in de snel veranderende onzekere wereld van vandaag, verandering continue dient te zijn. Dus we moeten altijd veranderen. Het is geen project met een einddatum, we zijn altijd in een staat van verandering. We kunnen ons niet veroorloven om verandering uit te stellen tot het punt waarop marges onder druk staan, of een businessmodel op z’n retour is. Dat is te laat. We moeten continue op zoek naar nieuwe kansen en veelbelovende waardeproposities, of betere manieren om te werken, en de organisaties daaromheen veranderen.

Er is ook nog een ongewenst bijeffect aan de projectgebaseerde verandermanagement aanpak: het is zeer ingrijpend voor betrokken werknemers, omdat verandering altijd groot, pijnlijk, en urgent lijkt te zijn. Het leidt tot een erg onzekere tijd voor mensen tot de boel weer een beetje tot rust komt. En net als mensen een beetje herstellen van de vorige reorganisatie wordt de volgende alweer aangekondigd. Continue verandering biedt hier kansen omdat veranderingen constant en kleiner zullen zijn, minder ingrijpend. Impact is gradueel en niet disruptief.

Het ingrijpende karakter van planmatig verandermanagement wordt nog eens versterkt door het feit dat het meestal top-down wordt uitgevoerd. In onze workshops vragen we deelnemers regelmatig om een aantal veranderingen op te noemen die ze hebben meegemaakt, en aan te geven hoe positief of negatief ze deze verandering ervaren hebben. Vervolgens vragen we ze de veranderingen onder te verdelen in interne en externe veranderingen. Externe verandering vind zijn oorsprong buiten jezelf of je team. Interne verandering wordt geïnitieerd vanuit jezelf of je team. Het is ongetwijfeld weinig verrassend om te horen dat mensen over het algemeen interne veranderingen veel positiever waarderen dan externe veranderingen. En toch wordt een verandering meestal aangekondigd door (top) management en start het zelden vanuit de medewerkers zelf. Als gevolg hiervan dient verandermanagement zich veel bezig te houden met weerstand tegen verandering. Wij vinden dat dit gereframed moet worden naar ‘omgaan met verandering’. Naar onze ervaring is een verandering veel succesvoller en bestendiger als het gebeurt in de vorm van een continue stroom aan kleine experimenten die geïnitieerd worden door medewerkers zelf. Het is niet slechts een kwestie van het betrekken van medewerkers, verandering dient ook echt potentieel vanuit medewerkers geïnitieerd en uitgevoerd te kunnen worden.

Dit betekent overigens niet dat een verandering geen steun van senior management nodig heeft. Uiteraard wel. Maar ook hier is een les te leren. Als we managers vragen wat er naar hun mening veranderd moet worden, krijgen we antwoorden als ‘De teams moeten meer verantwoordelijkheid nemen’, of ‘mensen op de afdeling moeten beter leren samenwerken’. Als we medewerkers dezelfde vragen stellen, krijgen we typische antwoorden als ‘Management moet leren ons te vertrouwen’, of ‘Management begrijpt niet wat we nodig hebben’. Zie je de trend? We hebben de neiging om de noodzaak te zien dat anderen moeten veranderen. Dus als je als manager een verandering wilt steunen, verander dan eerst jezelf. En wees daar zeer transparant over. Dat is de eerste stap die management moet nemen om verandering te ondersteunen. De andere stap is de neiging weerstaan om mensen te managen om te veranderen in plaats van om een omgeving te managen waarin mensen zichzelf kunnen veranderen.

Het probleem met een planmatige manier van veranderen is dat je verandering simpelweg niet kunt plannen. En een gedetailleerd eindbeeld van de gewenste organisatie definiëren kan ook niet. Niet in complexe omgevingen. Er zijn simpelweg teveel variabelen om te controleren. Je moet je toekomst ontdekken. Dat betekent niet dat we plannen als activiteit niet waarderen, maar we vertrouwen niet op het plan als uitkomst van planning. Het ontdekken van de toekomst van de organisatie (ondersteund door een goed gedefinieerde Purpose) betekent dat we continue kleine fail-safe experimenten uitvoeren om te ontdekken en te leren. Verandering dient op een vergelijkbare wijze plaats te vinden. Als we plannen, doen we aannames. Deze aannames moeten zo snel mogelijk met korte feedbackloops gevalideerd worden door middel van kleine verander-experimenten, die we zorgvuldig reviewen. Vervolgens kunnen we bijsturen op basis van het geleerde.

Verandering is dus geen lineair proces, het is een iteratief feedback gedreven proces. We scannen continue onze omgeving af om inzichten te vergaren in trends, uitdagingen, dingen die goed werken of juist niet, en nieuwe kansen. Vervolgens plannen we en bereiden we fail-safe verander-experimenten voor, geïnitieerd door de medewerkers zelf, en vergaren we snelle feedback op onze aannames door de experimenten te reviewen. Dat is Verandermanagement 3.0 in een notendop.

Wil je meer weten over Verandermanagement 3.0, gebaseerd op de Lean Change Management methode van Jason Little? Neem dan contact met ons op, of schrijf je in voor een van onze workshops.