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?
Geen opmerkingen:
Een reactie posten