De pijn van groei
De wereld wordt nog elke dag complexer, en dat geldt ook voor de meeste van onze organisaties. Dat is begrijpelijk. We komen nieuwe uitzonderingen op onze regels tegen, dus hebben we nieuwe regels nodig. Als gevolg daarvan wordt onze besturing steeds strenger en gedetailleerder.
We brengen nieuwe producten op de markt om aan de groeiende behoeften van onze klanten te voldoen en we voegen meer variaties toe. Om dit in goede banen te leiden, creëren we meer bedrijfsafdelingen. We krijgen nieuwe, grotere en andere klanten, dus hebben we meer verkopers nodig.
De markt verandert, dus hebben we nieuwe marketing mensen nodig. We hebben nu zoveel marketing en sales mensen - laten we er een afdeling van maken. Ze hebben het zo druk met onze huidige producten en klanten, laten we een nieuwe afdeling oprichten die zich vooral richt op nieuwe producten.
Technologie ontwikkelt en verandert, dus we moeten ervoor zorgen dat we de vaardigheden en competenties aan boord hebben. Laten we nieuwe mensen aannemen. Nu we zoveel competenties hebben, moeten we meer afstemmen en de normen bewaken.
Laten we afdelingen vormen rond die technische competenties en managers die senior zijn op dit gebied. Voor je het weet, kijk je in de spiegel en denk je: Verdomme, wat is er gebeurd met het mooie, kleine, flexibele en snelle bedrijfje dat we ooit waren....
Versimpelen is de oplossing
Als ervaren manager heb je een moment van bezinning. Je staat daar en kijkt naar je organisatie.
Je ziet een groot en gelaagd systeem dat is geoptimaliseerd voor lokale efficiëntie. Je bent zo geleidelijk veranderd in iets waar je niet trots op bent, maar je was te dichtbij om het te zien gebeuren.
Hoe had je dit kunnen voorkomen? Maar ja, je bent nu hier. De belangrijkste vraag is waar je kunt beginnen met ten goede te veranderen.
Eén ding weet ik zeker: nog meer regels en procedures, lagen, functies, experts en managers toevoegen is NIET het antwoord. Zo ben je er in de eerste plaats gekomen. Ga niet nog meer complexiteit toevoegen aan dit toch al complexe probleem. Ga niet een of ander agile framework 'erbij doen'. Als je agile gaat doen, met welke andere dingen stop je dan?
Het hele idee achter lichtgewicht frameworks zoals Scrum is dat we het proces en de interactie vereenvoudigen. Voeg agile niet toe 'als opleverproces' binnen een grotere waterval planmatige aanpak. Gebruik Scrum in zo'n geval als fundament. In plaats van Prince II of IPMA, niet ernaast.
Gebruik de feedback om iteratief te leren welke regels, procedures, lagen, functies en experts je belemmeren om sneller, goedkoper en beter op te leveren. Agile lost je problemen niet op, maar onthult wel waar je organisatie pijn heeft. Het is dan aan jou om je processen en structuren te vereenvoudigen.
Versnellen als hoeksteen
De voordelen van een Agile transformatie liggen meestal ergens in de lijn van beter, goedkoper, sneller leveren. Beter in termen van kwaliteit, klanttevredenheid of marktaandeel, goedkoper in termen van minder verspilling in product/proces, en sneller in termen van time-to-market/time-to-learn.
Hoe specifieker je weet wat je nastreeft, hoe beter je de vooruitgang kunt meten. In de zoektocht naar een voordeel op lange termijn door beter, sneller of goedkoper te zijn, durf ik best te zeggen dat snelheid de beslissende factor is. Het verhogen van de snelheid van leveren heeft meer aandacht nodig dan de andere voordelen.
Als je sneller bent, kun je je klanten eerder bedienen en kun je sneller leren. Sneller zijn in termen van efficiëntie betekent ook goedkoper zijn. Hoe sneller de feedbackloop, hoe meer je kunt valideren of je waarde levert. Dit is als samengestelde rente; het lijkt niet veel in het begin - maar dit zal je bedrijf op een heel ander spoor zetten en op termijn hét verschil maken.
Ben je, sinds je organisatie agile werkt, begonnen met het versnellen van je proces om te leveren? Voeg je 'agile' toe en maak je je organisatie complexer, of haal je juist onderdelen weg en vereenvoudig je en versnel je de organisatie?
All of us know more than one of us
Je organisatie vereenvoudigen door de omgeving te veranderen.
Klinkt complex, want dat is het ook. Hoewel we dit erkennen, benaderen we organisatorische verandering vaak nog steeds planmatig. Vertel ons wat we moeten veranderen, in welke volgorde we dit gaan doen en vertel me wanneer we wendbaar zullen zijn. Zie je de tegenstrijdigheid hierin?
Net als bij productontwikkeling en innovatie gaan we met complexiteit om door een empirische benadering te gebruiken: inspecteren en bijsturen. Neem een stap in de richting van je doel, valideer je aannames, beslis over de volgende mogelijke stap. Kijk naar je huidige organisatie; haar structuur, haar processen, haar gewoonten. Bepaal welke elementen helpen en welke elementen belemmeren?
Welke factoren hebben een positieve invloed op een omgeving die individuen en interacties, werkende oplossingen, samenwerking met klanten en reageren op verandering mogelijk maakt? Gebruik die elementen, versterk ze en leer van hun succes.
Welke factoren belemmeren zelforganisatie, kort cyclisch waarde leveren, creatieve nieuwe oplossingen en experimenteren? Maak deze elementen expliciet en gebruik de denkkracht en inzichten van de mensen die het werk doen om betere en eenvoudigere alternatieven te vinden.
Learn by doing
Organisatorische verandering is moeilijk.
Je organisatie stap voor stap vereenvoudigen en van elke stap leren is de sleutel om de verandering te laten beklijven. Zo'n grote verandering is spannend. We weten immers niet wat de precieze uitkomst zal zijn en we weten dat we onderweg voor problemen zullen komen te staan. Het is dus volkomen begrijpelijk dat we op zoek gaan naar zekerheid in het licht van deze onzekere uitkomst. Maar die zekerheid zoeken in een groot, goed geanalyseerd en uitgebreid plan, zal niet de verzekering bieden die je zoekt.
Net als bij productontwikkeling is de manier om met deze onzekerheid om te gaan om je te richten op een kort cyclisch kleine dingen veranderen in plaats van een alles in een big-bang. Dus hoe zou je in de verandering van je organisatie sneller kunnen leren wat werkt en wat niet?
Ik geef de voorkeur aan een gecontroleerd experiment op basis van een aantal stelregels:
- diep en smal boven breed en ondiep
- top-down én bottom-up
- gebruik mensen die zelf het voortouw willen nemen
Neem één product, haal het uit je huidige structuur en koppel het lost van de bestaande procedures. Geef ze de ruimte om te experimenteren en zorg ervoor dat de lessen terugvloeien in de organisatie.
De valkuil van Agile als mindset
In diverse transformaties zien we vaak dat we ons vrijwel alleen richten op het veranderen van de mindset van mensen. Als ze agile gaan denken, zullen ze hun gedrag veranderen. We geven ze training - wat goed is! - en verwachten dat ze die kennis terugbrengen in de organisatie. Maar als je niet ook het systeem verandert waarin ze zitten, welke resultaten kun je dan verwachten.
Het is alsof je tegen je kinderen zegt niet te roken, terwijl je zelf een zware roker bent. Of je kind naar een snoepfabriek sturen en verwachten dat het niet toegeeft aan de verleiding.
Mensen gedragen zich naar het ecosysteem waarin ze leven. Gewoonten en manieren van werken zijn voornamelijk gebaseerd op de triggers en de context van een specifieke omgeving. Als die omgeving gestructureerd is voor het minimaliseren van risico's, sterke silo-verantwoordelijkheden en procesmatige besluitvorming - hoeveel zelforganisatie kunnen die mensen dan laten zien? In hoeverre zijn ze in staat om een empirische benadering toe te passen als contracten worden dichtgetimmerd? Hoeveel samenwerking kun je dan verwachten?
Ja, zet je mensen op een training. En begin dan met organiseren voor eenvoud en snelheid. Creëer een omgeving waar individuen en interacties worden ondersteund, waar focus op snel valideren wordt beloond.
De usual suspects
Elk jaar publiceren verschillende instituten metastudies over Agile adopties. Ze publiceren cijfers over de meest gebruikte raamwerken, de mate van gebruik van Agile in de organisatie en de behaalde voordelen. Vaak zien we ook een sectie over 'wat verdere agile adoptie belemmert'. Ik ben geneigd om dat deel tegenwoordig over te slaan, omdat jaar na jaar dezelfde dingen opduiken.
In elk van deze onderzoeken duiken meestal dezelfde inzichten op. De usual suspects die pijn doen zijn (niet noodzakelijk in deze volgorde):
- het vermogen om de cultuur te veranderen
- steun en gedrag van het management
- algemene weerstand tegen verandering
- Agile toevoegen binnen huidige methoden of raamwerken
- kennis, vaardigheden en ervaring met Agile
Natuurlijk zijn er bij deze complexe verandering geen voor de hand liggende en beste oplossingen. Sommige dingen moeten echter simpelweg altijd gebeuren:
- Mensen opleiden
- Inhuren op competenties die passen bij agile
- De organisatie versimpelen
- De urgentie en de doelstellingen benadrukken
Misschien wel wel de vraag die het lastigst blijft: Hoe moeten we nu omgaan met het beïnvloeden van organisatiecultuur en de rol van management? Wat zijn daar de patronen die helpen om het succes te vergroten?
Respect comes first
Die managers... Zucht... Ze roepen vaak het hardst 'agile' en ze staan de adoptie of transformatie vaak het meest in de weg. Het management - waarschijnlijk het middenkader - kan voelen als een blok aan het been. Als PO zou ik de gesprekken moeten voeren, maar toch is er een manager die de echte beslissingen neemt. Als SM zou ik het team moeten ondersteunen in het continu verbeteren, maar er is nog steeds een manager die individuele opdrachten en beloningen uitdeelt als het gaat om persoonlijke ontwikkeling.
Laten we niet vergeten dat de meeste managers hun huidige positie hebben bereikt, zeer goed zijn beloond en nog steeds waardering krijgen omdat ze directe, besluitvaardige, doelgerichte probleemoplossers zijn. Laten we niet vergeten dat die mensen ons gebracht hebben waar we nu zijn - omdat we dat gedrag en die sterke punten nodig hadden.
Agile is niet alleen een andere voor delivery, het is ook een ander paradigma voor managers. Zoals met alle paradigmaverschuivingen, doet het pijn. In de woorden van Gandhi: eerst negeren ze je, dan lachen ze je uit, dan vechten ze met je, dan win je.
Voor hen is deze Agile ook onzeker, ze zien hun baan vaak het meest veranderen of ze zijn bang dat hun baan zal verdwijnen. Laten we dat respecteren voordat we van hen verwachten dat ze veranderen. Als jij als coach of Scrummaster acteert, stel jezelf eens de vraag. Behandel je de managers als probleem of behandel je ze als personen die onderdeel zijn van de verandering?
Theorie X of Y
Nog een gedachte over management. Er wordt veel geroepen over wat managers niet meer zouden moeten doen. Ik heb ook het gevoel dat ze niet altijd veel handvatten krijgen over wat ze wél kunnen doen. In tijden van onzekerheid, zoals een agile transformatie, hebben we de neiging om terug te vallen op wat we kennen. In veel gevallen betekent dit, het probleem oplossen - het stuur steviger in handen nemen.
Managers zijn lang beloond om dit soort gedrag te vertonen. Bovendien is een flinke dosis van de managementpraktijken die in MBA’s worden onderwezen, gebaseerd op theorie X (werknemers houden over het algemeen niet van verantwoordelijkheden en hebben behoefte aan voortdurende begeleiding en extrinsieke beloningen). Onze organisaties zijn ook gestructureerd voor theorie X, ze zijn gestructureerd voor controle en om verandering te minimaliseren.
Dus als manager in een organisatie die plotseling besluit om 'agile' te gaan werken, is dat doodeng. Plotseling begint zich een paradigma te vormen dat gebaseerd is op theorie Y. Een denkrichting waarbij medewerkers zelf gemotiveerd zijn, beslissingen willen nemen, initiatief en autonomie nodig hebben en niet veel sturing nodig hebben, heeft nu de overhand. Dit is niet hoe managers worden opgeleid. Dus aan alle agile coaches die 'theorie Y' verkondigen terwijl 'theorie X' altijd de norm is geweest: reflecteer eerst voor jezelf. Wat is de positieve intentie, de gemeenschappelijke basis, probeer het te begrijpen voordat je probeert te overtuigen.
Manage the system not the people
Als ik terugkijk op mijn ervaringen in agile transformaties, durf ik iets best stellig te beweren. Iedereen wil nuttig zijn voor de organisatie. Dat geldt voor alle lagen en mensen. Ja, soms is er weerstand. Ja, soms lijkt men niet mee te willen bewegen. Of het nu gaat om het C-level, middenmanagement of de mensen in de teams, er zijn maar heel weinig mensen die bewust belemmerend gedrag vertonen.
Ja, er zijn uitzonderingen op de regel, maar behandel die mensen dan ook als uitzonderingen. Managers zijn op zoek naar de juiste hefbomen om 'hun werk te doen'. Binnen het organisatiesysteem worden ze nog steeds verantwoordelijk gehouden voor een groot deel van de resultaten. Ook al zijn er nu Product Owners, cross-functionele teams en Scrum Masters, hun scope is vaak niet veranderd. Ze vertonen bepaald gedrag als onderdeel van dat organisatiesysteem.
Vanuit dat uitganspunt denk ik dat de meeste mensen in die posities meer dan open staan voor coaching en advies. Help hen door een spiegel te zijn voor hun acties wanneer dingen slecht gaan. Help ze door het raam te kijken als het goed gaat. Luister naar hun uitdagingen met de beweging naar zelforganisatie. Help hen de context te creëren waarin teams en klantgerichtheid kunnen gedijen. Help hen door obstakels die het leveren van waarde belemmeren expliciet te maken en deze obstakels structureel aan te pakken.
Cultuur = de automatische keuze
Misschien is het grootste obstakel bij agile transformatie wel het vermogen om de cultuur te veranderen.
Ja, Agile is een mindset. Nieuw denken moet leiden tot nieuw gedrag. Om dit 'nieuwe' gedrag te laten zien, kan een structurele verandering en een andere managementaanpak nodig zijn. Als we dit gedrag allemaal consequent vertonen, zullen we een andere cultuur vormen.
Dus aan de ene kant is een agile cultuur een deel van de oplossing om jouw specifieke organisatorische complexiteitsprobleem op te lossen, aan de andere kant is de grootste barrière voor agile het vermogen om de cultuur te beïnvloeden. Dat klinkt als een strijd.
Staat je huidige cultuur haaks op innovatie, zelforganisatie, snelle en vroege levering? Ben je bereid om je cultuur te veranderen?
Identificeer gedrag dat jij als change agent of leider ziet als niet congruent met agile principes. Benadruk en onderzoek, wat zou de positieve bedoeling kunnen zijn, de onderliggende waarde? Vraag jezelf af, welke gewoontes, regels, procedures of prikkels maken dit gedrag mogelijk of bevorderen het?
Deze elementen kunnen een goed uitgangspunt zijn om je cultuurverandering te starten. Wat zouden betere alternatieven zijn of kunnen we deze elementen verwijderen? Begin je organisatiecultuur stap voor stap te beïnvloeden.
Lead by Example
Sommige mensen zeggen dat je cultuur helemaal niet kunt veranderen. Ik denk dat cultuur een manifestatie is van waarden en overtuigen door middel van gedrag. Cultuur wordt gedeeld, is systemisch en daarom moeilijk te beïnvloeden. Cultuur is echter ook aangeleerd, dynamisch en wordt in een bepaalde context getoond.
Als je het kunt leren, kun je het ook afleren. Als het dynamisch is, kan het evolueren. Als het in een bepaalde context wordt getoond, kan die context worden veranderd! Als je de structuur verandert, volgt de cultuur. Dus als je de structuur niet verandert, zal je cultuur minder snel veranderen.
Het andere element van cultuurverandering gaat over het gewenste gedrag vertonen. Vooral de mensen in leidinggevende posities moeten de daad bij het woord voegen. Wees de verandering die je in je bedrijf zou willen zien. De hoogste in rang zet de toon voor gedrag. Mensen kijken naar jou, wat je uitdraagt, wat je promoot en wat je tolereert!
Voor alle anderen geldt: wacht niet op anderen om de ander gedrag te vertonen. Wacht niet tot anderen het goede voorbeeld geven. Je hebt geen managementpositie nodig om leiderschap te tonen.
Radical Candor
In het kader van voorbeeldgedrag is je eigen gedrag slechts één kant van de medaille. De andere kant is hoe je omgaat met het gedrag van anderen. Vooral als leider is dat misschien wel net zo belangrijk. Het gaat om wat je toelaat, omarmt en bemoedigt.
Ik heb in het verleden vaak samengewerkt met mijn ex-collega Guus. Wat ik erg waardeer is hoe we elkaar openlijk kunnen aanspreken in ons werk. Als ik de neiging heb om streng over te komen in een training, laat hij me dat ter plekke weten. Als hij te snel over een vraag van een cursist heen stapt, vertel ik hem direct dat hij de vraag niet beantwoordt.
Voor sommige mensen kan dit overkomen als direct, bot of opdringerig. Ik weet echter als Guus me ergens op wijst, dat dit met de beste bedoelingen is. Hij geeft om me en we willen allebei de best mogelijke training geven. Andersom is hij niet beledigd maar waardeert hij mijn opmerkingen omdat hij weet dat dit nodig is om te groeien en te verbeteren.
Dit concept van radicale openhartigheid, waarbij je direct uitdaagt en er persoonlijk om geeft - is iets dat ik graag vaker zou zien! Misschien vereist dit een bepaald niveau van vertrouwen om te doen. Echter is radicale openhartigheid net zo goed een middel om vertrouwen op te bouwen.
Aan de slag met een Agile werkwijze?
Aan de slag meteen Agile werkwijze?