Velocity einzelner Team-Mitarbeiter visualisieren?

Im letzten Sprint – als ich in der „Done“ Spalte nach einem gewissen Ticket suchte – musste ich mit großer Überrschung feststellen, dass einer der Entwickler DEUTLICH mehr Tasks erledigt hatte, als die Anderen.

Es ist korrekt, dass die Tickets, die er bis zu diesem Zeitpunkt gemacht hatte, vom Aufwand kleiner waren als die, die sich andere Mitglieder des Teams vorgenommen hatten – der Unterschied war aber gravierend.

Als ich die schiere Anzahl an fertigen Tasks sah, hatte ich das Verlangen diese zu visualisieren. Da ich es nicht besser wusste nahm ich eines der verfügbaren Flipcharts und startete früh am nächsten morgen das Task-Killer-Board. (Rote oder Orangefarbene Tickets sind ungeplante Tasks wie Maintainance, Bugs udgl.)

Zu erst herrschte im Team Verwirrung über diese Aktion, schnell konnte sich aber ein Zweiter finden, der dieser Idee etwas abgewinnen konnte und mit mehr Motivation begann Tasks abzuarbeiten.

In der nächsten Retrospektive musste ich aber einsehen, dass diese Art der Visualisierung unfair den Mitarbeitern gegenüber ist, die einen besonders schwierigen Task nehmen, im Pairprogramming arbeiten, im Krankenstand sind oder auf Weiterbildung waren.

Bestätigt in dem Glauben, dass eine „freundlichere“ Art der Visualisierung der Leistung des Einzelnen dennoch mehr Vor- als Nachteile bringt, ging ich aus der Retrospektive um im aktuellen Sprint eine spielerischere Art der Darstellung zu wählen.

Mehr dazu nach dem aktuellen Sprint.

Was meint Ihr, sollte man als ScrumMaster die Arbeit des Einzelnen (nur im geschützten Teamraum) darstellen oder nur auf die Arbeit des ganzen Teams eingehen und auf die Selbstorganisation der Gruppe bauen, um Probleme der Auslastung einzelner zu lösen?

Dieser Eintrag wurde veröffentlicht in News und verschlagwortet mit von Markus Wissekal. Permanenter Link zum Eintrag.

Über Markus Wissekal

Markus Wissekal ist seit 15 Jahren in der IT-Branche tätig. Im Jahr 2008 entwickelte er eine tiefe Begeisterung für agile Prinzipien und Methoden wie Scrum, Kanban und vielen Lean-Ansätzen. Ab 1.8.2015 ist Markus als Akkreditierter Kanban Trainer, agiler Coach und LegoSeriousPlay Facilitator verfügbar. Wenn Sie Interesse an einem Training in der DACH Region haben, oder Interesse daran wie Kanban, Scrum oder Lean in Ihrem Unternehmen funktionieren können, dann hinterlassen Sie mir doch eine Nachricht.

7 Gedanken zu „Velocity einzelner Team-Mitarbeiter visualisieren?

  1. Nein.

    Die alte Minderleister Diskussion im Deckmantel? So würde ich es empfinden. Leg doch einfachmal die Prime-Directive nicht nur in der Retro zu Grunde, sondern in der ganzen Arbeit. Als Ergebnis kommst du dann von quantitativer Betrachtung (Anzahl der Tasks) zu qualitativer, dem sichtbar machen von Problemen und diese dann auch zu beheben. Hab ich jedenfalls schon ein paar mal so gesehen, nachdem ich Leute mit der „prime directive“ geohrfeigt habe.

    Siehe XP values „Respect“
    http://www.outsofting.com/index.php?option=com_content&view=article&id=147&Itemid=113&lang=en

    • Ich denke, ich bin die eine oder andere Info in meinem Artikel schuldig geblieben:

      Das Task-Killer-Board hat uns im kompletten letzten Sprint begleitet. Es war für das Team jederzeit einsehbar und konnte (sobald ein Task die DoD erfüllte) von den Entwicklern in der jeweiligen Spalte platziert werden.

      Diese (erste) Aktion galt vor allem dem Bereich „Courage“ aus dem genannten Link:

      […] Courage is to tell the truth about progress and estimates, not to document excuses for failure because we plan to succeed, no to fear anything because no one ever works alone.

      Das Board wurde nach der Retrospektive „gelöscht“ und gegen ein anderes (mit den learnings aus der Retrospektive) ersetzt -> fail fast.

      Über das neue (spielerischere) Board schreibe ich nach der nächsten Retrospektive mehr.

  2. Pingback: Scott, the ScrumMaster

  3. Gefährlich! Das war der erste Begriff der mir dazu eingefallen ist.

    Ich glaube es kann – umsichtig eingesetzt – auch Nutzen stiften bestimmte Sachverhalte wie die wahrgenommene Abarbeitungsrate zu visualisieren. Als Start für eine Diskussion, warum es ggf. große Abweichungen gibt.

    Gründe könnten sein:

    • Vielleicht wurden Themen unter-/überschätzt.
    • Jemand hält sich nicht an die DoD und drückt ein Task nach dem anderen durch.
    • Es gibt ein Engpass in der Wissensverteilung.
    • Teammitglieder sind stark unterschiedlich engagiert. Warum?

    In einem erfahrenen, reifen Team werden diese Themen auf anderem Wege erkannt, besprochen und adressiert. Ist das Team noch nicht so erfahren, kann ich mir vorstellen, dass solch eine Visualisierung im Rahmen der Retrospektive eine Diskussion startet, die auch schwierig werden kann – ggf. gibt es verdrängte Konflikte die dann aufbrechen.

    Sobald solch eine Metrik jedoch dauerhaft geführt wird, erzeugt sie mehr Schaden als Nutzen und ist schädlich für die Selbstorganisation und die Gesamtleistung des Teams.

    Falls solche Zahlen auch außerhalb des Teams genutzt werden ist dies eindeutig schädlich, da der Kontext nie adäquat transportiert werden kann. Dann geht Respekt und Vertrauen verloren, die agilen Grundwerte nehmen Schaden.

    Also: Vorsicht!

  4. Sollte man als ScrumMaster die Arbeit des Einzelnen […] darstellen?

    Nein, sollte man nicht.

    Ich denke wenn sich so etwas aus einer gesunden Wettbewerbshaltung aus dem Team heraus entwickelt ist dagegen nichts einzuwenden. Als „Aussenstehender“ auf diese Weise dem Team einen Spiegel vorzuhalten ist aber meiner Meinung nach nicht richtig.

    Um die Kollegen von aussen anzuspornen würde es wohl mehr Sinn machen Faktoren für intrinsische Motivation zu unterstützen: Autonomie, Mastery und Purpose.

  5. Ich finde es ist ein mutiger Versuch von Markus seinem Team zu zeigen, dass es große Unterschiede in der Anzahl der abgeschlossenen Tasks zwischen den Teammitgliedern gibt. Er scheint dabei sehr sensibel vorgegangen sein und die Daten nach der Auswertung in der Retro gelöscht zu haben. Wichtig wäre jetzt, die Ursachen für die Unterschiede herauszuarbeiten und ob dies Anlass zur Veränderung geben sollte. Ein Wandel kann dabei nur erfolgen, wenn die Ideen aus dem Team kommen und von diesem getragen werden.
    Ich bin bereits jetzt gespannt, wie es weiter geht und freue mich auf den 2. Teil des Blogs.

  6. Pingback: Die Motivation und Velocity des agilen Teams spielerisch steigern

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Captcha * Time limit is exhausted. Please reload CAPTCHA.