Het strategie-ding

Geplaatst op door erik

Dit artikel is deel van een drieluik over organisatie ontwikkeling. Het eerste deel behandelende het fenomeen cultuur (Het cultuur-ding) in relatie tot organisatie ontwikkeling. Het derde behandelt een effectieve ontwikkelaanpak in samenhang met cultuur en strategie.

In de dagelijkse praktijk gebruiken we de begrippen missie, visie en strategie nogal door elkaar, zonder van elkaar te weten wat we daar precies onder verstaan of hoe deze concepten dan samenhangen. Consequentie hiervan zijn misverstanden, onvoldoende synergie, onbekende en niet ingevulde verwachtingen. Voor effectieve ontwikkeling van een organisatie is het goed een helder, gedeeld beeld te creëren van de essentie van deze begrippen.

Kader en doel

Het begrip missie levert van de drie concepten nog de minste problemen op.

De missie vertolkt de reden van bestaan van de organisatie verwoord.

Dit is dus de maatschappelijke, economische en technologische relevantie.

Wat visie en strategie betreft is dit een stuk lastiger. Managementspecialist Mintzberg, bijvoorbeeld, onderkent 7 nog steeds in de praktijk herkenbare definities voor strategie, Hoogervorst onderkent twee soorten en Ten Bosch definieert strategie als de ziel van de onderneming. Met het concept visie is het niet beter gesteld. Dat varieert van een droombeeld tot de aanpak om de missie te realiseren.

Bovenstaande figuur laat zien hoe de verschillende begrippen samenhangen. Doel van dit artikel is tot werkbare vormen van visie en strategie te komen om de ontwikkeling van organisaties effectiever te maken. Daarbij is het uitgangspunt dat missie-visie-strategie antwoord geven op de volgende vragen:

  • Hoe zorg je dat besluiten en dagelijkse activiteiten van alle deelnemers bijdragen aan de missie?
  • Hoe blijf je op koers in een dynamische wereld waarin inzichten evolueren en omstandigheden steeds weer anders zijn dan gedacht?

Twee vragen waaruit het eeuwige dilemma blijkt: vasthouden aan het plan om de missie te realiseren en tegelijkertijd flexibel zijn om om te kunnen gaan met de onzekerheden van het bestaan.

Omgaan met onzekerheid

Onzekerheden zijn inherent aan het ondernemen. Deels zit hem dat in de beperkte voorspelbaarheid van externe factoren als de overheid, de consument en de concurrent. Deels worden de onzekerheden veroorzaakt door de aannames en uitgangspunten die de onderneming zelf definieert. Denk hierbij aan de beschikbaarheid van technologie, de omvang van de vraag naar het product of service, de verwachte economische ontwikkelingen of de stabiliteit van de arbeidsmarkt.

De missie van Tesla is bijvoorbeeld als volgt geformuleerd: “to accelerate the advent of sustainable transport by bringing compelling mass market electric cars to market as soon as possible” (Tesla, 2014). Tesla formuleerde deze missie in een tijd dat nog uiterst onzeker was of er voldoende krachtige stroombronnen ter beschikking zouden komen en de scepsis over de haalbaarheid voor een nieuwkomer in de autoindustrie behoorlijk hoog was.

In dit soort omstandigheden helpt het als een gedreven iemand met een bord voor z’n kop de leiding (en de risico’s) neemt, en een verhaal weet te creëren waar anderen op intekenen omdat het aanspreekt en nog waar zou kunnen zijn ook. In vakjargon is dat een ondernemer met een visie.

Visie definieer ik hiermee als de set overtuigingen ten aanzien van zowel maatschappelijke, economische en marktmechanismen, als van product en organisatie zelf.

Tesla: a) accu’s met voldoende vermogen zijn binnen afzienbare tijd beschikbaar of te ontwikkelen, en b) de reguliere automakers zijn niet in staat een dergelijke missie op te pakken. Consequentie van dat laatste punt is dat Tesla in 2014 haar patenten gratis ter beschikking stelt als onderdeel van de strategie. Dit opdat andere autofabrikanten helpen de missie van Tesla te realiseren!

In de visie van Apple kun je de kwaliteit alleen borgen als je de hele keten beheerst. Deze visie leidde tot computerkasten die de consument niet kan openen en een app-store waar niets inkomt wat niet eerst door Apple zelf getest en beoordeeld is.

Dit begrip van visie dient los gezien te worden van een visioen op hoe de wereld eruit ziet als de missie gerealiseerd wordt. Hoewel redelijk wat managementliteratuur dat onder de visie verstaat (in de engelse taal wordt vision gebruikt voor zowel visie als visioen), vind ik dat het visioen toelichting bij de missie is. Niet onbelangrijk maar irrelevant voor het beantwoorden van de eerder gestelde vragen.

Een visie is alleen nuttig als deze gedeeld, gedragen en onderhouden wordt. Delen en draagvlak creëren, je stakeholders verleiden om de wereld op dezelfde manier te zien en te leren hoe zij het zien is dus allemaal onderdeel van het vormingsproces. Dit is overigens een continu proces. De ontwikkeling van inzichten laat zich lastig binden aan tijdsbeperkingen. Dit proces sturen en beheersen associeer ik met goed leiderschap.

Het creëren en onderhouden van een gedeelde visie is het antwoord op de tweede vraag:

Hoe blijf je op koers in een dynamische wereld waarin inzichten evolueren en omstandigheden steeds weer anders zijn dan gedacht?

In feite vormt de visie het kader voor het contract dat de organisatie sluit met alle stakeholders. Dit contract is het antwoord op de eerste gestelde vraag:

Hoe zorg je dat plannen en activiteiten van iedereen bijdragen aan de missie?

Het contract van/met de onderneming

Als met goed leiderschap de stakeholders ‘gewonnen’ zijn voor de visie, is het zaak ze te ‘binden’. Dit betekent missie en visie vertalen naar een strategie. Ik definieer hierbij strategie dus als het (virtuele) contract met zowel omgeving als de organisatie-onderdelen.

Dit contract is het stabiele kader dat alle stakeholders houvast biedt om in een complexe, dynamische omgeving gecoördineerd aan de afgesproken doelen te werken. Kaders voor plannen en besluiten zonder de effectieve inzet van middelen en competenties te belemmeren. De ideale strategie, kortom, creëert dus focus en richt de inzet van competenties zonder deze te belemmeren.

In de bestuurlijke context is deze functie gerealiseerd door middel van een stelsel van wetten en regels waarbinnen de maatschappij zich dient te bewegen. Het denken in dit soort constructen, wat het typische denkpatroon van juristen is, lijkt een heel goed handvat te zijn om een strategie vorm te geven. Het is erop gericht gedrag te sturen zonder een harnas te creëren van deadlines en planningen. Een mooi voorbeeld waarin een strategisch uitgangspunt ook daadwerkelijk een wet genoemd wordt, is de wet van Moore van voormalig Intel CEO Thomas Moore.

Thomas Moore heeft in 1965 als ‘wet’ geformuleerd dat elk jaar de capaciteit van chips in termen van het aantal schakelingen verdubbeld wordt. Na tien jaar is de wet aangepast naar elke 2 jaar. In zijn visie was dit a) wat zijn klanten nodig hadden, b) gezien beschikbare competenties mogelijk voor Intel, c)  gezien de positie van Intel mogelijk om dit in de markt af te dwingen  en d) technisch mogelijk. Deze wet heeft een grote impact gehad op het denken en doen van Intel, en haar concurrenten! Onlangs is een onderzoek gepubliceerd waaruit blijkt dat de grote werkdruk bij Intel verklaard moet worden door de stress omdat de ‘wet’ met de huidige stand van de techniek (sinds 2011) niet meer haalbaar blijkt.

Een strategie heeft geen specifieke geldigheidsduur. Het contract is voor onbepaalde tijd. Dat wil niet zeggen dat hij niet wijzigt. Nieuwe inzichten (visie), onbedoelde neven effecten of omissies vereisen dat een contract aangepast of aangevuld wordt. De frequentie van wijzigingen hangt af van de dynamiek in de omgeving en de ontwikkeling van de visie hierop. Als regel geldt hierbij: zo min mogelijk & zo vaak als nodig.

Strategie gedefinieerd als kader heeft als consequentie dat je strategie niet los kunt zien van de organisatiecultuur. De strategie heeft immers tot doel de kaders te zetten en beïnvloed daarmee het gedrag.

Denk aan de impact op het gedrag bij Intel. Het realiseren van de twee-jaarscyclus heeft impact op designkeuzes, prioritering, wie bij welke besluiten betrokken wordt, bij welke afdeling je de beste carrièrekansen hebtb en hoe beslissingen gemotiveerd worden.

Dit betekent dat de vereiste cultuuraspecten onderdeel zijn van de visie, die meegewogen worden bij het creëren van de strategie.

Twee antwoorden, één oplossing: leiderschap

De antwoorden op de twee in het begin gestelde vragen zullen inmiddels duidelijk zijn. Coördinatie van activiteiten vereist een contract, omgaan met onzekerheden als gevolg van complexiteit en dynamiek, realiseer je door het onderhouden van een gedeelde visie op de werkelijkheid.

Je wint mensen met een visie, je bindt ze met een strategie.

Voor het ‘winnen’ van je stakeholders is leiderschap nodig: het vermogen om een gedeeld, motiverende visie te creëren in een omgeving met veel onzekerheden en diverse belangen en overtuigingen. Het binden is meer een typische managementfunctie.

Veranderingen in een organisatie vinden meestal hun oorsprong in veranderingen in de visie. Op basis van de beschrijving van de cultuurdimensie in het vorige artikel en de essentie van strategie in dit artikel zal het laatste deel van dit drieluik inzoomen op het ontwikkelen van organisaties.

Het cultuur-ding

Geplaatst op door erik

Bij vrijwel elk verandertraject wordt wel gewag gemaakt van de noodzaak ook de cultuur te veranderen. Vaak is het een reactie op het niet naar verwachting lopen van de verandering. Cultuur is vaak wel in naam onderdeel van de verandering maar meestal ook niet meer dan dat. Het wordt tijd het cultuuraspect een integrale, concrete plek te geven in de ontwikkeling van de organisatie. Te beginnen in dit artikel met een nadere beschouwing van wat cultuur dan is.

Dit artikel is deel van een drieluik over organisatie ontwikkeling. Het tweede deel behandelt de essentie van strategievorming. Het derde behandelt het ontwikkelen van een effectieve veranderaanpak.

Het begrip

Het halve werk om tot antwoorden te komen is een goede, praktische definitie van cultuur. De meest tot de verbeelding sprekende definitie, mede omdat deze meteen praktische handvatten biedt, komt van Edgar Schein (Organizational culture and Leadership, 5th edition, 2017):

“The culture of a group can be defined as the accumulated shared learning of that group as it solves its problems of external adaptation and internal integration ….This accumulated learning is a pattern or system of beliefs, values, and behavioural norms that come to be taken for granted as basic assumptions and eventually drop out of awareness.”Doortrekken van deze gedachtelijn heeft een aantal consequenties die bepalend zijn bij het vorm geven en realiseren van veranderingen.

Deze definitie is praktisch doordat het de nadruk legt op precies die situaties waarbij overtuigingen, gedrag en waarden een bovengemiddelde rol speelt: complexe vraagstukken die geen eenduidig of beste antwoord kennen. 

Op basis van deze definitie kunnen een aantal conclusies getrokken worden over wat cultuur dan precies is. Deze volgen hieronder.

Cultuur is een emergente eigenschap

Aangezien cultuur de opeenstapeling van leerervaringen van het collectief is (accumulated shared learning) betekent dat geen van de onderdelen, leden van de organisatie, geïdentificeerd kan worden met de cultuur. Het collectief, bestaande uit haar leden, haar hulpmiddelen en de samenhang daartussen, heeft de eigenschap  De eigenschap ontstaat uit de samenhang, de relaties tussen de onderdelen van het systeem. Het is daarmee een emergente eigenschap

Een eenvoudig voorbeeld van een emergente eigenschap is het vriespunt van water. Deze is 0º C terwijl het vriespunt van elke van de componenten (waterstof en zuurstof) onder de -180º C zit.

De consequentie hiervan is dat de cultuur niet af te leiden is door analyse van eigenschappen van individuele leden van de organisatie. Niemand bezit de cultuur.

Cultuur is een best practice

Een cultuur evolueert en volgt daarbij een Darwinistische wetmatigheid. Dat wat succesvol is wordt versterkt, dat wat minder succesvol is, verdwijnt weer snel. Net zoals bij het leven op aarde bepaalt niet het object zijn succes maar de omgeving. Dat wil dus zeggen dat de maatschappelijke, economische en technologische context van een organisatie bepaalt wat een succesvolle cultuur is.

Cultuur is organisch

De cultuur van een organisatie groeit, verbreed en verdiept zich in de loop der jaren. Een jonge organisatie heeft nog geen eigen cultuur: het leren is nog maar net begonnen. De cultuur groeit bij elk complex probleem dat overwonnen wordt en verbreed zich met het toenemen van het aantal leden van de groep.

In de loop der tijd, met het groeien van de organisatie wordt de cultuur steeds verfijnder en worden ook subculturen zichtbaar. De cultuur wordt dan ook steeds lastiger te omschrijven en te bevatten.

Cultuur is als een boom: eerst jong en buigzaam en zich voegend naar de omstandigheden maar in de loop der jaren steeds steviger, dominant in zijn omgeving en minder buigzaam.

De cultuur wordt door de groei van het aantal leden immuun voor veranderingen in of buiten de organisatie, zoals haar structuur, het aantal leden of het vertrekken of binnen komen van individuele leden.

Een implicatie daarvan is dat de als de context verandert, de heersende cultuur van een succesfactor ineens kan veranderen in een probleem. Om de cultuur te veranderen zijn dan grote krachten nodig, zoals een groot aantal nieuwe leden of een sterke druk van de omgeving.

Cultuur is niet te beschrijven

Cultuur is een complex samenstel, een black box van overtuigingen, waarden en gedragsnormen die zich in het onderbewuste van de organisatie bevindt. Dit betekent dat een cultuur niet eenduidig te beschrijven is. Een cultuur wordt dan ook beschreven aan de hand van algemeen erkende en herkende patronen. 

Zo’n analyse biedt geen inzicht in wat de impact is van de cultuurcomponenten op het resultaat en geeft beperkte handvatten voor wat er moet veranderen om complexe vraagstukken anders op te pakken.

Interventies gericht op cultuurverandering zijn omgeven met veel onzekerheid omtrent wat er precies verandert en wat het resultaat is. Dit soort interventies zijn dan ook niet realistisch.

Conclusies

Cultuur is een emergente eigenschap van een organisatie, die zich continu ontwikkelt onder invloed van hoe zij complexe vraagstukken aanpakt en hoe succesvol zij daarin is in de ogen van haar omgeving. Het is een een impliciet trial & error proces terwijl de organisatie werkt aan haar doelstellingen.

De effecten van cultuur zijn het best zichtbaar bij het aanpakken van complexe vraagstukken. Omdat deze vraagstukken alles te maken hebben met kiezen, besluiten onder onzekerheid, spelen overtuigingen, normen en waarden een significante rol. Keuzes en besluiten zijn identificeerbaar, de totstandkoming is te achterhalen en de effecten ervan kunnen beoordeeld worden. Wil je inzicht in de heersende cultuur? Volg de besluitvorming!

Een jonge cultuur reflecteert sterk met haar omgeving en past zich aan aan de omstandigheden. Met het groeien van de cultuur wordt deze steeds meer een dominante, op zichzelf staande factor. Hierdoor kunnen veranderingen in de omgeving de heersende cultuur veranderen van een succes- in een probleemfactor.

Als blijkt dat een organisatie niet langer op haar reflexen kan vertrouwen bij het aanpakken van complexe vraagstukken, is het tijd om de component cultuur in de organisatie ontwikkeling te betrekken. Niet om te focussen op cultuurverandering maar om expliciet te maken wat de beoogde effecten van veranderingen dienen te zijn. Alleen dan kan een integrale strategie en veranderaanpak (cultuur en structuur) geformuleerd worden.

Echt agile?

Geplaatst op door erik

Voor betere, en vooral emotionele binding met alle stakeholders, snellere besluitvorming en meer rendement uit het beschikbare talent is meer nodig dan het kopiëren van een proces of organisatiestructuur van lichtende voorbeelden als Spotify. Het succes van deze voorbeelden is niet zozeer gebaseerd op een slim proces maar op een goed business model, hun governance structuur en hun wijze van talentontwikkeling. Ervan uitgaan dat deze factoren vanzelf goed komen met een nieuw agile proces blijkt een slechte strategie voor daadwerkelijke transformatie.

Processen zijn het middel om gegeven de omstandigheden en beschikbare middelen gewenste resultaten op een effectieve en beheerste (voorspelbare) manier te bereiken. Software ontwikkelen voor een streaming dienst kent een andere dynamiek dan software ontwikkelen voor een tandenborstel met gecombineerde software/hardware. Beschikbaarheid van kennis van de omgeving, ontwikkelplatforms, benodigde samenwerking met leveranciers, toegang tot experience panels en voldoende vermogen bepalen ondermeer hoe producten ontwikkeld worden. Daarop worden de processen geënt.

Een proces aanpassen is een goede stap zijn als dat gebeurt met het doel onderliggende factoren te verbeteren. De introductie van LEAN is hier een goed voorbeeld van. Het proces dwingt focus af en organiseert feedback op de performance. Een LEAN implementatie heeft dus tot doel verbetering in organisatie, competenties of attitude. De focus ligt daarbij vooral op objectief meetbare aspecten als  conformance-to-specs of fitness-for-use. Hoewel de claim anders is, zijn de huidige agile initiatieven nog vooral gebaseerd op dit uitgangspunt.

Een echt agile organisatie dient zijn focus te hebben op customer delight en, waarschijnlijker, all-stakeholder delight. Dit is vooralsnog veel minder meetbaar. Het implementeren van een proces gericht op feedback krijgen op meetbare performance criteria volstaat niet meer. Sensitiviteit voor de omgeving, snel besluiten en snel leren zijn bij deze onzekerheden belangrijke competenties. Het fundament hiervoor zijn investeringen in talent, een adequate governance structuur en een op toegevoegde waarde gericht business model. Dit is wat de echt agile organisaties als Spotify en Netflix onderscheid. Het proces is secundair.

Hun business model is geënt op het leveren van toegevoegde waarde aan gebruiker of zelfs maatschappij. Niet op het maximaliseren van winst. Dat dit de gemiddelde investeringsfonds niet meer afschrikt blijkt wel uit de grote sommen geld die ze desondanks bereid zijn te investeren. Er lijkt veel vertrouwen te zijn dat dat wat waarde toevoegt op termijn zelf van waarde wordt.

Een agile governance structuur is zodanig dat besluiten genomen worden door de personen of teams die daarvoor het beste toegerust zijn met inachtname van alle facetten. Een projectteam dat inhoudelijke keuzes maakt die later door het management financieel beoordeeld worden betekent dat veel tijd verloren gaat en de uiteindelijke besluitvorming door mensen gebeurt die hier minder goed voor ge-equipeerd zijn. Dat past niet in een agile organisatie.

Tevens dient borgt een agile governance structuur kort-cyclische feedback om het leerproces te optimaliseren. Zo stimuleert de governance structuur doelgerichtheid en creativiteit. Dit vereist qua talentontwikkeling veel aandacht voor welke expertise iemand heeft en ontwikkelt, en hoe effectief hij deze inzet in teamverband. Het gaat dus om expertise en impact als persoon om het verschil te maken.

Voor een bestaande organisatie is een dergelijke transformatie een investering die verder gaat dan het inhuren van coaches. Aan de transformatie is een learning curve verbonden. Organisaties die deze transformatie doorgemaakt hebben laten zien dat er misverstanden of problemen met de levering van hun producten of diensten kunnen ontstaan. Hier helpt alleen een goed transformatie plan, waarin de learning curve beheerst wordt, en doorzettingsvermogen tegen.

De architect rol in digital transformation

Geplaatst op door erik

Digitale transformatie en innovatie vereisen veranderingen van zowat alle aspecten van een organisatie. De relatie met klanten en de product keten waarvan ze onderdeel zijn verandert, de noodzakelijke competenties moeten geherwaardeerd worden en men moet de manier van samenwerken opnieuw ontdekken. Enterprise en business architecten dienen in deze dynamische context een centrale rol te spelen.

De meeste organisaties hebben inmiddels ingezet op een agile manier van werken als basis voor de vereiste transformatie. En dat is een goede zaak!. De precieze rol van met name enterprise en business architecten in dit agile proces en de transformatie blijkt echter nog de nodige vragen op te roepen bij zowel het management als de architecten zelf. In de zoektocht naar antwoorden hierop is het goed eerst een gedeeld beeld te creëren van het soort problemen waarover architecten zich buigen, wat unieke architect competenties zijn en hun positie in de organisatie.

Ten eerste het soort problemen waarop architecten zich focussen. Om die te bepalen is onderstaande matrix behulpzaam. Hierin zijn de helderheid van het probleem afgezet tegen de mogelijke oplossingen.

In de praktijk zie ik architecten focussen op een of meer kwadranten. Echter, als de oplossing of het probleem helder is hebben ze hooguit een ondersteunende rol. Specialisten in een bepaalde oplossing of probleemdomein, zoals data analisten, ontwerpers of verandermanagers hebben in de praktijk de leiding. Architecten nemen in dit soort situaties vaak een kwaliteitszorg rol. Hun focus is vaak de zorg dat de uiteindelijke oplossing in lijn is met ieders belangen.

Echter, als het probleem en de mogelijke oplossingen niet helder of zelfs vaag zijn, komen de architecten goed tot hun recht. Deze situatie vereist zowel een hoge mate van conceptueel denken als begrip van IT en business en het hebben van adviesvaardigheden. Eigenschappen die meestal toegekend worden aan architecten.

Gelet op competenties zie ik veel aandacht voor modelering en bijbehorende tools. Dit is zeker een noodzakelijk aspect maar volgens mij niet de sleutel tot succes. Een grondige analyse, gedeelde toekomstbeelden creëren en zorgen voor door alle stakeholders gedragen besluiten wel. Wederzijds begrip en vertrouwen zijn randvoorwaardelijk om een rol te hebben in dit spel. Business zowel als IT kennis zijn noodzakelijk om als volwaardig partner te kunnen acteren. De belangrijkste competentie is echter design thinking zoals gedefinieerd door D.school: Institute of Design at Stanford.

Empathize, define en ideate zijn de eerste drie stappen van design thinking en hebben tot doel op basis van gedeeld begrip tot hanteerbare probleemstellingen te komen en ideeën voor oplossingen te genereren. De benodigde vaardigheden op deze gebieden zijn het ontwikkelen van relaties, het leiden van een denk- en besluitvormingsproces om problemen te verduidelijken en om een gezamenlijk beeld te creëren van oplossingen met een grote groep van diverse stakeholders.

Inherent aan de aard van het hierboven geschetste probleemdomein is een leerproces. De organisatie ontwikkelt een beter begrip van de problematiek. De architect ontwikkelt een beter begrip van de oplossingsruimte. Een korte feedback cyclus is daarbij essentieel om controle te houden over de ontwikkelingen en de daarbij horende kosten. De design thinking stappen die hierop focussen zijn prototype, test en rol uit.

Het belang van dit leerproces en de rol zoals geschetst pleiten ervoor de architecten de verantwoordelijkheid te geven voor zowel de architectuurkeuzes als de realisatie ervan. Daarmee wordt geborgd dat de feedback terugkomt bij degene die de keuzes maakt.  Nog belangrijker is dat de architect ten opzicht van het management in een juiste positie komt om eisen te stellen. Er is op deze manier geen vrijblijvendheid. Management en architecten zullen er samen uit moeten komen om de digitale transformatie een succes te maken.

Valuation of ideas in an agile context (eng)

Geplaatst op door erik

Most organisations struggle with the way to choose and prioritise ideas for software development. Effective communication, sharing of convictions and a strong focus on learning will help to be innovative without loosing control. Most software development organisations have an agile process in place. To improve effectiveness they should invest in design thinking.

Questions asked frequently to me and my colleagues are: how do I determine a feature has value? How do you determine something has value to the business? How do you measure it? The reason for asking most of the time is a personal wish to improve something.

In many agile handbooks they say the product owner should decide. To support the decision making a lot of rule sets and formulas are available which try to objectify business value. But I think the answer isn’t that trivial.

What I notice is that the more effort one puts in grabbing the value the harder it gets to grab it.

I think the main reason for this is the role of uncertainty. Checklists, rules and formulas typically don’t take into account that not all is clear, that you don’t know all the parameters or not everyone agrees on the parameter values. It is easy to say “if this then that”, but if you don’t know if ‘this’ applies you still don’t know what to do or decide. The only way out is to act on estimates, convictions or believes.

For a startup this is easy.  You have a great idea and are you are convinced people are waiting for this. You are prepared to work night-and-day to prove you are right. You have a vision and are totally committed to realizing it. Finally you either come to the conclusion it doesn’t work, you run out of money or you end up as CEO of a highly valued company:-)

The problem with large organizations is that in order to be effective not only a lot of persons have to share the convictions and believes but they also have to commit themselves to proving them as well. Complicating factor is they have a responsibility to a large number of shareholders regarding the going concern as well.

This brings me back to the questions asked.

In virtual all cases the real problem is they don’t know, understand or share the convictions or believes. They perceive the organization as indecisive or even fickle. This obviously has impact on the commitment of the ones involved as well. Who wants to work night-and-day for realising ideas they don’t really believe in?

So what to do?

The essence is: you have to invest in understanding your clients as well as each other, generate ideas and select and commit to ideas. These ideas are based on assumptions that represent risks for the company. Managing these risks requires an approach concentrated on validation of assumptions in economically the best order.

The solution is twofold. Use the design thinking concept for creating shared believes in order to focus and create commitment. Then, use your agile development proces as it is meant: fail fast, learn fast. For me the conclusion is that there are good practices to determine the value of ideas but from a development perspective the nr. 1 criterium should be: what is now the most important thing to learn.

I like to elaborate on this aspects in future blogs. Please feel free to react with opinions and ideas to support this process.

About using models (eng)

Geplaatst op door erik

During my career I have seen come and go a lot of models aimed at improving the performance of IT. CMMi, Prince2, Scrum, SAFe, to name a few. What strikes me more and more is the huge differences in effect these models have, even between teams of the same organisation. Some teams are enlightened and show a huge boost in performance, while other teams successfully adopt new terminology and rituals but don’t show any real improvement.

Looking at all the cases I identified some aspects of models and the implementation of changes in general that influence the rate of adoption.

First the models. I think it is important to realise that models are not inventions, laws or recipes for improvement. They also don’t describe things that weren’t there before. Models are a visualisation of best practices, experiences and visions of a community: good ideas get a name. They provide a language to share this, regardless of organisation or country borders. One should realise that in general there is no scientific or statistical evidence. To speak with Edward Deming: “all models are wrong! Some are useful”.

All models are abstractions. This means aspects of reality are left out of the visualisation with the assumption they are stable or are irrelevant for the purpose of the model: a certain improvement. Question is whether this is true. In my experience a lot more aspects play a role, then visualised in the model.

Besides that, models have a number of assumptions. Adherence to these underlying assumptions determines whether the model is used effectively. So lets elaborate on these assumptions.

The first assumption is that anyone fully understands the model, mostly after a training. Just looking at the eternal discussions on the definition of requirements, makes this a weird one. Terminology and abstractions get meaning by using them. Sharing thoughts with each other is the most effective way to create this meaning. By definition, this makes it team, tribe or organisation specific.

Another assumption is that level of maturity of all involved has no influence on the ability to change processes using the model. This is a strange one too. I think this can be explained best by relating this to the third assumption.

The third and most striking assumption is that implementing a new way of working changes behaviour, which will finally lead to changing believes: the prerequisite for effective change. Changing of believes however is a slow process and depends on more then what is defined in the models. I already mentioned the abstractions and the level of maturity.

A beautiful illustration of the importance of believes is the agile manifesto. In a number of statements it makes clear what the believes should be. I think they are very appealing. However, there aren’t much organisations who make these beliefs the cornerstone of change, for example while implementing a scrum way of working. Discussing beliefs I think would be a beneficial shortcut to improvements.

Improving performance includes many factors which makes it complex. Consultants and managers alike, endorse the statement that it is all about people, their believes, their culture. Given what I stated above I suggest to give the improvement process back to these people. Don’t tell them we are gone use this model or framework. Ask them how using the model can help improve their performance. It creates more empathy, better communication, room for experimentation and prototyping. Leadership required!

LEAN wordt agile

Geplaatst op door erik

Een van het meest voorkomende en begrijpelijke misverstand is dat lean alleen geschikt is voor fabricage of routine situaties, met een zich steeds herhalende procedure en een sterke nadruk op de reductie van variatie ofwel verspilling. Volgens mij kan dit misverstand goeddeels opgelost worden door lean in de context te plaatsen van wat organisaties nu bezig houdt, speciaal gelet op de risico’s die ze lopen.

Altijd als ik betrokken ben bij lean implementaties in de afgelopen jaren is de meest opvallende en vaak te horen opmerking dat lean is bedoeld voor herhaalde, sterk gestandaardiseerde processen en daarom niet geschikt is voor ontwikkeling of projecten. Een van de argumenten is dat alle bekende en uitgewerkte voorbeelden uit fabricage omgevingen komen, te beginnen met Toyota. Een ander argument is de sterke focus op reductie van verspilling in procedures. Een derde argument is dat lean slechts een toolbox is voor management om variatie en dus kosten te reduceren.

Inderdaad, de lean filosofie is ontwikkeld in massa productie omgevingen als antwoord op de vraag hoe de kwaliteit, zijnde fitness-for-use, te borgen in een situatie dat de concurrentie positie werd bepaald door de mate van efficiency: het realiseren van economies-of-scale door grote markten te bedienen met goede producten tegen lage kosten.

Essentieel voor het borgen van kwaliteit in die situatie was het begrijpen van de klant, het product en het proces volgens welke dat product tot stand komt. Gezien het belang van efficiency is het niet vreemd dat de nadruk ligt op reductie van variatie in de processen. En variatie is het resultaat van risico’s die men loopt: gebeurtenissen waarvan niet duidelijk of en wanneer ze optreden. Dus iedereen zoekt naar de mogelijkheden om deze risico’s te elimineren. Dat kan gaan over risico’s met de kwaliteit van input materialen, de risico’s van slecht geëquipeerde medewerkers, de risico’s van onbekende procedures of de risico’s van geen begrip van ‘de klant’. De eerder genoemde argumenten waarom lean niet geschikt is komen door deze associatie met efficiency.

Nu leven we in een tijd dat het leveren van hoge kwaliteit op een voorspelbare manier gewoon is. Gelet op concurrentie positie staat vandaag de dag de relatie met de klant, gebruikers en allerlei andere stakeholders centraal. Om concurrerend te zijn moeten organisaties niet alleen focussen op het steeds sneller vernieuwen van hun producten maar tevens op het herdefiniëren van haar producten en services. Dit betekent onder meer het nauw betrekken van gebruikers bij de ontwikkeling en het volop ruimte geven aan creativiteit. Met deze eisen worden de bronnen variatie midden in het development proces, het kritieke pad, geplaatst. En de grote vraag is weer hoe kwaliteit, tijdigheid en kosten in bedwang te houden.

In standaard procedures wil je risico’s vermijden of elimineren. In een ontwikkelomgeving moet je deze risico’s echter omarmen. No guts, no glory, klinkt dat in goed Engels. De vervolgvraag is dan ook hoe de gevolgen van risico’s tijdens ontwikkeling of projecten te minimaliseren. Dat betekent onder meer het verbeteren van de identificatie en kwalificatie van risico’s, het schatten van de impact, het bepalen hoeveel risico je kunt nemen en het definiëren van een ontwikkelproces op zo’n manier dat de grootste risico’s met de meest impact als eerste getackeld worden en risico’s in hun algemeenheid zo snel mogelijk geëlimineerd worden. Het spel is nu beheersen van risico’s, niet het voorkomen ervan.

Voor software ontwikkeling zijn diverse agile raamwerken beschikbaar om dit te tackelen. Verrassend genoeg zijn deze gebaseerd op lean gedachtengoed. Ik ben ervan overtuigd dat er geen fundamentele reden is dat lean niet werkt in een ontwikkel- of projectomgeving. Haar schaalbaarheid over disciplines en zelfs over organisatiegrenzen zijn zelfs grote pluspunten. Het betekent wel dat de toepassing afgestemd moet worden op de huidige focus en risico attitude. Daarover is nog veel te leren. Laten we starten met het verzamelen van verhalen in deze context.

Wat innovatie afremt

Geplaatst op door erik

Veel managers die ik spreek zitten met de vraag hoe innovatie van organisatie en product vorm te geven met een steeds kleiner budget. Mijn standaard vraag is: Wat vinden je medewerkers of collega’s ervan? Het antwoord varieert van “Hoezo?”, “Ik weet het niet” of zelfs (en vaker)  “Zij snappen er niks van!”.

Onze collega’s zijn net zo hoog opgeleid als wij, vol energie, staan midden in het leven en zijn beter geïnformeerd over wat er in de wereld gebeurt dan ooit! Hoe bestaat het dat mensen zoals wij niet zouden begrijpen wat het probleem is en hoe ze kunnen helpen?

Mijn beeld? Omdat we gewend zijn aan principes die maken dat we niets anders kunnen bedenken dan ze gevangen te houden in een command&control structuur die allang niet meer past bij de huidige situatie en de aanwezige competenties.

Laat me een voorbeeld geven hoe twee teams het verschil maakten door ze meer vrijheid te geven  zelf hun omgeving en onderlinge afspraken vorm te geven.

Gedurende een aantal evaluaties kwam steeds hetzelfde problem boven water: twee teams werkten niet effectief samen met als consequentie achterblijvende kwaliteit van het gerealiseerde services en de noodzaak over te werken om deadlines te halen. Elke evaluatie gaf de verantwoordelijke manager aan de situatie op te zullen lossen. Niets leek echter te werken.

Tot de manager besloot eens met de teams om tafel te gaan en hen te vragen wat er nou precies aan de hand was. Binnen 10 minuten was duidelijk dat het probleem was dat een van de teams beschikte over de resources die ook het andere team nodig heeft. Het team dat de resources niet had, kreeg het niet voor elkaar tijdig resources ter beschikking te krijgen om hun werk goed te doen. Op verschillende manieren was dit al aangegeven maar het management herkende het niet als de grondoorzaak van het probleem. Eerder genomen maatregelen lagen op het vlak van meer rigoureuze planning en rapportages.

De discussie spitste zich vervolgens toe op twee mogelijke oplossingen. Of het eigenaarschap van de resources werd verdeeld of het team met de resources kreeg ook de verantwoordelijkheid voor het halen van de planning van het andere team. Gekozen werd voor het laatste: het team met de resources kreeg de verantwoordelijkheid voor het halen van de planning van het andere team.

Het effect? Het samenwerkingsprobleem was opgelost en na zes maanden bleek dat naast goede kwaliteit er een grote efficiency verbetering gerealiseerd was.

Ik heb een interessante oefening om je eigen rol in dit soort zaken te illustreren, die ik iedereen kan aanbevelen.

We weten allemaal dat in een auto je gas moet geven om sneller te gaan. We weten ook dat om ongelukken te voorkomen (stoppen voor rood) of om in control te blijven (niet te snel door een scherpe bocht) we moeten remmen.

De oefening is: schrijf een aantal specifieke maatregelen op die je genomen of ervaren hebt en stel je collega’s of medewerkers de volgende vraag: is dit gas geven of remmen? versnelt de maatregel of dient hij om in control te blijven?

Ik ben ervan overtuigd dat de meeste maatregelen betrekking hebben op in control blijven of risicovolle situaties te beheersen. Ik weet dat het lastig is, maar het is waardevol de ‘rem-‘acties te bespreken met je collega’s en medewerkers om te kijken hoe deze om te vormen in ‘gas-‘maatregelen. Ik kan je vertellen dat dit veel meer oplevert dan een book lezen over de volgende management-hype of beheersmodel.

Begrip van agile

Geplaatst op door erik

Ik heb inmiddels een behoorlijk aantal verandertrajecten om een agile informatievoorziening te realiseren gezien en ondersteund. Tijd om de op de ervaringen gebaseerde visie te delen dat agile worden hard werken is voor. …management.

Geheel in agile stijl is het volgens my belangrijk te beginnen met wat agile werken op zou moeten leveren. In het algemeen zijn de doelen van de agile transformatie:

  • meer creativiteit: effectiever gebruik maken van de beschikbare denkkracht, intelligentie en ideeën;
  • meer flexibiliteit: in staat zijn snel in te spelen op externe omstandigheden en veelbelovende nieuwe ideeën;
  • meer controle: in staat zijn te voorspellen, beter begrip van onzekerheden etc.

Het is van belang je hierbij te realiseren dat dit geen zero-sum game is. De vraag is dus niet hoeveel creativiteit offeren we op voor meer controle. De vraag is hoe verbeteren we en de controle en de creativiteit en de beheersbaarheid!

Gebaseerd op de hierboven genoemde doelen en het bewustzijn dat het geen zero-sum game kan zijn bij implementatie van frameworks als scrum, devops of het scaled agile framework zie ik een aantal steeds terugkerende thema’s. Veel voorkomende vraagstukken zijn: hoe houden we zicht op de lange termijn doelen? Hoe decomponeren we producten en houden zicht op de waarde die elk onderdeel creëert? Wanneer zijn specificaties voldoende om mee te starten? Hoe schatten en plannen we?

Voor de meeste vragen bestaan goede instrumenten en processen die ook daadwerkelijk gebruikt worden. Concepten als ‘Definitions of ready’ en ‘done’ (DoR, DoD), backlog management of het sprint-proces zijn goed ingeburgerd. De instrumenten zijn eenvoudig toe te passen. De uitdaging is echter hoe van gebruik van deze instrumenten te komen tot realisatie van de gestelde doelen. Dat kan alleen door de instrumenten te gebruiken en ervan te leren. Leren hoe in de specifieke situatie, met de marktdynamiek en de eigen propositie de instrumenten het best gebruikt kunnen worden.  In feite betekent de implementatie van een agile framework de introductie van een aantal gebieden waarop de organisatie begint te leren.

Complicerende factoren zijn echter dat de leergebieden met elkaar verbonden zijn en dat per leergebied meerdere disciplines te leren hebben. Bijvoorbeeld, leren schatten is lastig als er geen DoD of DoR is en zal met het team, IT management en business opgepakt dienen te worden. Een retrospective als er geen goede DoD is leidt al snel tot generieke opmerkingen die in de praktijk niet opgepakt worden. Als er geen door alle disciplines gedeeld beeld is van waarde beperkt dit de effectiviteit van backlog management.

Dus, een effectieve implementatie van agile vereist vooral aandacht voor hoe de organisatie leert op meerdere gebieden tegelijkertijd. En op een manier dat èn de creativiteit, èn de flexibiliteit èn de controle toeneemt! In een specifiek operating model dat de organisatie heeft of wil hebben.

Dit is al met al een lastig vraagstuk dat niet zomaar te vangen is in wat algemene hints, een model of framework. Dit maakt een transformatie naar agile werken een maatwerk traject waarbij de genoemde instrumenten zeker helpen om kader te geven. Het blijft echter in hoge mate maatwerk waarbij succes afhangt van een gedragen visie en hoe het leren gefaciliteerd wordt door de governance structuur, het leiderschapsmodel, het gedrag en attitude van alle betrokkenen, de aanwezige competenties en de beschikbare technologie. En aangezien wijsheid geen standaardsituatie is zal op deze vlakken ook genoeg te leren vallen: double loops learning volgens Argyris. Kortom betekent het veel werk en creativiteit van het management om een vruchtbare bodem te creëren voor de transformatie.