Shu-Ha-Ri: een pad naar meesterschap

Als Agile Scrum coach en trainers krijgen we vaak de vraag hoe het beste met Agile Scrum in een organisatie gestart kan worden? Organisaties functioneren vaak al volgens een bepaalde structuur en verandering kan dan moeilijk zijn. Bij het invoeren van een nieuwe werkwijze worden al snel concessies gedaan en compromissen gesloten tussen de oude en de nieuwe werkwijze. En juist deze compromissen kunnen ervoor zorgen dat een verandering moeilijk voet in de aarde krijgt. Daarom adviseren wij om bij het Shu-ha-ri principe toe te passen.

 

Shu-ha-ri komt uit de Japanse vechtkunst en heeft als doel de leerling tot meester te maken bij het uitoefenen van vaardigheden en hun denkwijze. Deze groei tot meesterschap bestaat uit drie fases, namelijk de Shu-fase, de Ha-fase en de Ri-fase.

 

———

 

Shu: Voorbereiden van lichaam en geest

De leerling doet in deze precies wat de leraar hem voorschrijft. Het oefenen en testen van de voorgeschreven regels en voorbeelden van de leraar zorgen ervoor dat lichaam en geest de basis ervaren. In deze fase worden de regels nauwgezet gevolgd en volgt het principe dat er slechts één weg naar meesterschap is. Ook al zijn er in principe andere mogelijkheden, deze worden op dit moment nog niet verkend.

In Agile Scrum betekent dit dat het Scrum Framework volledig volgens de regels wordt toegepast. Ook al wordt op dit moment anders gewerkt in de organisatie. Alleen op deze manier kan volledig ervaren worden hoe het Scrum Framework bedacht is. Hoe je als team dit kunt laten werken, zonder dat meteen de hele organisatie om moet, is hier de uitdaging.

 

Ha: Verder zoeken en zichzelf verbeteren

Als de basis volledig bekend en ervaren is, dan is het tijd dat de leerling vragen gaat stellen. Waarom werkt het zo? Moet ik het wel op deze manier doen? Wat is het precieze idee erachter? Zijn er andere, misschien betere manieren om dit te doen?
Het doel van deze fase is om het vertrouwde los te laten of in een ander licht te plaatsen en nieuwe mogelijkheden gaan zien. Door de basis uit de Shu-fase brengt de leerling een goedgevulde rugzak mee om zijn proces te reflecteren. Deze reflectie levert zelfkennis op en draagt erbij om na te denken op welke punten het wellicht verstandig is om af te wijken van de basis.

 

In Agile Scrum betekent dit dat gekeken wordt naar welke zaken van het Scrum Framework goed en welke minder goed bij de organisatie passen. Hoe ga je plannen, ga je story points gebruiken, of gebruik je bijvoorbeeld helemaal geen estimation. Kortom het is tijd om te reflecteren en aan te passen waar nodig.

 

Ri: Het geleerde toepassen en doorgeven aan anderen

In deze fase staat de leerling op de schouders van de leraar en ontwikkelt zijn eigen zienswijzen. Het doel is om te overstijgen. De leerling is volledig zelfbewust en begrijpt wanneer op welk moment bepaalde zaken moeten worden ingezet. Hij test deze in de praktijk van het dagelijkse leven en kan anderen hierin onderwijzen. De leerling is leraar geworden.

 

In Agile Scrum zou dit kunnen betekenen dat er hele nieuwe Agile methodes worden ontwikkeld. De mindset en het gedachtegoed worden volledig begrepen en er wordt geëxperimenteerd met nieuwe manieren van werken en getest op de werkvloer. Ook kunnen nieuwe medewerkers en opdrachtgevers duidelijk uitgelegd worden hoe en waarom een organisatie op deze manier werkt.

 

——-

Ga je dus aan de slag met een nieuwe werkmethode zoals bijvoorbeeld Agile Scrum? Wees je dan bewust van de lessen uit de oosterse vechtkunst. Probeer eerst volledig te ervaren hoe deze methode is opgezet, voordat je gaat afwijken. Groei vervolgens door zelfreflectie en experimenteer in de praktijk tot een vorm die volledig past bij jouw team of je bedrijf.

 

In welke fase (Shu, Ha of Ri) bevindt jij of jouw team zich? En welke uitdagingen komen jullie hier tegen?

, ,

Scrum Master is dat een full-time job?

Hoe staat het er ook alweer voor met mijn Scrum Master taken? Het was weer een drukke sprint en ik moet eerlijk bekennen dat ik het overzicht een beetje kwijt ben, er is gewoon zoveel development werk dat gedaan moet worden en ik ben natuurlijk buiten mijn Scrum Master rol ook één van de meest ervaren developers, dus moet ik wel programmeren om het tempo erin te houden…

Herkenbaar?

Wij zien binnen bedrijven waar wij coachen dat er zeer verschillend naar de Scrum Master rol wordt gekeken en dat in deze bedrijven, het altijd een onderwerp van discussie is: Werken we met full time Scrum Masters of niet? En hoeveel teams kan een Scrum Master dan hebben?

Vaak zie je hierin het volgende zienswijze van de manager over een full-time Scrum Master:

  1. Dan hebben we minder mensen die hands-on aan het product bezig zijn
  2. Het is teveel overhead
  3. Dit kan ik niet betalen

Vaak wordt er hierbij onderschat hoeveel tijd het kost in een team als ze niet in flow zijn en samen niet effectief tot beslissingen komen. (Denk hierbij bijvoorbeeld aan ineffectieve communicatie) De vraag is dus: Hoeveel/wat kan een full-time Scrum Master onze organisatie opleveren? En dit antwoord kan per organisatie of zelfs per team verschillen.

Mike Cohn (een van mijn favoriete Agile bloggers) heeft hier een mooi voorbeeld van waarbij hij aanhaalt dat zeker elk team baat zou hebben bij een fulltime Scrum Master maar dat het economisch ook zeker niet voor elk team verantwoord is om dit te doen. Mijn stelling is dan ook niet dat bij elk bedrijf elk team een fulltime Scrum Master nodig heeft.

Mijn visie is dat Scrum Masters zich sneller kunnen ontwikkelen wanneer ze  zich fulltime bezig kunnen houden met Scrum Master zijn.  Daardoor ontwikkelt ook het zelforganiserende en het resultaat van de teams en de organisatie hier omheen sneller. Naar mijn inziens dient er een bewuste keuze gemaakt te worden en door te experimenteren, te reflecteren en aan te passen uiteindelijk bij de juiste fit voor jouw bedrijf te komen.

Punten om mee te nemen in de visie op Scrum Masters zijn:

  1. Werken we met full time Scrum Masters?
  2. Hoeveel tijd heeft een Scrum Master per team nodig?
  3. In welk stadium van zelforganiseren bevinden onze teams zich? (in het begin zal een Scrum Master veel tijd hieraan moeten besteden. Als dit niet gebeurt kan de voortgang afremmen waardoor ze altijd afhankelijk zullen blijven)
  4. Heeft één Scrum Master één team of meerdere teams?
  5. Welke verantwoordelijkheden liggen bij de Scrum Master?
  6. Hoe creëren we ruimte en een cultuur om deze Scrum Masters zich te laten ontwikkelen?
  7. Ondersteunt de Scrum Master alleen het development team of ook de Product Owner en de organisatie?

Hoe kijkt jouw organisatie aan tegen bovenstaande vragen?

Mijn mening is; ga het gesprek open aan tussen Scrum Master en management en creëer een visie. Betrek de Scrum Masters in het ontwikkelen van deze visie. Ben je nog niet zeker van de juiste beslissing? Bedenk een experiment en een looptijd hiervan om het samen te testen. Ga empirisch werken en ondervindt zo samen wat wel, maar ook wat niet werkt. Geef dus tijd en ruimte om deze visie ook uit te dragen aan je Scrum Masters. Reflecteer samen en geef voldoende ontwikkelingsmogelijkheden om te groeien in de Scrum Master rol en dan zal de organisatie verrast zijn hoe een Scrum Master het leven binnen de organisatie makkelijker en leuker kan maken 😊

Volgende keer het laatste deel van deze 3-delige reeks over Scrum Masterschap. Tot dan!

Doe de test: Zijn jullie een écht team?

In Scrum word vaak gesproken over teams. Sterker nog, in Scrum vinden we teams zo belangrijk dat we eigenlijk het liefst “Dedicated Teams” willen zien. Wat betekent dat de leden van het team ook echt genoeg inzet kunnen tonen voor het betreffende team. Dit wordt erg lastig wanneer je bijvoorbeeld in twee teams zit of parttime werkt.

Maar wat maakt een team nou eigenlijk een team? En wat zijn de verschillen tussen een team en een werkgroep?

Volgens David Wolcott Johnson in zijn boek “Groepsdynamica” zijn niet alle groepen ook daadwerkelijk teams en zijn teams juist een van de vele mogelijke groepen waar iemand zich in kan bevinden.

Je bewust zijn van in wat voor een situatie je je bevindt, en daar ook je verwachtingen en verantwoordelijkheden op aanpassen, zal zorgen voor een gezondere samenwerking. Het geeft een helderder beeld voor zowel jezelf als de mensen met wie je samenwerkt rondom wat je wel en niet van elkaar kunt verwachten en waar jullie je mogelijk in kunnen verbeteren.

Voor je kunt stellen dat je in een team werkt zijn er 5 vragen die je jezelf of je teamgenoten kunt stellen:

1.      Zijn jullie je bewust van de afhankelijkheid die jullie onderling naar elkaar hebben om het doel van het team te kunnen realiseren?

2.      Hebben jullie contact met elkaar? Daarnaast, wat vinden jullie van de manier waarop jullie contact hebben met elkaar?

3.      Is het wel helder voor alle leden wie er in het team zitten?

4.      Zijn er verschillende, doch specifieke rollen en functies in het team?

5.      Is er een eindpunt op de horizon? Hebben jullie wel lang genoeg de tijd samen om echt een team te vormen?

Als je op al deze bovenstaande vragen ‘ja’ hebt kunnen antwoorden dan kun je spreken van het werken in een team. Andere duidelijke verschillen tussen een groep en een team zitten hem in :

Het nemen van verantwoordelijkheid voor het gehele product en het meten van de effectiviteit van het team word ook gedaan op basis van de door het team geleverde producten. Terwijl we bij een groep juist uitgaan van meer indirecte manier van voortgang meten. Denk hierbij bijvoorbeeld aan hoeveel invloed de groep op anderen heeft.

De missie van een team is specifiek, duidelijk omgeschreven en daarnaast ook toegespitst op de verantwoordelijkheden van het team. Terwijl als we spreken van een groep de algemene missie van de organisatie ook voor de groep het doel vormt.

Verantwoordelijkheid in een team staat zowel voor je eigen individuele gedeelte als voor het gehele resultaat van het team. Waarbij we in een groep ervanuit uitgaan dat je alleen verantwoordelijk bent door je eigen individuele aandeel in het geheel.

Ik hoop dat deze korte punten jullie kunnen helpen met identificeren of je je op dit moment dus in een groep of team bevindt. Er zijn kleine doch wezenlijke verschillen die absoluut invloed kunnen hebben op het succes van beide samenwerkingsverbanden.

Er is nog een heleboel te vertellen over teams en werkgroepen. Graag ga ik de volgende keer verder in op wat voor een verschillende teams er zijn en hoe situatiewerkwijze en activiteiten invloed hebben op welk soort team je bent en wat de subtiele verschillen zijn.

Bewust zijn van waar je bent en hoe er verwacht word met elkaar om te gaan geeft een goed startpunt weer vanuit waar je als team, of werkgroep, stappen kun maken om nog beter te worden!

Ik ben heel nieuwsgierig; werken jullie op dit moment in een team of in een werkgroep? En welk van de punten heeft jullie geholpen om te signaleren welke vorm van samenwerking je op dit moment doet?

Bedankt voor het lezen en tot de volgende keer, dan dus meer over teams!

Met vriendelijke groet,

Lars Liebrand