De evolutie van Agile-principes & hoe je ze toepast in de wereld van vandaag

Het transcript lezen:

We proberen onze podcasts uit te schrijven met behulp van een softwareprogramma. Vergeef ons eventuele typfouten, want de bot is niet altijd 100% correct.

Galen Low: Hallo allemaal, bedankt dat jullie luisteren. Mijn naam is Galen Low van The Digital Project Manager. Wij zijn een community van digitale professionals met als missie elkaar te helpen vaardigheden op te bouwen, zelfvertrouwen te ontwikkelen en verbinding te maken, zodat we de waarde van projectmanagement in een digitale wereld kunnen vergroten. Als je daar meer over wilt horen, ga dan naar thedigitalprojectmanager.com/membership.

Goed, vandaag maken we een reis om Agile opnieuw vorm te geven en te onderzoeken hoe het in de toekomst kan worden gebruikt — en welke aanpassingen we zouden moeten maken om ervoor te zorgen dat het ook over vijf, tien of vijftien jaar nog goed aansluit bij de manier waarop teams zullen werken.

Vandaag schuift niemand minder dan Jim Highsmith bij me aan — dé Jim Highsmith — een gerenommeerde Agile-pionier, mede-auteur van het Agile Manifesto, oprichtend lid van de Agile Alliance en veelzijdige professional op het gebied van technologieprojecten met meer dan 60 jaar ervaring... Ik zou kunnen doorgaan, maar volgens mij zouden de onderscheidingen dan ongeveer de hele aflevering vullen.

Dus Jim, heel erg bedankt dat je vandaag bij me bent! Het is een eer.

Jim Highsmith: Bedankt, Galen. Ik kijk ernaar uit.

Galen Low: We zijn al flink in gesprek. Ik heb genoten van onze gesprekken. We hebben het gehad over de toekomst van Agile. We hebben het gehad over het opnieuw vormgeven van Agile.

Maar ik dacht dat ik meteen in een interessant onderwerp zou duiken nu ik je toch te pakken heb. Je bent mede-auteur van het Agile Manifesto. En je bent vanaf het begin lid geweest van veel van de belangrijke groepen die ten grondslag liggen aan wat Agile vandaag de dag is. Met andere woorden: je hebt een van de beste plaatsen gehad om de evolutie van Agile vanaf het allereerste begin te zien.

Op welke manieren heb je de toon zien veranderen in gesprekken over Agile vandaag, vergeleken met de tijd waarin het een nieuw idee was? Is het nog steeds zo spannend om erover te praten?

Jim Highsmith: Voor mij is het nog steeds spannend. Ik weet niet of dat voor iedereen geldt. Een van de dingen die je moet beseffen, is dat het Agile Manifesto in een ander tijdperk is ontstaan.

Ik bedoel, het was 23 jaar geleden. Er was in die periode niet veel sociale media. De manier waarop we het woord verspreidden, was via tijdschriftartikelen, spreken op conferenties en de wiki van Ward Cunningham. Dat was het zo ongeveer. In de beginjaren kregen we veel pijlen op ons afgevuurd, omdat het echt een verandering ten opzichte van het verleden was — een behoorlijk ingrijpende verandering.

Behalve op sommige plaatsen. Als je bijvoorbeeld naar Silicon Valley ging en zei: kijk, hier is wat praktische informatie, dan zeiden ze: o, dat doen wij al. We hadden er alleen nog een naam voor nodig. Ik was eens bij een bedrijf in Silicon Valley en zij zeiden dat ze Agile toepasten. Ik vroeg: hoe lang duren jullie iteraties? Ze zeiden: drie of vier maanden.

Dus zelfs daar waren er verschillen van inzicht. Het andere is dat er al lange tijd een levenscyclus voor technologie-adoptie bestaat: vernieuwers, vroege meerderheid, late meerderheid. In het begin waren het een paar vernieuwende mensen, zowel bedrijven als individuen, die zich echt op Agile stortten.

Nu hebben we mensen in al die verschillende fasen. We hebben de vroege meerderheid en de late meerderheid. Sommige mensen beginnen net. Anderen willen niet beginnen. Daardoor krijg je van elk van hen een ander soort feedback. In het vernieuwende segment gaan mensen gewoon mee met wat een goed idee is.

Tegen de tijd dat je bij de late meerderheid komt, willen ze bewijs. En niet alleen bewijs binnen hun sector, maar ook binnen hun soort projecten. Ze zullen al snel zeggen: nee, dat kunnen we niet doen vanwege X, Y en Z. Je zult dus altijd gemengde reacties krijgen op dit soort vragen. Een van de dingen die ik heb gemerkt — en ik heb alles gedaan, van geen methodologie tot gestructureerde methodologieën en Agile-methodologieën — is dat ze allemaal werken en dat ze allemaal niet werken.

Het gaat meer om de mensen dan om de methodologie. En eigenlijk gaat het om de mentaliteit. Ik gebruik liever de woorden ‘verwezenlijkingen en teleurstellingen’ dan ‘succes en mislukking’. Ik denk dat elk project, of het nu Agile of Waterval is of iets anders, bepaalde verwezenlijkingen heeft. Mensen zeggen: Waterval werkt niet.

Nou, in de jaren tachtig heb ik heel wat projecten met Waterval uitgevoerd en die waren zeer succesvol. We hebben veel bereikt. Er waren ook teleurstellingen, en sommige van die teleurstellingen haalden ons halverwege de jaren negentig in. In een boek uit 2002 schreef ik een definitie van wendbaarheid. Wendbaarheid is het vermogen om verandering te creëren én erop te reageren om voordeel te behalen in een turbulente bedrijfsomgeving.

Ik weet niet of ik daar vandaag veel aan zou veranderen. Het gaat om wendbaarheid. En ik denk dat mensen soms methoden, methodologie en mentaliteit door elkaar halen. Dat zijn drie verschillende dingen waar we later nog wat dieper op kunnen ingaan. Maar in essentie is de toon bij het kijken naar Agile veranderd.

Een van de dingen die ik met dit initiatief om Agile opnieuw vorm te geven probeer te doen, is de toon weer positiever maken.

Galen Low: Ik vind die invalshoek erg goed: het gaat niet meer alleen om de groep van vroege gebruikers. Nu heb je een spectrum van mensen die achterlopen en mensen die later instappen, met het bewijs dat zij nodig hebben.

De bewijslast is nu anders dan vroeger. En ik vind het mooi wat je zegt over het feit dat de wereld blijft draaien en dat wendbaarheid tegenwoordig als waardevol wordt gezien, maar dat betekent niet dat Waterval niet meer werkt. Het kan gewoon een ander doel of aandachtspunt hebben, of je kunt andere teleurstellingen en verwezenlijkingen verwachten. Dat betekent niet dat het verouderd is.

Jim Highsmith: Iets wat volgens mij soms uit het oog is verloren, is dat je projecten moet bekijken binnen de context van die projecten, vooral als het gaat om onzekerheid. Een project zoals het Webb-telescoopproject is bijvoorbeeld heel anders dan het maken van een app voor je iPhone, als je kijkt naar de gebruikssituatie. Dat moet je begrijpen wanneer je in het bijzonder een project gaat managen.

Galen Low: Ik vind het geweldig dat je dat voorbeeld gebruikt, want we grijpen vaak naar dit soort lucht- en ruimtevaartvoorbeelden. In een softwarewereld met continue integratie, waarin je voortdurend implementeert, is het relatief eenvoudig.

Ik zeg niet dat het gemakkelijk is, maar het is zeker een stuk eenvoudiger dan een spaceshuttle naar het ruimtestation sturen voor een bevoorradingsmissie of om een onderdeel te repareren dat niet werkte zoals verwacht. Je moet anders plannen, anders budgetteren en gewoon anders over dat project nadenken.

Jim Highsmith: Ja. Interessant dat je lucht- en ruimtevaart noemt, want begin jaren 2000 had ik een gesprek met de minister van de luchtmacht. Zij had mijn eerste boek gelezen en zei dat we bij het bouwen van lucht- en ruimtevaartprojecten misschien iteraties nodig hadden, en dat die misschien geen jaar of twee jaar konden duren.

Ze gebruikte het idee van adaptieve ontwikkeling in een van haar toespraken. Het is dus niet zo dat alle lucht- en ruimtevaartprojecten Waterval moeten zijn; ze kunnen tot op zekere hoogte adaptief en Agile zijn. En ik denk dat dat een belangrijk onderdeel is van onszelf opnieuw vormgeven.

Galen Low: Eerder lachte ik een beetje om het idee van een sprint van drie tot vier maanden. Maar soms is dat, in het grote geheel, juist wendbaar. Dat is snel. Het is een zeer korte cyclus om resultaten te krijgen, ervan te leren en ervoor te zorgen dat je niet vijftien jaar lang het verkeerde bouwt. Het is nog steeds de juiste mentaliteit, zelfs als — en ik denk dat ik terugkom op wat je eerder zei — er methoden, methodologieën en mentaliteiten zijn, die we voortdurend door elkaar halen.

Soms willen we dat sommige van die mentaliteiten allerlei vastgelegde regels en dingen hebben, regels die je niet mag overtreden. Maar eigenlijk is het gewoon een manier om erover na te denken, om sommige andere teleurstellingen te voorkomen die zouden zijn ontstaan als je het op een andere manier had aangepakt.

Jim Highsmith: Je kunt elk van de praktijken nemen, bijvoorbeeld sprintplanning. Je kunt ze belasten met documentatie en vergaderingen, waardoor ze zeer voorschrijvend worden, of je kunt ze adaptief maken. Je kunt dus dezelfde praktijk nemen en afhankelijk van hoe je die benadert, wordt ze meer voorschrijvend of meer adaptief.

Galen Low: Alle voordelen die mensen aanprijzen van iets — van wat dan ook, niet alleen Agile — kunnen ook de ondergang ervan worden. In de verkeerde handen kunnen ze onwaar worden.

Jim Highsmith: Het andere is dat met de komst van sociale media de 10% een luidere stem heeft dan de 90%. En 10% is graag negatief. Ik weet niet of je Spiro Agnew nog kent, maar hij was vicepresident onder president Nixon. Hij stond bekend om de uitdrukking ‘the nattering nabobs of negativity’.

Daaraan moest ik denken toen ik me hierop voorbereidde. Ik dacht: dat is het probleem met 10% van de mensen op sommige van die sociale media; het zijn praatgrage vorsten van de negativiteit.

Galen Low: Het is grappig, en ik ben blij dat je sociale media noemt, want veel mensen maken tegenwoordig via controverse kennis met Agile — via iemand op Reddit of iemand op sociale media, meestal vanuit een negatief perspectief. Waarom gebruiken mensen nog steeds Waterval, of wat is er zo bijzonder aan Agile? Het werkt nooit. Ze benaderen het vanuit die extreem polariserende kanten. En zoals jij zegt: ze zijn luidruchtig.

Het is niet meer slechts een handjevol mensen dat naar een radioprogramma luisterde, een billboard zag of een academisch artikel las. Het verschijnt praktisch bij iedereen in de tijdlijn. Ze krijgen voortdurend dit soort indrukken in hun hoofd. Maar terugkomend op je voorbeeld: in de politiek is dit een projectmethodologie waarvan je niet zou verwachten dat ze zo controversieel en omstreden is, maar dat is ze wel. We discussiëren al meer dan twintig jaar hartstochtelijk over de vraag of Agile goed is of niet. En volgens mij discussiëren we er nog steeds over. Waarom doen we dat nog steeds?

Waarom is het zo omstreden en waarom zijn we er na ruim twintig jaar nog niet overheen?

Jim Highsmith: Juist. Ik zag bijvoorbeeld eerder dit voorjaar een bericht op LinkedIn over de problemen met Agile-benaderingen. Het ging over het feit dat er geen documentatie zou zijn en er waren nog enkele soortgelijke punten.

Ik zei: die vragen hebben we twintig jaar geleden al beantwoord. Waar ben je geweest? Ongeveer een maand geleden keek ik door mijn projectmanagementboek, Agile Project Management, dat in 2009 is gepubliceerd. Ik zag daar toevallig een grafiek over documentatie die ik was vergeten.

Ik dacht: goed, dit is iets waarin ik naar een meer evenwichtige benadering van documentatie heb gekeken en enkele richtlijnen heb gegeven. Ik plaatste het op internet zoals het was. Ik heb niets aangepast of veranderd. Het heeft inmiddels 66.000 vertoningen en 96 keer opnieuw plaatsen. Iets waarvan ik dacht dat het niet zo interessant was — richtlijnen voor documentatie. Het laat zien dat er veel mensen zijn die op zoek zijn naar goede, evenwichtige informatie, weg van de extremen.

Dat gezegd hebbende, hadden we die extremen destijds wel nodig, omdat we de grenzen moesten onderzoeken. Bij documentatie zei iemand misschien: laten we geen documentatie proberen. Niemand bedoelde dat letterlijk. Wat we bedoelden, was dat documentatie communicatie en samenwerking had vervangen.

Een gevolg van Waterval was dat je organisaties kreeg die Waterval volgden. Je had een afdeling voor vereisten, een ontwerpafdeling, een programmeerafdeling en een testafdeling. De communicatie daartussen bestond volledig uit documentatie. Er was geen samenwerking.

Er was toen geen interactieve communicatie. Daar wilden we juist vanaf: de essentie was dat documentatie je samenwerking moest aanvullen, niet andersom.

Galen Low: Het is grappig, want we gebruiken taal als ‘de Agile-revolutie’, ‘grote verandering’ en ‘omwenteling’. Je hebt gelijk: er is veel tijd verstreken en we waarderen niet helemaal meer welke druk er toen nodig was. Wanneer je aan revoluties denkt, aan redeneren vanuit een uiterste om verandering te bewerkstelligen, denk ik dat veel mensen het misschien te letterlijk hebben genomen. Daarna zijn mensen het steeds opnieuw op een handige manier verkeerd blijven interpreteren, want voor zover ik kan zien klinkt het niet als ‘geen documentatie’.

Het gaat er meer om dat communicatie boven documentatie staat als principe.

Jim Highsmith: Het gaat om interpretatie. Het lijkt een beetje op de Amerikaanse grondwet. Er zijn rechters die strikt interpreteren. Wat er in de grondwet staat, is precies wat het betekent. Dus als er in het Agile Manifesto software staat, dan geldt het voor software.

Er zijn ook anderen die losser interpreteren en erkennen dat Agile kan evolueren en dat het manifesto niet in steen gebeiteld is. Het was bedoeld voor een specifiek moment in de tijd. We moeten dus manieren vinden om het naar andere gebieden uit te breiden en niet blijven hangen in de exacte formulering.

Galen Low: Het is geen Agile-probleem. Het is een menselijk probleem. En dat is net zo goed van toepassing op het letterlijk interpreteren ervan, het voldoende begrijpen van de essentie om het mee te nemen naar de toekomst, en alles daartussenin. Is dat goed? Daar gaan we ons juist in verdiepen. Ik denk dat mensen niet altijd beseffen dat Agile verandert.

Dat heb jij volgens mij gezien. Ik vraag me af welke opkomende trends of praktijken in Agile projectmanagement je recentelijk zijn opgevallen.

Jim Highsmith: Het is interessant dat er volgens mij mensen zijn die uitbreidingen maken op de basisaanpak van Agile. Toen we in 2004 en 2005 begonnen met de Agile-conferenties, maakte ik me bijvoorbeeld zorgen omdat er zoveel negativiteit in de Agile-gemeenschap tegenover projectmanagement was.

Daarom kwamen we met scrum masters en andere aanduidingen: we hebben geen verdomde projectmanagers meer nodig, maar scrum masters. Dat is volgens mij lange tijd een probleem geweest. In 2005 ontdekte ik een organisatie die The Agile Project Leadership Network heette. Onze missie was om projectmanagement uit te breiden naar Agile en eigenlijk te zeggen: projectmanagement is niet waardeloos; we hebben gewoon een ander type projectmanagement nodig.

We hebben projectmanagement nodig dat meer op mensen dan op taken gericht is, dat zich richt op samenwerking en op andere zaken. We begonnen daarmee, en dat is eigenlijk de groep waarvan sommigen van ons naar PMI zijn overgestapt om de Agile PMI-certificering te ontwikkelen. Ik denk dat er altijd uitbreidingen zijn geweest. Mensen zoals David Pereira werken bijvoorbeeld verder aan het onderwerp. Hij heeft een nieuw boek over productmanagement geschreven en ik heb het voorwoord geschreven.

Wat ik er goed aan vond, is dat het boek volledig over wendbaarheid gaat, maar dat hij het woord Agile of wendbaarheid misschien maar een paar keer gebruikt. Het draait allemaal om het concept van wendbaarheid. Er zijn anderen zoals Chris Stone die met hun aanpak van softwareontwikkeling vooruitgaan zonder altijd het woord Agile te hoeven gebruiken. Uiteraard is AI het grote opkomende gebied. Ik heb mensen de term ‘veredelde Agile’ zien gebruiken, wat volgens mij passend is voor deze tijd.

Galen Low: Je zei eerder dat jullie bij het schrijven en uitbrengen van het manifesto met pijlen werden beschoten en dat mensen boos waren over verandering.

Nu hebben we het idee van uitbreidingen op Agile. Worden sommige van deze mensen ook met pijlen beschoten? Gebruiken ze bewust het woord Agile niet, zodat het mensen niet afschrikt of zodat ze niet worden aangevallen?

Jim Highsmith: Een deel daarvan speelt inderdaad mee, omdat sommige mensen de term een beetje loslaten vanwege de slechte publiciteit.

Interessant genoeg krijgt Agile tegenwoordig goede publiciteit in het bedrijfsleven. Als je bijvoorbeeld kijkt naar aankondigingen van directieleden over hun koers, zie je dat de topman van GM het woord wendbaarheid heeft gebruikt. De topman van Bayer heeft een nieuwe praktijk opgezet en ook daar wordt het woord wendbaarheid gebruikt. In een zakelijke omgeving wordt het dus steeds vaker gebruikt.

Steve Denning heeft onlangs verschillende artikelen in Forbes geschreven over het implementeren van Agile-methodologieën. Een Agile-mentaliteit is tegenwoordig belangrijk geworden voor enkele van de grootste bedrijven.

Galen Low: Ja, dat zie ik ook steeds vaker. Het leidt binnen onze community tot gesprekken over wat ze bedoelen.

Komt er dan zoiets als Scrum voor leidinggevenden, voor strategische planning en strategische uitvoering? Of gaat het meer om die mentaliteit? En opnieuw raken we verstrikt in het onderscheid tussen methoden, methodologieën en mentaliteiten. Waarschijnlijk gaat het om alle drie, maar we moeten voorkomen dat ze door elkaar raken.

Jim Highsmith: Er is bijvoorbeeld een vereniging, de Agile Marketing Association, die Agile-principes toepast op marketing en daar behoorlijk succesvol mee is. Ik denk dat je uitbreidingen voor marketing zult zien, meer dan één. Je zult uitbreidingen zien rond kunstmatige intelligentie en in verschillende sectoren. En nee, ik denk niet dat je sprintplanning in de bestuurskamer zult krijgen.

Wel zul je meer Agile en adaptieve manieren zien om hiernaar te kijken. Neem als voorbeeld de organisatiestructuur. Ik luisterde naar een ongelooflijk goede presentatie van de topman van NVIDIA. Hij vertelde dat hun nieuwste chip 208 miljard transistors bevat. Toen ik begon, was een transistor ongeveer zo groot als het uiteinde van je vinger.

Als je dat vermenigvuldigt met 208 miljard, kom je uit op tien vierkante mijl. De technologie van vandaag verschilt enorm van die van zelfs maar vijf jaar geleden. Ik praat hierover met groepen. Onlangs kwam er na een presentatie een vrouw naar me toe die zei: je hebt me echt geïnspireerd en je hebt me doodsbang gemaakt.

Ik had het over onderwijs, training en al dat soort zaken. Ik zei dat je, wie je ook bent — scrum master, projectmanager of Agile-coach — enige technologische achtergrond nodig hebt. Je kunt er niet meer omheen. Ik denk dat dat sommige mensen wakker heeft geschud.

Galen Low: Het is interessant. Ik moet soms ook uit mijn eigen referentiekader stappen, want zoals je zegt gaat het manifesto over software. Ik zie tegenwoordig veel dingen en reageer dan extreem met: natuurlijk. Maar voor veel andere sectoren is het helemaal niet vanzelfsprekend. Ik ben blij dat bedrijven, marketing en andere gebieden hun processen en methoden openstellen om wendbaarder te worden.

Zij moeten ook hun eigen weg vinden. Het helpt niemand als iemand boven op de berg staat en zegt: zoek het nu maar uit. Het helpt ook niet om te zeggen: dit is mijn bergtop, blijf daar beneden en denk hier niet eens over na.

Er is veel ruimte voor meer samenwerking. Waar vindt de meeste verandering plaats? Waar is de meeste wendbaarheid nodig? Rond technologie en rond het bedrijfsleven. En daardoor is het inderdaad zowel beangstigend als inspirerend. Ik denk dat het moet samenkomen en vervolgens samen moet groeien. We moeten het verder brengen. Misschien is dat wel het opnieuw vormgeven van Agile.

Jim Highsmith: Een deel ervan is het opnieuw vormgeven van management. Om terug te komen op die presentatie: de topman van NVIDIA heeft 55 rechtstreekse medewerkers. Dat heet het platter maken van de organisatie. Je moet heel anders managen als je 55 mensen rechtstreeks aanstuurt dan wanneer je er drie of vier hebt. Het was interessant om hem te horen uitleggen hoe hij anders managede omdat er zoveel mensen rechtstreeks aan hem rapporteerden. Dat is precies het soort management dat we opnieuw moeten vormgeven.

Ik geef je nog een voorbeeld van de andere kant. Een vriend van me, een consultant, ging bij een organisatie Agile-transformaties uitvoeren en ontdekte dat ze honderd softwareontwikkelaars en 98 projectmanagers hadden. Dat was een beetje uit balans. Een deel van het probleem was dat ze functionele silo’s hadden: analisten, ontwerpers, programmeurs en testers.

Iedereen werkte misschien aan zeven of acht projecten. De combinatie daarvan vereiste veel projectmanagement om alle coördinatie draaiende te houden. Een voor de hand liggende oplossing was dus de organisatie stroomlijnen, het aantal projectmanagers verminderen en het aantal technische mensen vergroten.

Ik denk dat ook de verhouding tussen management, samenwerking en techniek uit balans is geraakt. De technische aspecten van Agile hebben soms niet genoeg gewicht gekregen.

Galen Low: Dat is heel logisch. Het is grappig, want we hadden het over redeneren vanuit een uiterste. Als projectmanager en iemand die projectmanagers vertegenwoordigt, ben ik bereid toe te geven dat er slechte projectmanagers zijn. Er was waarschijnlijk behoefte aan teams waarin misschien geen projectmanager zat. Maar onze technologieprojecten zijn complexer geworden en er is meer coördinatie nodig, dus het is logisch dat er een projectmanager is.

Het midden kan zijn dat het niet alleen om botsende rollen gaat, maar ook om de balans en de manier waarop we mensen en rollen bij elkaar brengen en waar we prioriteit aan geven.

Bij een Agile-project ligt die prioriteit waarschijnlijk niet meer bij documentatie. Er zou meer nadruk moeten liggen op technische rollen. En technische rollen zijn niet meer alleen technisch. Het gaat om bekwame zakelijke denkers die ook kunnen programmeren, goed met mensen kunnen omgaan en niet langer passen in de oude stereotypen.

Onze configuraties moeten dus veranderen. Onze verhoudingen moeten veranderen. Agile lijkt een goed antwoord voor de toekomst, maar er zijn uitdagingen aan de horizon.

Welke uitdagingen zie je vandaag voor Agile-methodologieën? Welke uitdagingen komen eraan? En waarom moeten we Agile überhaupt opnieuw vormgeven?

Jim Highsmith: We moeten het opnieuw vormgeven vanwege die veranderingen. Mensen praten vandaag over AI, maar er is ook Web3, blockchain, de cloud en big data. Er zijn allerlei technologische veranderingen onderweg.

En als we over drie tot vijf jaar quantumcomputing krijgen, zal dat de zaken echt veranderen, afhankelijk van hoe snel men toepassingen kan bouwen die nuttig zijn voor bedrijven en organisaties. Ik denk dat het moeilijk zal worden om die technologische veranderingen bij te houden en de juiste impuls binnen een organisatie te creëren.

Laten we Agile even buiten beschouwing laten. Kijk naar een andere grote verandering van de afgelopen tien jaar: big data. Er is een boek geschreven over de evolutie van big data in die periode. Daaruit blijkt dat 90% van de problemen of teleurstellingen bij bigdata-implementaties cultureel was en slechts 10% technologisch.

Als Agile dezelfde weg volgt, denk ik dat we big data overtreffen wat betreft de effectiviteit van de transformatie, maar er is nog een lange weg te gaan. Veel heeft te maken met mentaliteit. Ik zie mentaliteit als de instelling van een individu en cultuur als het geheel van alle mentaliteiten binnen een bedrijf.

Ik gebruik die twee woorden dus enigszins verschillend. We lijken niet beter te worden in culturele verandering en verandering van mentaliteit. Hoe gaan we dat doen? Hoe versnellen we die verandering? Ik denk veel na over het idee van bekwaamheid in plaats van kennis. Zodra je met AI te maken krijgt en over een kennisengine praat, is kennis één ding.

Ik kan AI gebruiken voor kennisgebaseerde taken, zoals onderzoek doen. Maar bekwaamheid is iets anders. Bekwaamheid is een functie van kennis plus ervaring plus besluitvorming.

Het is dus niet genoeg om een paar certificaten voor Scrum of Kanban te behalen. Alleen kennis is niet voldoende. Je hebt ervaring nodig. Hoe kunnen we de snelheid waarmee we die ervaring opdoen verhogen? Kun je ervaring opdoen zonder iets daadwerkelijk te ervaren? Een manier is de aanpak van Harvard Business School met casestudy’s.

Je geeft een kleine groep mensen een casestudy, laat hen er uitgebreid over discussiëren en vervolgens presenteren aan de rest van de groep. Dat is ervaringsgericht, omdat het om een diepgaande analyse gaat. Zo kun je ervaring vergroten zonder een situatie daadwerkelijk te hebben meegemaakt.

Het volgende niveau is: heb je voldoende ervaring en kennis om goede beslissingen te nemen? Hoe weet je welke beslissingen je moet nemen? Er zijn beslissingen van type één en type twee. Er is dus een heel spectrum, en AI zal elk onderdeel op een andere manier beïnvloeden.

Zoek je alleen bewustwording, een assistent of uitbreiding van je mogelijkheden met behulp van AI-systemen? Ik denk dat het moeilijk wordt om dat goed te bepalen, omdat je tegenwoordig met zoveel verschillende technologische zaken rekening moet houden.

Galen Low: Daar ben ik het volledig mee eens. Alles gaat heel snel. Als je aan iteraties denkt, hebben we het over sprints. We bekijken die vanuit efficiëntie en leren, maar meestal gaat het om technisch leren, zodat we onze fouten niet exponentieel vergroten en ze pas aan het einde ontdekken.

Maar de mentaliteit van snel leren en snel falen is eigenlijk voor ons als mensen bedoeld. Zodat we iedere keer bewust kunnen leren. Dat raakt misschien niet helemaal de kern van ervaring opdoen zonder ervaring op te doen, maar we kunnen onze korte ervaringen wel gebruiken om er zoveel mogelijk uit te leren en erop te reflecteren, zodat we als mensen beter worden.

En je hebt gelijk: het probleem is meestal niet de technologie. We zijn gewoon niet goed geworden in culturele verandering. De controverse rond Agile gaat deels over interpretatie, maar voor een groot deel ook over weerstand tegen verandering. Mensen gaan van veel structuur, zekerheid en voorspelbaarheid naar een gebied dat losser, ambiguër en onbekender is. Dat menselijke mechanisme maakt mensen soms terughoudend tegenover Agile.

Jim Highsmith: Iteraties zijn belangrijk voor leren. Neem een project dat een jaar zou duren en dat je als Waterval-project uitvoert. Je doet de definitie van de vereisten één keer, het ontwerp één keer, het programmeren één keer en het testen één keer.

Als je het in een Agile-kader uitvoert met bijvoorbeeld maandelijkse releases, doorloop je al die leercycli twaalf keer in plaats van één keer. Dat stimuleert het leerproces. Iets waar ik een beetje moedeloos van word, is wat ik ‘voorschrijvende wendbaarheid’ noem. Dat is een oxymoron, maar daar komen sommige mensen uit.

Ze zeggen: laten we deze zes dingen doen. Je moet deze zes dingen doen en je moet het op deze manier meten. Dan wordt het voorschrijvend. Als je wendbaarheid voorschrijvend maakt, leer je nooit genoeg om goede ervaring op te doen en vervolgens je aanpak aan te passen. Dat staat tegenover wat ik ‘adaptieve wendbaarheid’ noem, en dat is hoe het zou moeten zijn.

Ik zou die toevoeging niet nodig moeten hebben, maar tegenwoordig soms wel. Ik denk dat dit idee van voorschrijvende wendbaarheid is waar veel mensen in de sector over klagen. Daarnaast hebben Agile-methodologieën zich breed verspreid. Zoals Jerry Weinberg zei over frambozenjam: hoe verder je het uitsmeert, hoe dunner het wordt. Aan de randen zijn er mensen die een tweedaagse cursus voor scrum masters hebben gevolgd en vervolgens scrum masteronderwijs geven.

Galen Low: Ja.

Jim Highsmith: Daar heb ik vanzelfsprekend wel wat problemen mee.

Galen Low: Aan de ene kant ben ik blij dat we het niet in een fles hebben opgesloten en voor onszelf hebben gehouden. Aan de andere kant is iets dat breed wordt toegepast vatbaar voor verkeerde toepassingen. Soms zijn het mensen die niet beseffen dat ze iets verkeerd doen: ze vertegenwoordigen, beoefenen of interpreteren het verkeerd, waardoor het verwatert. Dat is volgens mij een belangrijk uitdagingengebied.

Als we teruggaan naar jouw missie om Agile opnieuw vorm te geven, begrijp ik waarom dat nodig is. De vraag is: hoe? Aan welke strategieën werk je of welke strategieën zie je voor je om de uitdagingen van de toekomst aan te pakken?

Jim Highsmith: We hebben een initiatief opgezet om Agile opnieuw vorm te geven. Er is een kerngroep die we The Launch Group noemen.

We proberen dit initiatief alleen te lanceren; we proberen het niet te managen. We hebben een website en geven binnenkort verschillende presentaties op conferenties over Agile opnieuw vormgeven: terug naar de basis, dus het werk rond mentaliteit, en vervolgens vooruit naar de toekomst. Hoe gaan we dat managen? Hoe zorgen we ervoor dat het in de toekomst vooruitgaat?

In september ben ik betrokken bij een conferentie in Portugal over het opnieuw vormgeven van management. Niet alleen hoe we Agile-ontwikkeling in een AI-omgeving uitvoeren, maar ook hoe we leiderschap en management in een AI-omgeving vormgeven. Ik ben daar betrokken bij enkele experimenten, omdat het niet eenvoudig is.

Met de huidige hypecyclus moet je voorzichtig zijn met wat je probeert te doen. Naarmate we verdergaan met Agile, vind ik de term ‘aangevulde Agile’ passend. Het zal zonder twijfel elk gebied van softwareontwikkeling anders beïnvloeden, van programmeren en testen tot het formuleren van vereisten.

Het zal dus veranderen. Als je probeert dezelfde praktijken en methoden te blijven gebruiken, kom je in de problemen. Je moet de juiste mentaliteit hebben om te zeggen: dit is een praktijk die we vroeger gebruikten, maar die we niet meer nodig hebben omdat AI dit overneemt.

Martin Fowler schreef bijvoorbeeld een boek over refactoring. Refactoring is een interessante oefening waarbij je teruggaat en iets beter maakt.

Galen Low: Juist.

Jim Highsmith: Maar wat als je een automatisch refactoringhulpmiddel hebt? Dan wordt refactoring misschien onderdeel van het hulpmiddel en hoef je je er minder zorgen over te maken. Je moet wel in staat zijn — iemand noemde het geen prompt engineering maar promptverbeelding — om je voor te stellen welke dingen op een ander niveau zouden kunnen helpen bij refactoring. Er blijft dus ruimte voor kennis en begrip van refactoring vanuit een mentaliteitsperspectief, maar de praktijken zelf zullen veranderen door kunstmatige intelligentie en andere technologieën.

Galen Low: Is dat dan de analogie voor het opnieuw vormgeven van Agile? Jij bent een lanceringsteam en gaat een pad bewandelen van refactoring van Agile. Maar belangrijker nog: jullie bouwen het mechanisme waarmee Agile zichzelf in de loop van de tijd kan refactoren. We bevinden ons op een moment waarop we terug moeten naar de basis om vooruit te kunnen naar de toekomst.

Maar in plaats van hier over twintig jaar opnieuw terug te komen, zou Agile zichzelf gewoon moeten blijven ontwikkelen en refactoren. Is dat de droom?

Jim Highsmith: Daar had ik nog niet in termen van refactoring over gedacht, maar ik denk dat je gelijk hebt. Dat is een deel van ons doel. We willen dat mensen begrijpen dat Agile geen ramp is geweest. Het is op veel verschillende plaatsen zeer succesvol geweest. Er zijn wel teleurstellingen rond Agile die we moeten aanpakken. We moeten vooral bekijken hoe Agile zich in de toekomst zal aanpassen of refactoren. Daarom ga ik terug naar de basis en kijk ik tegelijkertijd naar de toekomst.

We hebben een website met veel goed materiaal. We proberen ook andere organisaties erbij te betrekken. De Agile Alliance heeft bijvoorbeeld een groep gevormd om verschillende panelsessies op conferenties te organiseren. Dit jaar organiseren we een panelsessie op de Agile-conferentie in Dallas.

Ik zou bijvoorbeeld graag zien dat de Scrum Organization dit initiatief van terug naar de basis en vooruit naar de toekomst op zich neemt. Onze aanpak is niet gebonden aan één stroming. Daarom heb ik bijvoorbeeld gekeken naar de teleurstellingen rond Agile en geprobeerd een analyse van de onderliggende oorzaken te maken, in plaats van te zeggen dat X, Y en Z verschrikkelijk zijn.

Wat was er in het proces dat zij doorliepen teleurstellend? Hoe kunnen we daarvan leren en het op brede schaal toepassen, of je nu Kanban, Scrum, XP of DevOps gebruikt?

Galen Low: Ik hou van die niet-confessionele aanpak. Door de schaal en het succes van Agile voelt het alsof jouw initiatief nu bijna diplomatie op staatsniveau is.

Je brengt al die organisaties, verenigingen en facties samen die zichzelf als afzonderlijk zien. Maar er is een moment van eenheid nodig om vooruit te komen. Anders zijn we als die jam die zo dun is uitgesmeerd dat we de andere kant van het brood niet meer als met jam bedekt herkennen. Dat is dan weer andere jam — dat zijn wij niet — en zo raken we gefragmenteerd.

Jim Highsmith: We hebben dit op verschillende manieren besproken. Een belangrijke vaardigheid voor iedereen die Agile wil zijn — of je nu programmeur bent of topman van een bedrijf — is het begrijpen van balans. Je balanceert voortdurend creativiteit tegenover controle, of samenwerking tegenover richting.

Vanuit organisatorisch perspectief moet je cultuur zich aanpassen aan waar je op een bepaald moment bent en waar je naartoe moet. Stel dat je op een schaal van 1 tot 10 van Agile zit, waarbij 10 het meest Agile is en 1 helemaal niet Agile. Misschien probeer je van 1 naar 3 te gaan. Dat is wat Agile-er, maar niet zo Agile als Google, Microsoft of een andere organisatie.

Hoe je dat doet, verschilt sterk van de overgang van 7 naar 8 of van 4 naar 6. Er is een punt waarop het heel moeilijk wordt. Carol Dweck heeft een boek over mentaliteit geschreven waarin ze twee basistypen bespreekt.

De groeimentaliteit staat open voor verandering, terwijl een vaste mentaliteit dat niet doet. Je hebt beide nodig. Helaas ontstaat in grote organisaties na verloop van tijd vaak een veel hoger percentage mensen met een vaste mentaliteit dan met een groeimentaliteit. Dat is een moeilijke verandering.

Als je op 1 staat en naar 3 of 4 wilt, moet je misschien nadenken over de vraag of sommige mensen met een vaste mentaliteit je vermogen om te veranderen beperken. Heb je genoeg mensen met een groeimentaliteit om die verandering te realiseren? Eén persoon bovenaan of onderaan is niet genoeg. Op elk niveau moet iemand bereid zijn om dit op zich te nemen. Dat is een deel van het probleem met cultuurverandering: het veranderen van die benadering van vaste en groeiende mentaliteiten.

Galen Low: Ook die schaal is interessant. Velen van ons zijn geprogrammeerd om het binair te willen: we willen een schakelaar omzetten en van de ene op de andere dag Agile transformeren. Maar van 1 naar 3 gaan is ook goed.

Jim Highsmith: Ook context is interessant. Ik sprak vroeger op verschillende organisatorische congressen van PMI. Ik vroeg dan: hebben jullie projecten met vrij duidelijke vereisten en bekende technologie? Dan zeiden ze ja.

Vervolgens vroeg ik of ze projecten hadden met grensverleggende technologie en zeer onzekere vereisten. Ook daarop zeiden ze ja. Dan vroeg ik: meten jullie succes bij beide projecten op dezelfde manier? Dan zeiden ze: o. En managen jullie die projecten op dezelfde manier?

Dat bedoel ik met context en balans. Je moet de context begrijpen waarin je werkt en de balans begrijpen. Geen documentatie tegenover volledige documentatie; waar ligt het balanspunt? Korte- tegenover langetermijnplanning; waar moet je zijn?

Een van mijn zorgen over sommige kortetermijnplanningen, vooral de aanpak waarbij alles om functies draait, is dat we vergeten dat er eigenlijk een doel is. Dat doel ligt verder in de toekomst dan alleen vandaag 36 nieuwe functies opleveren. Soms verliezen we het langetermijnplan omdat iedereen zegt dat je niets op lange termijn mag plannen.

Daarom ga ik terug naar het woord dat ik in mijn eerste boek gebruikte: speculatie. Je hoeft niet te plannen; je moet speculeren. Je moet je voorstellen waar je naartoe wilt, zonder het tot in detail vast te leggen zoals we vroeger deden. Maar je moet nog steeds een idee hebben van waar je naartoe gaat en welk resultaat je wilt bereiken.

Galen Low: Wat ik interessant vind, is dat het zo vanzelfsprekend klinkt, maar dat we kampen hebben gecreëerd in plaats van technieken. We proberen een kalkoen op dezelfde manier te bereiden als een salade, omdat we Agile zijn en maar één manier kennen.

Als je het echt ontleedt, zeg je: bij hoge ambiguïteit misschien dit, en bij een grote behoefte aan voorspelbaarheid en stabiele vereisten misschien dat. Het gaat niet om spatel versus vork. Het gaat erom wanneer je de spatel gebruikt en wanneer een ander hulpmiddel.

Ik vind het goed dat je mensen op een niet-confessionele manier wilt samenbrengen. We vertegenwoordigen geen enkel kamp; laten we gewoon weer samenkomen om Agile te refactoren en vooruit te helpen. Er zijn teleurstellingen die iedereen die Agile wel of niet gebruikt raken. Hoe komen we daar voorbij en hoe leren we ervan?

Vanuit jouw perspectief: waar gaat de toekomst van projectmethodologieën, projecten en de manier waarop we samenwerken en samen resultaten leveren naartoe? Terugkomend op jouw idee van speculatie: hoe bereiden we ons voor op een onbekende toekomst?

Jim Highsmith: Toen ik werkte aan mijn boek Wild West to Agile, dat vorig jaar is verschenen, begon ik aan hoofdstuk negen, het laatste hoofdstuk.

Ik zei tegen mezelf: hier wil ik de toekomst voorspellen. Toen dacht ik: nee, dat gaat niet werken. De toekomst voorspellen is niet erg verstandig. Omdat ik een soort geschiedenis van softwareontwikkeling vanuit mijn persoonlijke perspectief had geschreven, besefte ik dat ik vooral geïnteresseerd was in hoe geschiedenis je kan helpen je op de toekomst voor te bereiden, niet in het voorspellen van die toekomst.

Daarom heb ik stappen gezet om je voor te bereiden. De eerste is proberen historische patronen te begrijpen. Wanneer ik tegenwoordig iets schrijf, ga ik daarom terug en kies ik een stukje geschiedenis. Ik schreef onlangs iets over gestructureerde methoden en wat ik de monumentale methodologie van de jaren tachtig noem, om mensen te laten zien dat dit niet de eerste keer is dat dit soort dingen gebeurt. AI beweegt al dertig of veertig jaar op en neer tussen hypecycli en rustige periodes.

Veel mensen hebben geen gevoel voor geschiedenis, en ik denk dat dit kan helpen. We moeten de mentaliteit en de cultuur veranderen en betere manieren vinden om dat te doen. Er zijn zoveel boeken geschreven over verandermanagement, vanuit zoveel verschillende perspectieven. We botsen op wat het betekent om mens te zijn. Misschien doen we het zo goed als we kunnen, maar misschien zijn er dingen die we kunnen verbeteren.

Zoals ik al zei, denk ik dat een manier om ons op de toekomst voor te bereiden het opnieuw ontwerpen van de organisatie is. Daar hoort het platter maken van de organisatie bij. Ook moeten managers en medewerkers de juiste training en ervaring krijgen. We zullen de opleiding moeten opschalen.

Er is niet langer een carrièrepad; het is een hindernisbaan. Ieder van ons is verantwoordelijk voor het uitstippelen van een route door die hindernisbaan. Stel dat ik naar de toekomst kijk en zeg: ik moet meer weten over AI. Waar begin ik? Waar moet ik naar kijken? Hoe vind ik mensen die goede informatie kunnen geven? Welke lessen moet ik volgen?

Ik zag onlangs dat cursus C een basiscursus AI aanbiedt. Vorig jaar volgden 5.000 mensen die cursus. Dit jaar hebben al 400.000 mensen hem gevolgd. Waar halen we die kennis vandaan en hoe doen we dat? We moeten onze verbetering van bekwaamheden versnellen. Nogmaals: bekwaamheid is kennis plus ervaring plus besluitvorming.

Hoe doen we dat beter? Alleen kennis opdoen is niet genoeg. Ik maakte me vroeger zorgen over certificeringen en de wildgroei aan certificeringen in onze sector. Ik heb er nog steeds bedenkingen bij, maar ik ben ze gaan zien als verkennerinsignes.

Ik heb ook zulke insignes. Ze laten alleen zien dat ik een beetje basiskennis heb opgedaan. Ik trek certificeringen dus niet meer echt in twijfel, hoewel ik soms moet lachen om iemand met negentien certificeringen achter zijn naam. Technologie wordt opnieuw nog belangrijker.

Er is nog een boek over de komende golf. Dat gaat niet alleen over AI, maar ook over biotechnologie. Die twee zullen elkaar beïnvloeden. Als je bijvoorbeeld een AI-engine hebt die gericht is op celmanipulatie en biologische instrumenten goedkoper kunnen worden gemaakt, krijg je al snel op veel niveaus de mogelijkheid tot genetische manipulatie.

Als dat niet net zo beangstigend is als AI. Er zijn dus allerlei technologische ontwikkelingen. Of je nu projectmanager, middenmanager, topman of CIO bent: je hebt technisch begrip en technische kennis nodig. Dat betekent niet dat je een computer moet kunnen programmeren, maar wel dat je meer technische achtergrond nodig hebt dan ooit tevoren.

Galen Low: Besluitvorming op basis van onze ervaring en kennis is de manier waarop we altijd vooruit zijn gegaan. Wat ik daar verfrissend aan vind, is dat we praten over AI als een spook dat plotseling is verschenen, terwijl het al dertig jaar bestaat.

We praten over grondwetten en over hoe we in het verleden verandering hebben aangepakt — niet noodzakelijk Agile veranderen, maar de manier waarop we samenwerken, communiceren of de principes en mentaliteiten waarop we vertrouwen veranderen. Zijn we daar goed in geworden? Nee. Worden we deze keer goed door alleen naar Agile te kijken? Nee. Maar het maakt allemaal deel uit van dezelfde oefening.

Jim Highsmith: We doen het stap voor stap beter.

Galen Low: Ja. Stap voor stap beter. We krijgen de machine die zichzelf refactort. En dan voeren we comfortabel tweewekelijkse biotechnologische genetische sprints uit. Elke twee weken brengen we een nieuw wezen uit.

Jim Highsmith: Ik kom terug op mijn vriend Gerald Weinberg, die in de jaren tachtig een boek schreef met de titel Secrets of Consulting. Hij zei: als je een organisatie binnengaat en denkt dat je haar met meer dan 10% kunt veranderen, houd je jezelf voor de gek.

Galen Low: Dat is volkomen terecht. Ik vind dit echt geweldig, Jim. Bedankt dat je bij ons te gast wilde zijn. Er zitten zoveel waardevolle inzichten in. We zouden je graag nog eens uitnodigen. Je had het over een kader rond de ontevredenheid over Agile.

Daar zouden we graag dieper op ingaan. Voor nu hebben we onze luisteraars volgens mij een stevig stuk inhoud gegeven en ik waardeer het enorm.

Jim Highsmith: Bedankt. Ik heb ervan genoten en zou het graag nog eens doen.

Galen Low: Voordat ik je laat gaan: waar kunnen mensen je meest recente boek vinden?

Jim Highsmith: Bij elke boekverkoper. Het heet Wild West to Agile. Het is voor de helft een geschiedenis van softwareontwikkeling en voor de helft een persoonlijke memoires.

Galen Low: Dat vind ik geweldig. Fantastisch. Ik neem het op in de shownotities hieronder.

Jim Highsmith: Bedankt.

Galen Low: Goed mensen, daar hebben jullie het. Zoals altijd: als je wilt deelnemen aan het gesprek met meer dan duizend gelijkgestemde kampioenen van projectmanagement, kom dan bij onze community! Ga naar thedigitalprojectmanager.com/membership voor meer informatie. En als je vandaag hebt genoten van wat je hoorde, abonneer je dan en blijf in contact via thedigitalprojectmanager.com.

Tot de volgende keer, bedankt voor het luisteren.