Wie erkennt man das faule Teammitglied in einem selbstorganisierten Team?

Zunächst etwas Kontext: Ich bin Projektmanager in einem Softwareentwicklungsunternehmen mit einer Kanban-Umgebung. In dem Team, das ich leite, gibt es keine Leute, die mir von ihrer Arbeit berichten, oder Leute, die nacheinander erzählen, was sie gestern gemacht haben usw. Bei Stand-up-Meetings konzentrieren wir uns auf den Fluss, fast nie auf ein bestimmtes Stück der Arbeit.

Neulich hatte ich einen (kleinen) Streit mit meinem Chef um einen Satz aus dem Buch Management 3.0 von Jurgen Appelo:

Ob Mitarbeiter Führungskräfte brauchen, ist unerheblich. Es sind die Aktionäre, die Manager ihres Unternehmens brauchen. Selbstorganisation ist wertlos. Es braucht jemanden, der an seinen Ergebnissen interessiert ist, um zu entscheiden, ob die Ergebnisse der Selbstorganisation „gut“ oder „schlecht“ sind.

Dann stellte der Chef diese Frage:

In Anbetracht eines selbstorganisierten Teams, in dem niemals einzelne Arbeiten gemeldet werden, wie erkennen Sie das faule Teammitglied?

Eines der Schlüsselprinzipien von Scrum dreht sich um das Konzept eines sich selbst verwaltenden Teams. Hast du die Full-Metal-Jacke des Films gesehen? In diesem Film entdeckt das Team, dass Pvt. Pyle ist ein faules (Donut essendes) Mitglied des Teams. Das Team stellt fest, dass dies die Arbeitsbelastung des restlichen Teams erhöht. Als gutes selbstorganisierendes Team arbeiten sie also unabhängig voneinander zusammen, um eine Lösung zu finden, die für das gesamte Team funktioniert. Das klappt, & Pvt. Pyle beschleunigt das Tempo. Dies schlägt später leider auf das Management zurück. Ich werde keine Spoiler geben, aber ich schlage vor, dass Sie sich den Film ansehen, um die ganze Geschichte zu erfahren.

Antworten (3)

Werturteile vs. Flow-Analyse

In Anbetracht eines selbstorganisierten Teams, in dem niemals einzelne Arbeiten gemeldet werden, wie erkennen Sie das faule Teammitglied?

Das ist die falsche Art, die Frage zu stellen, aber es ist verständlich, da Menschen soziale Wesen sind. Die Frage wird durch einen sozialen Filter gestellt, der Motive unterstellt, anstatt den Prozessablauf zu analysieren und Engpässe, Prozesslücken oder Hindernisse zu identifizieren.

Eine bessere Möglichkeit, dieses Problem zu betrachten, besteht darin, den gesamten Prozessablauf zu betrachten. Ist die Wertschöpfungskette intakt und die Durchlaufzeit des Prozesses akzeptabel, ist die Frage, ob ein Teammitglied ein Superstar oder ein Superdud ist, eigentlich irrelevant . Die einzige Frage, die zählt, ist, ob diese Person der Kette einen Mehrwert hinzufügt oder ob der Prozess um diese Person herumleitet (z. B. die Person ein Engpass/Hindernis ist, das aus Kanban-Perspektive als „Verschwendung“ angesehen werden könnte).

Nehmen wir für den Moment an, dass die Person faul ist , aber dennoch einen Mehrwert für den Prozess schafft. Vielleicht ist diese Person die einzige, die weiß, wie man das Whatsit ausbaut, bevor es an den Kunden verschickt wird. Während es verlockend sein mag, diese Person durch jemanden zu ersetzen, der sich darauf freut, jeden Tag aufzutauchen und alles schneller zu verdeutlichen, legt das Gesetz der unbeabsichtigten Folgen nahe, dass dies Ihren Prozess oder Ihre Zykluszeiten möglicherweise nicht wirklich verbessert. Vielleicht kann sich der Prozess nicht schneller bewegen, als er es tut, oder vielleicht liefert diese Person einen nicht nachverfolgten Wert für die Prozesskette, der nicht von einer bestimmten Swimlane oder Story-Karte erfasst wird.

Wenn Sie Leute wegen "moralischer Verkommenheit" oder einem anderen sozialen Äquivalent feuern wollen, ist das in Ordnung. Aber machen Sie bitte nicht den Fehler zu glauben, dass dies ein Prozessproblem ist, da dies nicht durch die von Ihnen vorgelegten Daten gestützt wird.

Unteraufgaben nicht optimieren

In Kanban (wie in anderen agilen Methoden) ist die Verfolgung der individuellen Leistung immer die falsche Metrik. Bob Lewis hat wiederholt gesagt :

Sie können nicht das Ganze optimieren, indem Sie die Teile optimieren, egal ob Sie ein Auto, ein Softwaresystem oder eine IT-Organisation entwerfen.

Es ist ein allgegenwärtiges Thema für Mr. Lewis, und obwohl der Kontext des Blogeintrags, auf den verwiesen wird, etwas anders ist als Ihr Problem, ist die Kernbotschaft immer noch zielführend. Wenn Sie das Gefühl haben, dass ein Teil des Prozesses nicht optimal ist, müssen Sie sorgfältig abwägen, ob die Optimierung einer Teilaufgabe oder Rolle Ihren Gesamtprozess tatsächlich verbessern oder verschlechtern würde.

Wenn Sie das Gefühl haben, dass jemand „faul“ ist, sprechen Sie damit implizit eine potenzielle Optimierung an. Sie müssen Ihre Metrik sorgfältig prüfen (Warum denken Sie, dass diese Person faul ist?) und feststellen, ob sie für den Gesamtprozess wirklich wichtig ist oder nicht. Wenn Sie das Falsche messen oder für etwas anderes als Wertschöpfungskette, Abfallreduzierung oder Prozessdurchsatz optimieren, betreiben Sie nur Social Engineering.

Man kann ein faules Teammitglied in einem funktionsübergreifenden Team nicht wirklich erkennen . Das Gute an funktionsübergreifenden Teams ist der Zusammenhalt, der die Leistung (gut oder schlecht) des Einzelnen „versteckt“ , sodass man nicht wirklich sagen kann, dass X oder Y faul sind. Es kann vorkommen, dass die Teammitglieder über ein anderes Mitglied sprechen, aber diese Diskussion ist und sollte nicht auf der Ebene Ihres Chefs sichtbar sein, es sei denn, sie wird von den Teammitgliedern eskaliert. Jürgens Buch handelt von agilem Management, und ich kenne Ihren Chef nicht, aber nachdem er das Buch bekommen hat, wird er feststellen, dass es keine Antwort auf seine Frage im Zusammenhang mit Agile oder Management 3.0 gibt.

Nehmen wir an, Sie sind ein Teammitglied und denken, dass Ihr Kollege faul ist. Ich betrachte Faulheit als ein Symptom. In den meisten Fällen steckt etwas anderes dahinter, also ist es entscheidend, herauszufinden, was vor sich geht. Ich erinnere mich, dass ein alter Kollege von mir überzeugt war, dass ein anderer Kollege faul sei, und ständig versuchte, es zu beweisen und diesen anderen Kollegen loszuwerden. Eigentlich war er überhaupt nicht faul, sondern viel langsamer als die anderen. Wenn Sie also denken, dass jemand in Ihrem Team faul ist, graben Sie tiefer und finden Sie sein/ihr Motiv heraus . Es gibt zwei Lösungen: ihm/ihr helfen oder ihm/ihr ein anderes Team suchen.

1) Einfacher Weg: Da Sie ein Kanban-Board haben, sollte es relativ einfach sein, die durchschnittliche Anzahl von Aufgaben/Punkten zu verfolgen, die von jedem Teammitglied erledigt wurden

2) Bitten Sie (einzeln) jedes Teammitglied, 1-2 Partner für eine schwierige und wichtige Aufgabe (Aufgabe, Geschichte) auszuwählen und zu sehen, wer NICHT ausgewählt wird - diese Methode gibt Ihnen möglicherweise mehr Informationen über das Team, könnte aber nach hinten losgehen vorsichtig sein.


noch etwas: Sie müssen nicht auf "Story Points pro Person" optimieren, aber es könnte eine gute Idee sein zu wissen, dass Sie ein schwaches Glied im Team haben (vielleicht jemand, der negative Ergebnisse produziert (ich habe es gesehen))

Kanban ist nicht darauf ausgelegt, die individuelle Leistung zu verfolgen. Wenn Sie für „Story Points pro Person“ optimieren, optimieren Sie nicht den Prozessfluss oder den Durchsatz.
@CodeGnome: Ich stimme zu, aber (afaik) 1) jedes aktive Element (Aufgabe) auf dem Kanban-Board muss einen Namen der Person(en) haben, die an diesem Element arbeiten 2) jede Geschichte und Aufgabe sollte im Voraus geschätzt werden -> wenn Der Manager möchte die Leistung des Teammitglieds wirklich einschätzen, das ist möglich.
noch etwas: Sie müssen nicht auf "Story Points pro Person" optimieren, aber es könnte eine gute Idee sein zu wissen, dass Sie ein schwaches Glied im Team haben (vielleicht dasjenige, das negative Ergebnisse produziert)
In Kanban haben Stories keine Besitzer. Swimlanes oder Prozessspalten könnten das sein, aber die Storys selbst sollten gemeinschaftseigene „heiße Kartoffeln“ sein, die durch die Prozesswarteschlangen gezogen werden. Ungenutzte Upstream-Warteschlangen sind im Allgemeinen ein Zeichen für Durchsatz- oder WIP-Probleme und nicht unbedingt „Faulheit“. Menschen können faul sein, aber Sie können es nicht nur anhand der Zykluszeit zwischen Prozessen messen.
@CodeGnome Ich habe nicht "Geschichten" gesagt, ich habe Aufgaben gesagt . Und ich habe nicht über die Besitzer gesprochen, aber meiner Meinung nach sollte diese Haftnotiz den Namen der Person haben, die gerade an dieser Aufgabe arbeitet ; Der Grund ist einfach: Wenn bei dieser Aufgabe etwas schief geht (oder wenn Sie eine Frage haben) - wen fragen Sie nach Details ?