Praktijk van het gebruik van een persoonlijke rating van elk teamlid in de context van Scrum en SAFe

In dit artikel ben ik van plan te vertellen hoe wij in onze praktijk een persoonlijke rating van elk teamlid in Scrum toepassen tijdens het werken volgens het framework SAFe

Waarschijnlijk zullen velen het ermee eens zijn dat (vooral in Rusland) mensen bij ons vrij vaak proberen zo weinig mogelijk te werken (het eindproduct leveren binnen hun competenties of door nieuwe te verwerven) en zo veel mogelijk geld te verdienen. Met de omvang van het bedrijf lijken de mogelijkheden daarvoor recht evenredig te groeien. Hiermee werken in de regel verschillende HR-mensen, die op allerlei manieren proberen een correct motivatiesysteem op te bouwen. Daar horen ook OKR's en zovoort bij. Over het algemeen lijkt dit alles gericht te zijn op de balans van de belasting van ieder binnen de corporatie en het comfort van alle betrokken groepen personen/teams van de corporatie. In dit artikel deel ik een metriek die ik zelf heb bedacht en in het team toepas. Zij maakt het, naar mijn mening, mogelijk om de inspanningen van HR'en en OKR's aan te vullen in de balans van de belasting binnen één concreet team of juist een disbalans te zien. Ook kan zij heel goed worden opgeschaald naar een team van teams, ik zie daarin geen bijzonder probleem.

Zo is het voor mij als Scrum Master soms vrij duidelijk dat de belasting in het team niet in balans is, de een werkt voor twee, de ander doet niets (dit zijn extreme vormen en natuurlijk een ernstig probleem, maar deze metriek toont ook niet alleen extreme vormen). Zo'n situatie overkwam mij en ik dacht na over welke metriek dit probleem helder zou kunnen belichten. Uiteindelijk resulteerde dit in een persoonlijke rating van elk teamlid.

Voordat ik de metriek zelf beschrijf, wil ik ook één heel belangrijk, naar mijn mening, idee noemen. Op dit moment ben ik daar absoluut zeker van.

Metrieken moeten worden gebouwd op basis van de gegevens die je toch al krijgt. Het verkrijgen van een metriek mag het team niet dwingen systematisch meer tijd te besteden en zijn proces van waardelevering aan te passen aan de metriek zelf. Hierover zal ik proberen meer te vertellen in een van de volgende artikelen.

Dus, een voorbeeld van een concreet geval. Natuurlijk gebruiken we een bord om User Stories door statussen te verplaatsen van DOR (Definition Of Ready) tot DOD (Definition Of Done). Dat is bij ons virtueel (d.w.z. het staat op internet via een link. Ons team is ook gedistribueerd en de standups vinden plaats via corporate Skype, juist met het bord op het scherm.

Voor een teamlid is het handig om zichzelf als deelnemer aan een User Story te zetten, zodat bij gebruik van het filter op zichzelf snel alleen die stories overblijven waarin hij op dat moment deelneemt (meestal gebruiken we dit filter tijdens de standups).

Hier wil ik ook een toelichting geven: dit betekent niet dat dit teamlid niet kan deelnemen aan andere stories (als bijvoorbeeld tijdens de standup iemand van de teamleden om hulp vraagt, kan hij heel goed deelnemer van een nieuwe story worden of omgekeerd, als hij voelt dat zijn deelname niet nodig is, kan hij ophouden deelnemer van een of andere story te zijn.

Dus om de rating van elk teamlid te berekenen, moeten we kijken op hoeveel SP elk teamlid invloed heeft. In ons geval heeft Arkadi invloed op 29 SP (stories 1, 2, 5, 6), Tatjana heeft invloed op 33 SP (neemt deel aan alle stories), Vasili op 23 SP (stories 1, 3, 5, 6).

Gesloten (DOD voltooid) bij Arkadi 5 van 29 SP, bij Tatjana 6 van 32 SP, bij Vasili 5 van 23. Met het sorteren heb ik lang geworsteld en ik kwam tot de volgende formule voor het vergelijken van twee teamleden (team[i] - het ene teamlid en team[j] - het andere teamlid):

Volgens deze sortering krijgen we de huidige rating van de teamleden in de volgende vorm.

• 1e plaats. Vasili (voltooid 5 van 23)
• 2e plaats. Arkadi (voltooid 5 van 29)
• 3e plaats. Tatjana (voltooid 6 van 32)

Laten we nu alle gegevens voor de sprint genereren. Stel dat de sprint 5 werkdagen duurt.

• 1 dag
  

  

  
  1e plaats: Vasili (0 van 23 verbrand)
  2e plaats: Arkadi (0 van 29 verbrand)
  3e plaats: Tatjana (0 van 32 verbrand)
  
• 2e dag
  

  

  
  1e plaats: Vasili (0 van 23 verbrand) dynamiek(1->1)
  2e plaats: Arkadi (0 van 29 verbrand) dynamiek(2->2)
  3e plaats: Tatjana (0 van 32 verbrand) dynamiek(3->3)
  
• 3e dag
  

  

  
  1e plaats: Vasili (5 van 23 verbrand) dynamiek(1->1->1)
  2e plaats: Arkadi (5 van 29 verbrand) dynamiek(2->2->2)
  3e plaats: Tatjana (5 van 32 verbrand) dynamiek(3->3->3)
  
• 4e dag
  

  

  
  1e plaats: Vasili (8 van 23 verbrand) dynamiek(1->1->1->1)
  2e plaats: Arkadi (8 van 29 verbrand) dynamiek(2->2->2->2)
  3e plaats: Tatjana (9 van 32 verbrand) dynamiek(3->3->3->3)
  
• 5e dag
  

  

  
  1e plaats: Vasili (23 van 23 verbrand) dynamiek(1->1->1->1->1)
  2e plaats: Tatjana (24 van 32 verbrand) dynamiek(3->3->3->3->2)
  3e plaats: Arkadi (21 van 29 verbrand) dynamiek(2->2->2->2->3)
  

Zo kunnen we met deze metriek de persoonlijke statistieken van elk teamlid opbouwen en hem helpen de juiste conclusies te trekken. Hier zien we bijvoorbeeld dat Vasili zijn tijd vanaf het begin zeer goed heeft gepland (d.w.z. bij de sprintplanning heeft hij met het team afgesproken welk werkvolume hij feitelijk ook heeft uitgevoerd.) Maar tegelijkertijd: had hij op een of andere manier de andere teamleden kunnen helpen? Misschien niet, maar het is de moeite waard om hierover na te denken voor de retrospective.

Bij Tatjana en Arkadi is het probleem ernstiger. Het is duidelijk dat zij vanaf het begin bij de sprintplanning met het team hebben afgesproken deel te nemen aan alle stories en feitelijk niet in staat waren de verplichtingen na te komen. Over de oorzaken is het ook de moeite waard om na te denken voor de retrospective. Misschien moet men minder voor zichzelf plannen, misschien competenties uitbreiden om alles gepland te kunnen doen, er zijn ook andere oplossingen mogelijk.

Zo kunnen we statistieken opbouwen, niet alleen over het hele team en niet alleen over één sprint, maar ook over specifieke deelnemers van het DEV TEAM over de hele tijd, en deze informatie gebruiken voor voortdurende verbetering van het team.

Tot slot wil ik bijzondere aandacht vestigen op het feit dat er vóór het gebruik van deze metriek al een voldoende hoog vertrouwensniveau bij het grootste deel van het team moet zijn. Ook zou ik willen aanraden sterk de nadruk te leggen op wat primair is: het ontbreken van overwerk en comfortabel werken.

Wij richten ons op het correct voorspellen van het resultaat, niet op de motivatie om over te werken om de 1e plaats te behalen. Uiteindelijk is deze metriek gericht op het verbeteren van het planningsvermogen van elk teamlid afzonderlijk.