Afbeelding kat

Zelf organiseren is ook zelf oplossen

Print Friendly, PDF & Email

Waarom niets doen vaak beter is dan een interventie plegen. Dat gaat mogelijk tegen onze natuur in. Zeker wanneer we zien dat er iets fout dreigt te gaan. Want in je achterhoofd denk je aan de stakeholders die een verwachting hebben over wat er uit ‘de fabriek’ komt op een bepaald moment. Dan ben je geneigd om in te grijpen en te sturen. Lees in deel 1 van deze blog wat ik heb geleerd van WEL ingrijpen in een zelf organiserend team. Daaruit blijkt dat dat niet altijd de juiste keuze is bij het scrummen, als het ontwikkelteam zelf verantwoordelijkheid draagt over wat er wordt ontwikkeld en over het behalen van het sprintdoel. Zij organiseren zichzelf, dus het devies is: grijp niet in en laat het ze zelf oplossen. Lees wat ik heb geleerd van NIET ingrijpen.

Waarom ik NIET ingreep

Uit de periode dat ik wel ingreep gedurende een sprint heb ik geleerd dat het veel extra tijd kost en dat het ontwikkelteam het ervaart als bemoeienis. Dus geen interventies meer, maar het team zelf hun problemen laten oplossen. Ik heb daarom besloten om me meer terughoudend op te stellen naar het ontwikkelteam toe. Ook was ik niet meer bij elke Daily Scrum meeting aanwezig. Waarom zou ik? Het is hun verantwoordelijkheid om de product increment te maken op hun manier binnen de timebox van de sprint. Met gepaste afstand zag ik de probleemsituaties nog steeds voorbijkomen (transparantie) en door het team worden besproken, maar heb me er niet mee bemoeid.

Tot mijn plezier bleek dat aan het eind van de sprint vaak het sprintdoel gehaald werd. Het oplossend vermogen van het team was groot waardoor ogenschijnlijke problemen gedurende de sprint netjes werden opgelost, zonder concessies te doen aan functionaliteit of kwaliteit. De teamleden leerde van elkaar en van elke iteratie. Als extra bonus kwam het ontwikkelteam vroegtijdig naar mij toe in situaties wanneer het sprintdoel niet gehaald zou gaan worden. Dat kwam weinig voor. Samen vonden we dan een oplossing waarbij ik als Scrum Master een rol had in communicatie naar stakeholders toe.

Ben de coach

Zie je een noodzaak om te sturen, prima, doe dat dan na afloop van de ontwikkelactiviteit aan het einde van de sprint. Maak dus goed gebruik van de Agile rituelen die elke sprint staan gepland om terug te kijken op de ontwikkelactiviteit. Geef feedback op de product increment en de waarde die het oplevert (outcome). Coach het team in het continue streven naar het leveren van waardevolle verbeteringen van het product.

De sprint retrospective geeft je alle ruimte om samen te bespreken hoe de product increment tot stand is gekomen. Volgens de scrumgids past dit in het verband van zelforganisatie.

‘Tegen het einde van de Sprint Retrospective zou het Scrum Team verbeteringen moeten hebben benoemd die geïmplementeerd zullen worden in de volgende Sprint. Het implementeren van deze verbeteringen in de volgende Sprint is de aanpassing naar aanleiding van de inspectie van het Scrum Team zelf.’

Dit is dus het moment om de situaties te bespreken die zich tijdens de sprint hebben voorgedaan en hoe deze door het team zijn opgelost. Wat vinden we daarvan? Hoe kunnen we het voorkomen of een volgende keer effectiever oplossen? Wederom, coach het team in het zorgvuldig uitvoeren van deze inspectie om zinvolle aanpassingen te doen in toekomstige sprints. Daarvan groeit het team naar ‘high-performance’.

Er kan altijd iets onverwachts gebeuren gedurende een sprint dat effect heeft op capaciteit en functionaliteit. Om dergelijke situaties te voorkomen is het zaak als Scrum Master om scherp te zijn op het resultaat van de planningsbijeenkomst. De Scrumgids zegt:

Aan het einde van de Sprint Planningsbijeenkomst zou het Ontwikkelteam in staat moeten zijn om aan de Product Owner en Scrum Master uit te leggen hoe zij van plan zijn, als zelf organiserend team, het Sprintdoel te behalen en het verwachte Increment te realiseren.

Stimuleer het team om de uitkomsten van de sprint review en sprint retrospective te gebruiken in de planningsbijeenkomst van de volgende sprint. Ik vertel hier waarschijnlijk niets nieuws over hoe deze scrumrituelen worden ingezet, maar ik wil benadrukken dat het de juiste plaats is om te sturen indien nodig.

Alles onder controle

Een collega van een andere afdeling vroeg regelmatig aan mij “En…alles onder controle?”. In het kader van transparantie geef je eerlijk antwoord. Toen ik nog wel ingreep tijdens het ontwikkelproces en met het idee een bepaalde controle te hebben over het eindresultaat, was het antwoord toch vaak ‘nee’. Dat kwam vooral doordat ik druk was met het willen oplossen van problemen voor het ontwikkelteam.

Toen ik niet meer ingreep tijdens het ontwikkelproces en het idee van controle had losgelaten, was het antwoord bijna altijd ‘ja’. Hoe komt dat nou? Teamleden voelden zich eigenaar van de increment, voelde zich daar 100% verantwoordelijk voor en zij kregen een grote verbondenheid met het product. Daar was niet meer die Scrum Master die ging ‘helpen’ met het oplossen van een probleem, dat kon het ontwikkelteam uiteraard zelf. Bovendien bleek vaak dat een potentieel probleem niet eens echt een incident werd, want het was opgelost voor het einde van de sprint. De scrumrituelen zijn de mechanismen om te sturen en vooral ook om te coachen en als team succesvol te zijn. Het antwoord is dan dus altijd: “Ja…alles onder controle.”

Foto: kantoor kat genaamd Jules