ShuHaRi

Deze blog gaat over het deelgebied People analyse (zie 'de brillen van de business analist' voor de onderverdeling). Business analisten komen in aanraking met een grote diversiteit aan mensen (waaronder stakeholders, teamleden, managers, product owners, scrum masters, andere analisten etc.). Het kan analisten enorm helpen als ze zich beseffen dat mensen verschillende ervaringsniveaus hebben met betrekking tot diverse thema’s, zoals bijvoorbeeld requirements, ontwikkelingsmethodieken en –frameworks, analysetechnieken, etc.

 

Ik merk zelf vaak een verschil tussen mensen die nieuw zijn met een bepaald onderwerp en mensen die hier al langer mee te maken hebben gehad. Mensen die nieuw zijn met een onderwerp zoeken vaak naar handvatten en willen het liefst volgens een voorgeschreven aanpak (een soort stappenplan of heuristiek) werken. Ik zie dit zowel in projecten als in trainingen.

 

Op de projectvloer lopen vaak mensen rond die ‘Scrum volgens het boekje’ willen praktiseren. Na het behalen van hun PSM (Professional Scrum Master) denken ze dat Scrum de beste (of zelfs de enige!) manier is om waardevolle software op te leveren. Ze gebruiken geen ‘Sprint 0’ omdat die niet in de Scrum Guide voorkomt. Of er worden uitsluitend user stories gebruikt omdat dit in Scrum de meest gebruikelijke vorm is om requirements te beschrijven. Ook onderscheiden deze mensen geen aparte rol voor de eigenaar van de architectuur (de Architecture Owner) omdat die in Scrum niet bestaat. Maar is dat verstandig?

 

In praktijkgerichte trainingen hoor ik vaak dat mensen op zoek zijn naar handvatten waarmee ze hun taken effectiever en efficiënter kunnen uitvoeren. Maar ik kom ook geregeld cursisten tegen die in de voorbereiding op een examen klagen dat ze het ‘niet eens zijn met het boek’. ‘Moet ik dat nou anders leren dan hoe ik het altijd doe?’ krijg ik dan vaak te horen. Mijn reactie is een meestal een glimlach van herkenning. Het betreft mensen die soms al decennialang werkzaam zijn in het vakgebied en een ‘papiertje’ willen of moeten behalen voor bijvoorbeeld Requirements Engineering. Het betreft in dat geval een multiple choice-examen waar je antwoorden moet geven zoals de lesstof die voorschrijft. Meestal helpt het als ik de term ShuHaRi uitleg als iemand zich niet senang voelt om dingen te leren waar hij/zij niet achter staat. Shu, Ha en Ri zijn termen die afkomstig zijn uit Japan en geven de kennis-/ervaringsfase aan waarin iemand zich bevindt.  

 

Shu

Shu kun je letterlijk vertalen als ‘Leer’ of ‘Volg de regels’

In het Shu-stadium verkeert iemand die nieuw is met een onderwerp en die zich de basiskennis inclusief de bijhorende technieken en filosofieën (de eerder genoemde 'handvatten') nog eigen moet maken. Het doel in dit stadium is om een fundament te bouwen waar je later op kunt doorbouwen.

 

Ha

Ha betekent ‘Onthecht’ of ‘Breek met de regels’

In het Ha-stadium verkeren mensen die al geruime kennis van en ervaring hebben met een onderwerp. Ze doen dingen niet meer klakkeloos volgens een bepaalde theorie maar hebben daar vaak hun eigen invulling aan gegeven inclusief definities, werkwijzen, methoden en technieken. Vanuit hun eigen ervaring vragen ze zich voortdurend af of de dingen die ze horen of zien wel kloppen (in mijn ogen een prima eigenschap voor iedere analist!).

 

Ri

Ri is het laatste stadium en betekent ‘Excelleer’ of ‘Bepaal de regels’

In dit stadium heb je zó veel kennis en ervaring dat je de regels bepaalt m.b.t een thema. Het zijn vaak schrijvers van (internationaal) populaire boeken, artikelen en blogs. In volgende blogs zal ik regelmatig verwijzen naar deze personen (ze worden soms zelfs goeroes genoemd). Omdat systeemontwikkeling en business analyse relatief jonge vakgebieden zijn, vinden er nog steeds flinke ontwikkelingen plaats.

 

Terug naar de training. Iemand met veel ervaring bevindt zich meestal in het Ha-stadium. Als zo iemand basiskennis moet leren omdat hij/zij het papiertje wil behalen (omdat de markt daarom vraagt) dan is het logisch dat het moeite kost om dingen klakkeloos te leren. Het helpt dan meestal als de cursist zich beseft dat hij/zij zich weliswaar niet in de Shu-fase bevindt, maar dat het raadzaam is om sommige dingen tijdelijk, puur voor het papiertje, in het hoofd te stampen. Na zo’n foundation-training is het wellicht tijd voor passender Ha-trainingen.  

 

Ook op de projectvloer kan ShuHaRi (door business analisten) worden gebruikt om mensen ervan te overtuigen dat het vaak beter is om je niet te veel vast te klampen aan ‘het boekje’. In geval van Scrum is het boekje zó dun (zie vorige blog) dat een grote groep mensen dagelijks bezig is met het opvullen van de vele hiaten. Sommige van deze mensen durven te ‘breken met de regels’ (Ha) zoals die zijn vastgelegd in de Scrum Guide en zijn zelf een (empirische) ontdekkingstocht gestart welke dingen er wel en welke er niet werken in hun organisatie (in een bepaalde situatie). In plaats van (of parallel aan) je eigen zoektocht kan het verstandig zijn om ‘best practices’ toe te passen die door gerenommeerde schrijvers (in het ‘Ri’-stadium) zijn beschreven. Deze ‘tips & tricks’ zijn ontstaan op basis van jarenlange praktijkervaringen (met systeemontwikkeling in het algemeen en Scrum in het bijzonder). Iedereen in het vak loopt vroeg of laat immers tegen dezelfde dingen aan! Je kunt natuurlijk ook zelf blijven tobben en je strikt vasthouden aan de regels, maar de vraag is of je daar veel mee op zal schieten (zie onderstaande tekening).

 

 

In mijn volgende blogs zal ik regelmatig terugkomen op veelvuldig beschreven onderwerpen op het gebied van (agile) systeemontwikkeling plus de rol van de business analist.


vorige pagina