Praxis der Nutzung des persönlichen Rankings jedes Teammitglieds im Kontext von Scrum und SAFe

In diesem Artikel plane ich zu erzählen, wie wir in unserer Praxis das persönliche Ranking jedes Teammitglieds in Scrum während der Arbeit mit dem Framework SAFe

Wahrscheinlich werden viele zustimmen, dass (besonders in Russland) unsere Leute recht häufig versuchen, weniger zu arbeiten (das Endprodukt im Rahmen ihrer Kompetenzen oder durch den Erwerb neuer zu liefern) und mehr Geld zu bekommen. Mit der Größe des Unternehmens scheinen die Möglichkeiten dafür direkt proportional zu wachsen. Damit arbeiten in der Regel verschiedene HR-nahe Leute, die auf alle mögliche Weise versuchen, ein korrektes Motivationssystem aufzubauen. Dazu gehören auch OKRs und so weiter. Im Allgemeinen scheint all dies auf die Ausgewogenheit der Belastung jedes Einzelnen innerhalb des Unternehmens und den Komfort aller interessierten Gruppen von Personen/Teams des Unternehmens abzuzielen. In diesem Artikel teile ich eine Metrik, die ich selbst erfunden habe und im Team anwende. Sie ermöglicht es, wie mir scheint, die Bemühungen von HR und OKRs um die Ausgewogenheit der Belastung innerhalb eines konkreten Teams zu ergänzen oder entsprechend ein Ungleichgewicht zu erkennen. Außerdem kann sie durchaus auch auf ein Team von Teams skaliert werden, darin sehe ich kein besonderes Problem.

So ist es für mich als Scrum Master manchmal ziemlich offensichtlich, dass die Belastung im Team nicht ausgewogen ist, jemand arbeitet für zwei, jemand macht nichts (das sind Extremformen und natürlich ein ernstes Problem, aber diese Metrik zeigt nicht nur Extremformen). Bei mir ist eine solche Situation eingetreten, und ich dachte darüber nach, welche Metrik dieses Problem deutlich hervorheben könnte. Letztendlich mündete dies in ein persönliches Ranking jedes Teammitglieds.

Bevor ich die Metrik selbst beschreibe, möchte ich noch eine meiner Meinung nach sehr wichtige Idee erwähnen. Derzeit bin ich mir ihrer absolut sicher.

Metriken sollten auf den Daten basieren, die Sie ohnehin erhalten. Das Erhalten einer Metrik sollte das Team nicht dazu zwingen, systematisch mehr Zeit aufzuwenden und seinen Wertlieferungsprozess an die Metrik selbst anzupassen. Mehr dazu werde ich in einem der nächsten Artikel zu erzählen versuchen.

Also, ein Beispiel eines konkreten Falls. Natürlich verwenden wir ein Board, um User Stories durch Status von DOR (Definition Of Ready) bis DOD (Definition Of Done) zu bewegen. Es ist bei uns virtuell (d.h. im Internet unter einem Link. Unser Team ist ebenfalls verteilt, und Standups finden über das Unternehmens-Skype statt, gerade mit Übertragung des Boards.

Für ein Teammitglied ist es bequem, sich selbst als Teilnehmer einer User Story einzutragen, damit man bei Verwendung eines Filters nach sich selbst schnell nur die Geschichten übrig lassen kann, an denen man gerade beteiligt ist (meistens verwenden wir diesen Filter bei Standups).

Hier möchte ich auch eine Erklärung geben: Das bedeutet nicht, dass dieses Teammitglied nicht an anderen Geschichten teilnehmen kann (wenn zum Beispiel beim Standup jemand aus dem Team um Hilfe bittet, kann er durchaus Teilnehmer einer neuen Geschichte werden, oder umgekehrt, wenn er das Gefühl hat, dass seine Teilnahme nicht erforderlich ist, kann er aufhören, Teilnehmer einer Geschichte zu sein.

Um also das Ranking jedes Teammitglieds zu berechnen, müssen wir schauen, auf wie viele SP jedes Teammitglied Einfluss hat. In unserem Fall beeinflusst Arkadi 29 SP (Geschichten 1, 2, 5, 6), Tatjana beeinflusst 33 SP (beteiligt an allen Geschichten), Wassili 23 SP (Geschichten 1, 3, 5, 6).

Geschlossen (DOD erfüllt) bei Arkadi 5 von 29 SP, bei Tatjana 6 von 32 SP, bei Wassili 5 von 23. Mit der Sortierung habe ich mich ziemlich lange gequält und bin zu folgender Formel für den Vergleich zweier Teammitglieder gekommen (team[i] - ein Teammitglied und team[j] - ein anderes Teammitglied):

Gemäß dieser Sortierung erhalten wir das aktuelle Ranking der Teammitglieder in folgender Form.

• 1. Platz. Wassili (erledigt 5 von 23)
• 2. Platz. Arkadi (erledigt 5 von 29)
• 3. Platz. Tatjana (erledigt 6 von 32)

Jetzt lassen Sie uns alle Daten zum Sprint generieren. Stellen wir uns vor, dass der Sprint 5 Arbeitstage dauert.

• 1. Tag
  

  

  
  1. Platz: Wassili (verbrannt 0 von 23)
  2. Platz: Arkadi (verbrannt 0 von 29)
  3. Platz: Tatjana (verbrannt 0 von 32)
  
• 2. Tag
  

  

  
  1. Platz: Wassili (verbrannt 0 von 23) Dynamik(1->1)
  2. Platz: Arkadi (verbrannt 0 von 29) Dynamik(2->2)
  3. Platz: Tatjana (verbrannt 0 von 32) Dynamik(3->3)
  
• 3. Tag
  

  

  
  1. Platz: Wassili (5 von 23 verbrannt) Dynamik(1->1->1)
  2. Platz: Arkadi (5 von 29 verbrannt) Dynamik(2->2->2)
  3. Platz: Tatjana (5 von 32 verbrannt) Dynamik(3->3->3)
  
• 4. Tag
  

  

  
  1. Platz: Wassili (8 von 23 verbrannt) Dynamik(1->1->1->1)
  2. Platz: Arkadi (8 von 29 verbrannt) Dynamik(2->2->2->2)
  3. Platz: Tatjana (9 von 32 verbrannt) Dynamik(3->3->3->3)
  
• 5. Tag
  

  

  
  1. Platz: Wassili (23 von 23 verbrannt) Dynamik(1->1->1->1->1)
  2. Platz: Tatjana (24 von 32 verbrannt) Dynamik(3->3->3->3->2)
  3. Platz: Arkadi (21 von 29 verbrannt) Dynamik(2->2->2->2->3)
  

Somit kann man mit dieser Metrik die persönliche Statistik jedes Teammitglieds sammeln und ihm helfen, die richtigen Schlüsse zu ziehen. Zum Beispiel sehen wir hier, dass Wassili seine Zeit von Anfang an sehr gut geplant hat (d. h. bei der Sprintplanung hat er sich mit dem Team auf den Arbeitsumfang geeinigt, den er tatsächlich auch erledigt hat.) Aber gleichzeitig: Hätte er den anderen Teammitgliedern irgendwie helfen können? Vielleicht nicht, aber über diese Frage sollte man vor der Retrospektive nachdenken.

Bei Tatjana und Arkadi ist das Problem ernster. Offensichtlich haben sie sich von Anfang an bei der Sprintplanung mit dem Team auf die Teilnahme an allen Stories geeinigt und konnten die Verpflichtungen tatsächlich nicht erfüllen. Über die Ursachen sollte man ebenfalls vor der Retrospektive nachdenken. Vielleicht sollte man weniger für sich selbst einplanen, vielleicht die Kompetenzen erweitern, um alles Geplante zu schaffen, auch andere Lösungen sind möglich.

Somit können wir die Statistik nicht nur für das gesamte Team und nicht nur für einen Sprint sammeln, sondern auch für einzelne Mitglieder des DEV TEAM über die gesamte Zeit und diese Informationen zur ständigen Verbesserung des Teams nutzen.

Abschließend möchte ich besonders auf die Tatsache hinweisen, dass vor der Verwendung dieser Metrik im Team bereits ein ausreichend hohes Vertrauensniveau bei der Mehrheit des Teams vorhanden sein muss. Außerdem würde ich empfehlen, einen großen Schwerpunkt darauf zu legen, was an erster Stelle steht – das Fehlen von Überstunden und eine komfortable Tätigkeit.

Wir legen den Schwerpunkt auf die richtige Prognose des Ergebnisses und nicht auf die Motivation, Überstunden zu machen, um den 1. Platz zu belegen. Letztendlich zielt diese Metrik auf die Verbesserung der Planungsfähigkeit jedes einzelnen Teammitglieds ab.