Niet leren, leren, leren en lezen, en toch Agile willen zijn?

Wat heb je aan lezen en leren als je als organisatie beweert Agile te (willen) zijn? En hoe operationaliseer je leren en hoe weet en meet je of de leerervaring lijdt tot verbeteringen? Om te beginnen een paar zaken en ervaringen die ik wil delen.
- Ik begeleid al jaren HBO-studenten tijdens afstudeerstages, en op mijn vraag “Heb je de kennis van boek x gebruikt om toe te passen in fase y van je project?” is het antwoord steevast “Uh, Boek x, nee, zegt me niks. Ik heb geen boek gelezen.”
- Of collega’s die zeggen “Oh, een boek, nee dat is alleen maar theorie”
- De vernieuwingen in onderwijsland, wie heeft gelijk? Waarom is de leesvaardigheid van 10-jarigen laag (onderzoek verricht door de IEA, International Association for the Evaluation of Education Achievement) evenals die onder 15-jarigen (onderzoek PISA meting, een driejaarlijks vergelijkend onderzoek onder 60.000 leerlingen uit 77 landen naar de onderwijsresultaten.). En de effecten daarvan op het functioneren in het werkzame leven, ook een automonteur moet een handleiding en instructie kunnen lezen.
- “Onderwijskundigen omarmden denk-modes over het autonome kind, dat ‘eigenaar van zijn eigen leerproces’ moet zijn en ‘ontdekkend’ moet leren, terwijl er geen wetenschappelijk bewijs is dat zulke methodes werken. Methodes waarvoor dat bewijs wel bestaat, ‘expliciete instructie’ bijvoorbeeld, werden terzijde geschoven als ouderwets en autoritair.” (Bron: Sezgin Cihangir, 2023 13 december, Lezen is geen luxe tijdverdrijf, NRC, geraadpleegd op 13 december 2023, https://www.nrc.nl/nieuws/2023/12/11/lezen-is-geen-luxe-tijdverdrijf-a4183902)
- Lees ook eens het boek Jongens zijn slimmer dan meisjes, 35 mythes over leren en onderwijs, van Pedro de Bruyckere, Paul Kirshner en Casper Hulshof. En lees dan eens, als voorbeeld, de uiteenzetting over de mythe rondom leerstijlen. En ga vervolgens maar eens op zoek naar organisaties die hun leer-aanbod op basis van de leerstijlen van Kolb hebben ontwikkeld en aanbieden.

Kortom, leren en lezen hebben veel met elkaar te maken. En leren is een ingewikkeld proces. Maken we nu de overstap naar de wereld van, voornamelijk, ICT. Stap bij een willekeurig ICT-bedrijf of ICT-afdeling binnen en 9 van de 10 keer vallen dan de woorden agile en scrum. Of varianten daarop. Raadpleeg vervolgens de literatuur over deze twee begrippen en dan stuit je naast de praktijk van Lean, Six Sigma regelmatig op de termen continu verbeteren. En empirisme, één van de elementen van SCRUM staat hoog in het vaandel van organisaties die beweren dat ze ‘scrummen’ of ‘lean-agile’ of ‘scrum-agile’ bezig zijn. In scrum wordt dan ook nog een zogenaamde retrospective gehouden als moment om mogelijke verbeteropties te ontdekken. Veelal een sessie doorspekt van meningen en misvattingen.
Overigens, bedenk ook dat veel niet-ICT organisaties deze terminologie en methoden hanteren. Denk maar eens aan de zogenaamde dagstart die je bij veel organisatie terug ziet.
Maar nergens is in de werkwijze een leer-proces ingebakken waarin kort-cyclisch, op basis van kennis, teamleden op inhoud komen tot fundamentele inzichten. Nergens wordt er naar bewezen en gedocumenteerde kennis gezocht. Want welke houding je ook inneemt als ‘agile-coach’ of ‘scrum-master’(zie mijn eerdere artikel https://strategiewerkt.blogspot.com/2023/12/de-spagaat-van-de-coach-in-de-scrum.html), het is belangrijk dat je op onderbouwde wijze een interventie pleegt. En er een manier is om het resultaat van de interventie in termen van leren kunt meten.
Innovatie in de wereld van ‘agile-teams’ kan mijn inziens worden bereikt door onderwijskundige principes toe te passen in expliciete kortcyclische leermomenten die veel verder gaan dan retrospectives. Kies er eens voor om op regelmatige basis inhoud te doceren, medewerkers te dwingen om tijd te nemen om kennis op te doen. Plan het in, meet de effecten en pluk de echte vruchten van het woord Agile.

De spagaat van de coach in de scrum wereld.

De agile-coach. Wie kent m niet? Luis in de pels? Je hebt er niks aan? Wat moet ik er mee? De scrum master? Wat is dat dan? Wat doet die dan? Agile teams? Agile-scrum, dat hoor ik ook wel eens. Je kunt er cursussen voor volgen, examens in afleggen en boeken kopen. Je kunt ze inhuren en in dienst nemen. En altijd is het een zoektocht naar de waarde van de functie. En ieder vogeltje zingt dan zoals het gebekt is. En iedereen doet maar wat. Cherry-picking, er uit pakken wat je leuk lijkt. Gewoon maar van alles op een hoop gooien en door de mixer halen. Maar wat blijft er dan over van de oorspronkelijke ideeen? Waar houden we ons dan aan vast? En wat maakt dat we succesvol zijn in de toepassing van een filosofie, een overtuiging of methode?

Een opdracht die ik recent heb uitgevoerd confronteerde mij met bovenstaande vragen en dilemma's. Er waren veel verschillende verwachtingen over de taken die ik moest uitvoeren onder de titel 'scrum master'. Na toetsing van mijn beeld over de rol gedurende een aantal weken bleek uiteindelijk dat ik niet aan de verwachtingen kon voldoen. Ik heb toen afscheid genomen van de situatie.

Maar .... het bood wel een mooi leermoment en triggerde me om me nog maar weer eens te verdiepen in het fenomeen van coaching, in de wereld van IT. Vervolgens ben ik met een aantal collega's en bekenden in het onderwerp gedoken. Raadpleegde literatuur en bezocht diverse bijeenkomsten die over het onderwerp gingen.
Een aantal eigen conclusies en wetenswaardigheden wil ik bij deze delen.
1. Citaat uit de scrumguide 2020 "Het basisontwerp of ideeën van Scrum aanpassen, het weglaten van elementen of de regels van Scrum niet volgen, verbergt problemen en beperkt de voordelen van Scrum en maakt het potentieel zelfs nutteloos. Veel organisaties laten elementen weg of volgen de regels niet. Is dat erg? Niet direct. Je hoeft niet altijd naar de letter van de wet te leven, maar wees je bewust van de keuzes, benoem ze of zeg niet dat je scrumt.
2. Citaat uit de scrumguide 2020 "Binnen het Scrum raamwerk kunnen diverse processen, technieken en methoden worden toegepast." Scrum gebeurtenissen, de artefacten en de rollen worden meestal wel ingevuld. Maar het schort vaak aan de processen, technieken en methoden. Die raken op de achtergrond. Daar is meer winst te halen dan met de basala invulling. Hoe analyseer je, hoe schat je, hoe stel je een architectuur op, hoe is kennis vastgelegd, hoe snel kun je software aanpassen, is de software van hoge kwaliteit, welke testmaat gebruiken we? Vragen die belangrijker zijn dan je druk maken over story points en user stories.
3. De rol van de scrum master. De scrum guide gebruikt letterlijk twee keer het woord coachen. Nl. "Het coachen van teamleden in zelfsturing en multidisciplinair werken" & "Het leiden, trainen en coachen van de organisatie in haar Scrum adoptie". Maar gebruikt ook de woorden "helpen", "zorgdragen", "in te zien", "begrijpen", "adviseren" en "faciliteren". Maar hoe bepaal je dan in welke situatie je welk werkwoord je toepast? Hoe kun je dan je eigen gedrag aanpassen? Welk referentiekader gebruik je dan? Om in metaforen van de voetbalsport (of welke andere sport dan ook) te spreken, ben je dan trainer, coach of manager. Mag je alleen spiegelen op foute passes? Kiest het team wie ze laat invallen? Mag je iemand wel of niet buiten de selectie plaatsen? Welke spelers koop je? Dan helpt het in de scrum-wereld, of agile wereld, om onderstaand referentiekader (Typical Role Statements from the Consulting Role Grid (Champion, Kiel, & Mclendon, 1990) tegen de muur te plakken en helder te hebben welke houding je in neemt als scrum-master. En niet alleen de scrum master kleur bekent, maar de rest van het team ook.

4. De weeffout in scrum. En als we de wereld van de vele coachings-buro's onder de loep nemen dan zien we dat de coach geen onderdeel is van het team. Niet meewerkt en niet meetimmert aan de totstandkoming van een product. En dat is in de scrum-wereld wel zo. Kun je dan coachen? Of moeten we dit anders inrichten?