De Agile mentaliteit nader bekeken

Om Agile te kunnen werken, moet een meerderheid van de leden van een organisatie de juiste mentaliteit hebben om zo te voorkomen dat je niet verder komt dan het implementeren van een methode zoals bijvoorbeeld Scrum. In de literatuur hebben we het dan steeds over mindset. Ik worstelde met deze term totdat laatst iemand tegen me zei dat mindset niet meer en niet minder betekent dan mentaliteit. Het is interessant om te filosoferen wat die mentaliteit nu precies is. Het eerste dat in me op kwam was dat een agile mentaliteit niet is dat je, wanneer iemand wat tegen je zegt, boos wordt en je direct gaat verdedigen.

De Amerikaanse filosofe Martha Nussbaum beschrijft dat emoties en gedachten sterk aan elkaar gekoppeld zijn, als ik haar goed begrijp, veel meer dan we veronderstellen. Het prettige en bevrijdende aan deze argumentatie vind ik dat ik er nu meer aan kan doen. Het voert te ver om hier haar argumentatie te herhalen, zelf beschiijft zij die in vele honderden pagina’s, dus laten we het even voor aannemelijk accepteren en hier op verder filosoferen. Een emotie zo zegt zij houdt een oordeel in. In het geval van boosheid een oordeel op of de persoon die iets tegen mij zegt, of een oordeel van hetgeen hij zegt.

Het probleem is dat de boosheid een afwijzing inhoudt, op voorhand verwerpen we de inhoud van hetgeen de ander zegt, of, nog erger, we verwerpen de persoon in kwestie. Het vreemde is, dat de boosheid komt voordat we in staat zijn geweest om er goed over na te denken. Daarnaast hebben we met de boosheid in ieder geval de deur dicht gegooid voor terugkoppeling in de toekomst. We hebben een niet mis te verstane bijdrage geleverd aan het scheppen van een gesloten atmosfeer in het team en dat is nu in een Agile wereld niet de bedoeling.

Elke team moet een samenwerkend systeem worden dat steeds waardevoller gaat samenwerken voor de omgeving waarin zij verkozen heeft te opereren. Als de klanten succesvol zijn dan is het team dat ook. Boosheid sluit die deuren. Hoe bereiken we dat die mentaliteit een onderdeel van onszelf wordt? In ieder geval op twee manieren:

  1. Door het voorbeeld te geven, wanneer je boosheid voelt opkomen beheers je en kijk naar het oordeel dat onder de boosheid ligt. Is dit terecht, ga dan het gesprek aan en vertel waarom je dit zo vindt. Is het onterecht, ga dan ook het gesprek aan en luister, want door terugkoppeling ben je in staat om je talenten verder te ontwikkelen. Voorbeeldgeven spreidt zich als een olievlek uit waardoor het een onderdeel van de cultuur van de organisatie wordt.
  2. Door zorgvuldig feedback te geven. Wanneer je feedback geeft omdat je boos bent, dan moet je eerst kijken wat het onderliggende oordeel is. Pas wanneer je dat weet, kan je feedbacken. Trouwens feedback heeft altijd ten doel om de ander succesvoller te maken! Let op, de feedback moet ten doel hebben om mensen competenter te maken, niet om iemand te sturen!

De filosoof Schoppenhauer schreef dat om gelijk te krijgen je door moet drukken wanneer iemand boos wordt, omdat je dan kennelijk een gevoelig punt te pakken hebt. Dat vind ik een verkeerde mentaliteit. Wanneer er boosheid is, dan moet je die boosheid de gelegenheid geven om weg te stromen. Wanneer iemand boos op je reageert, zeg dan dat dit niet de bedoeling was en vraag om terugkoppeling van degene die dit oordeel over je uit. Accepteer het als een waardevolle terugkoppeling en ga eerst werken aan een goede relatie met de ander. Daarna kun je het nog een keertje proberen.

Door Agile kunnen we het straks weer over ‘echt’ projectmanagement hebben

De AGILE transformatie heeft de wijze waarop we producten en systemen ontwikkelen op een revolutionaire manier veranderd. Vooral in de IT heeft dit veel projectmanagers hun functie heeft gekost. Laten we eerlijk zijn, dat is maar goed ook. Want hoe het ging, daar lusten de honden geen brood van. De meeste projecten duurden langer, kostten meer en leverden slechts matige kwaliteit op. Een continue stroom van berichten over tegenvallende IT projecten bereikten ons via de media. Dat, zo zei men, lag allemaal aan projectmanagement. Ook de poging om met PRINCE2 projecten in een controlled environment te krijgen, is niet meer dan een loze salesbelofte gebleken. Het was ook niet zo vreemd dat toen de Agile methoden het levenslicht zagen men deze massaal omarmde. Projectmanagement heeft, zo hoor je steeds vaker zeggen voorgoed afgedaan.

MAAR ZO IS HET NIET GEGAAN!

Laat mij je deelgenoot maken van een andere geschiedenis over projecten en projectmanagers in de IT. Ooit was er SDM, de systems development methodology, een bijzondere kruising tussen een it-ontwikkelings- en een projectmanagementmethode. Eerst was er een informatie analist die een document opleverde, daarna kwam er een functioneel ontwerper die ook weer een document opleverde, dat document werd door de technische ontwerper vertaald naar een technisch ontwerp met daarin de programma’tain’tbeschreven die de programmeur maakte. De programma’tain’twerden dan door de ontwerpers getest, daarna door een gebruiker geaccepteerd en als je geluk had mocht een technisch beheerder, en niet te vergeten een functioneel beheerder daar ook nog iets over zeggen.

Al die verschillenden disciplines werden door grote organisaties ondergebracht in aparte afdelingen met een eigen manager erboven. Bij kleine organisaties was de afstand kleiner tussen de mensen, maar bij de hele grote banken en overheidsorganisaties waren het grote, soms wel meerdere afdelingen. Toen kwamen de projectleiders die werden verantwoordelijk om al die verschillende afdelingen te coördineren. Mijn punt is, dat die mensen eigenlijk helemaal geen projectmanagers waren, veeleer waren zij regelneven die de tekortkomingen van de staande organisatie moesten oplossen. Het waren pleisterplakkers. Dat de resultaten van de projecten tegenvielen lag niet aan hun, hoewel zij vaak de schuld kregen, maar aan de gebrekkige vorm van organiseren.

Toen kwam PRINCE2 een zeer geavanceerde beschrijving over de administratieve organisatie voor een groot en complex project. Ontwikkelt door de Britse overheid om dergelijke projecten succesvol te managen. Wat gebeurde er? De Nederlandse IT afdelingen hebben zich door sluwe opleiders laten misleiden en het als de oplossing geadopteerd voor hun tegenvallende IT projecten. Maar PRINCE2 was een oplossing voor een heel ander probleem dan organisaties hadden. Het gevolg is dramatisch geweest en heeft vele mensen van hun arbeidsvreugd en motivatie beroofd. Had men nagedacht over de wortel van het probleem – de gescheiden afdelingen – dan had men zich gerealiseerd dat projecten niet de oplossing waren, maar een andere manier van organiseren wel. Daarover later, terug naar de verziekende werking van PRINCE2.

Bovenop het verschillende afdelingenprobleem, waardoor je maar moeilijk een multidisciplinair projectteam kunt samenstellen, kwam de PRINCE2 methodiek met een projectmanager op het verkeerde niveau te liggen. Een project kan alleen succesvol worden gemanaged in een organisatie vanuit het niveau van de uiteindelijke klant, omdat er aan nagenoeg elk IT project een organisatorisch verandering zit, moet de projectmanager boven zowel de IT als de business staan. Een PID schrijven door een projectmanager van de IT afdeling is een hopeloze vorm van verspilling. We hebben nu twee foutieve oplossingen bovenop elkaar liggen, met als resultaat een grote TELEURSTELLING.

Toen kwam Agile, tezamen met LEAN. Het multidisciplinaire team, de squad, kan alleen functioneren als de organisatie het eerste probleem van de gescheiden afdelingen oplost. Slimme organisaties, zoals bijvoorbeeld de ING, hebben dat gedaan. Als je dat doet heb je geen mensen meer nodig die PIDS schrijven en volgens het PRINCE2 stramien allemaal verspillende managementactiviteiten uitvoeren. Het project is uit het team gehaald en we hebben de regelneven en pleisterplakkers niet meer nodig. De mensen die dit werk deden zijn nu productowners of scrummasters geworden en krijgen daar oneindig veel meer voldoening uit dat ooit te voren. Dat komt omdat ze nu werk doen dat waarde heeft.

Dit heeft nog een ander zeer positief gevolg, want nu kunnen we het weer over projectmanagement hebben. Over de echt hele grote en complexe veranderingen waarvoor we alles nog bijna opnieuw moeten uitvinden. Met de komst van Agile zal de projectmanagementwereld zich moeten herorienteren en opnieuw bewijzen dat zij instaat is om iets nieuws, wat nog nooit eerder in die combinatie is gedaan op een succesvolle manier te managen. Of zij daartoe instaat is, dat is nog maar de vraag. Want in de Agile wereld zit men ook niet stil. Het zal een strijd zijn, wie wint, dat is nog maar de vraag, maar in ieder geval kunnen we het nu weer hebben over ‘echt’ projectmanagement.

De Scrum Master zal uiteindelijk verdwijnen

Het is een prachtige gedachte: zelfsturende teams. De vraag is of het zal gaan werken. Ik denk dat wanneer het de Agile Leider lukt om binnen de organisatie de juiste mentaliteit te stimuleren dat dit wel degelijk zo zal zijn. Nu kan je een discussie starten om te zeggen dat zelfsturing eigenlijk zelforganisatie moet zijn, maar daar ben ik het niet mee eens. De gedachte dat er ergens een baas is (de CEO) die stuurt, is nog steeds een belemmerende overtuiging en getuigd van een nog niet volledig beeld van wat echte wendbaarheid is. Laten we nu eens uitgaan van de hypothese dat het management vertrouwen heeft in de scrum teams, en in de scrum of scrums.

Om een en ander te faciliteren heeft elk team een scrum master, die op zijn of haar beurt een of meerdere team kan hebben. De scrum masters halen impediments weg, dat doen alle leiders in de agile organisatie. Maar na verloop van tijd zijn er steeds minder impediments weg te halen. Helemaal wanneer de organisatie lean principes gaat toepassen. Is er in aanvang nog 1 scrum master per team, na verloop van tijd zullen scrum master meerdere teams hebben. Het is dan onvermijdelijk dat er steeds minder scrum masters in een organisatie zullen zijn. Deze ontwikkeling gaat door totdat er geen scrum masters meer nodig zijn. Daarom zal de scrum master uiteindelijk verdwijnen!

Een zeer blog, echter, je zal maar scrum master zijn.