Wie man Low-/High-Performer im Team erkennt

Lesen Sie diese Antwort mit Begeisterung und offenem Herzen :)

Ich beantworte die Frage „wie man sicherstellt, dass Entwickler langsame Entwickler ansprechen – oder. Im Allgemeinen jedes Problem-“ anstelle von „wie man langsame Entwickler erkennt“, da ich denke, dass dies nicht das zugrunde liegende Problem ist.

Der Weg, dies auf den Punkt zu bringen, ist:

• Schaffen Sie eine sichere Umgebung. Jeder sollte sich sicher fühlen, wenn es darum geht, seine Bedenken zu äußern und Vorschläge zu machen
• Trainieren Sie Menschen in Soft Skills. Klingt offensichtlich, aber Menschen trainieren sich oft nicht in Aspekten wie Kommunikation, Arbeitsweisen, Zeitmanagement, intrapersonalen Fähigkeiten (zu wissen, wann man aufsteigen oder Hilfe holen muss!)
• Stellen Sie sicher, dass jeder die Ziele des Projekts versteht (dies ist Teil der Kommunikation, aber ich denke, es erfordert einen separaten Aufzählungspunkt).

Der Hauptgrund für meinen Vorschlag ist, dass ich denke, dass dies auf lange Sicht viel mehr Wert für Ihr Team generieren wird. Der zweite Grund ist, dass ich denke, dass es viel einfacher ist, Probleme zu erkennen, indem Sie sicherstellen, dass Sie mit Leuten zusammenarbeiten, die Probleme und Lösungen proaktiv angehen, als wenn Sie Metriken, KPIs oder im Allgemeinen mechanische Systeme zur Überprüfung der Leistung verwenden (dies kann erkennen nur, wofür sie geschaffen wurden, nicht neue Probleme, die als Ergebnis von "menschlichen" Problemen entstehen).

Eine letzte Anmerkung: Stellen Sie sicher, dass Retrospektiven richtig durchgeführt werden. Dieses spezielle Problem mit dem „langsamen Entwickler“ hätte in Retrospektiven angesprochen werden sollen und Sie hätten offen und transparent mit Ihren Kollegen darüber sprechen sollen.

Ich schlage Ihnen vor, einen Blick auf eines meiner Lieblingsbücher zu werfen, das viel über die Arbeit in sicheren Umgebungen und die Steigerung der Produktivität erklärt: Creativity Inc .

Ich stimme anderen Antworten hier über die langsamere Person zu. Aber warum ist die andere Person schneller?

Ich hatte einmal jemanden in meinem Scrum-Team, der so viel schneller war als alle anderen:

• Sie verschwendeten keine Zeit damit, ihre Ideen mit Kollegen (z. B. Testern) zu validieren.
• Sie waren nicht durch Teamvereinbarungen belastet, z. B. ist der Ansatz der testgetriebenen Entwicklung (TDD) viel langsamer als das einfache Nachrüsten von Tests.
• Sie waren dem Spiel voraus, indem sie Code für Elemente schrieben, die sich noch im Product Backlog befanden.
• Sie übernahmen die alleinige Verantwortung für mehrere lebenswichtige Prozesse.
• Sie wurden von Endbenutzern geliebt, weil sie nur Dinge reparierten (keine Notwendigkeit, den Product Owner zu stören!).
• Sie überarbeiteten ihren Code schnell, wenn Tester einen verpassten Anwendungsfall fanden.
• Sie lenkten die Kollegen nicht bei Übungen zum Wissensaustausch ab.
• Sie dominierten Scrum-Zeremonien nicht (indem sie nie wirklich sprachen).

Ja, sie waren ein schrecklicher Teamplayer. Wir stellten schließlich fest, dass wir die Art von Geschwindigkeit, die sie boten, nicht wollten.

Nur weil ein Entwickler langsam ist, bedeutet das nicht, dass er verbessert werden muss.

Ich bin und war einige Jahre lang eines der am wenigsten codeproduktiven Mitglieder des Entwicklungsteams, in dem ich arbeite. Warum? Da ich ein Teamleiter bin, habe ich viele andere Aufgaben, darunter Mentoring, Schulung, Kommunikation mit Interessenvertretern, Unterstützung bei Live-Problemen und Entwicklung der Unternehmensgemeinschaft. Keines davon taucht auf unserem Kanban-Board auf.

Zweitens ist am Ende des Projekts die einzige Geschwindigkeit, die wirklich zählt, die Geschwindigkeit Ihres Teams . Ihr „langsamer Entwickler“ arbeitet möglicherweise hinter den Kulissen, um dem Team zu helfen, und wie @OneDayWhen darauf hinweist, sitzt Ihr „schneller Entwickler“ möglicherweise in einem Silo und hortet Wissen. Sie überspringen möglicherweise Komponententests, die Ihr "langsamer Entwickler" gewissenhaft durchführt.

Sie haben gefragt, was die Scrum-Antwort darauf ist. Die Antwort ist, Ihre täglichen Standups zu nutzen, um sich auf Aufgaben zu konzentrieren. Ihr Board enthält alle Aufgaben, die nach Vereinbarung Ihres Teams erledigt werden müssen, um das Sprintziel zu erreichen. Wenn Sie es schaffen wollen, müssen alle Aufgaben erledigt werden.

Wenn eine Aufgabe/Story/Feature/Bug ins Hintertreffen gerät und es so aussieht, als wäre es gefährdet, dann melde es beim Standup. Dies könnte daran liegen, dass Ihr „langsamer Entwickler“ abgelenkt ist oder damit zu kämpfen hat. Es könnte auch daran liegen, dass jemand krank war oder zu einem Live-Vorfall gerufen wurde.

Machen Sie sich als Scrum-Teammitglied keine Gedanken über die persönliche Leistung, das ist die Aufgabe des Managers und sollte 1:1 gehandhabt werden. Sehen Sie sich als Scrum Master gefährdete Aufgaben an und fragen Sie das Team, was getan werden kann, um sie wieder einzuholen.

Ich hoffe, das ist offensichtlich, aber die Schnelligkeit bei der Ausführung einer Aufgabe ist nicht das einzige Kriterium, anhand dessen Sie einen Praktiker bewerten möchten. In vielen Fällen spielt die Geschwindigkeit möglicherweise nicht einmal eine Rolle.

Es ist auch interessant, dass das OP nur auf die Leistungsextreme hinweist: hoch, niedrig.

Außer bei extrem kleinen Teams, bei mittelgroßen bis großen Teams, gibt es diese Dichotomie nicht.

Ich denke, es gibt drei Facetten, die bei der Bewertung Ihres Teams verstanden werden müssen: 1) die zu verwendenden Kriterien; 2) die Leistungsverteilung; und 3) die Dynamik unterschiedlicher Stärken und Schwächen, die kumulativ ein leistungsstarkes Team schaffen.

1: Zu oft beschränken wir die Definition von hoher Leistung auf ein oder zwei Kriterien, während wir andere Metriken minimieren oder ignorieren, ähnlich wie bei dieser OP-Frage. Eine zu enge Konzentration auf ein Kriterium auf Kosten anderer führt dazu, dass einem ansonsten mittelmäßigen Leistungsträger das Label „Hochleistung“ verliehen wird.

2: Wie sieht die Leistungsverteilung in jedem Team in jeder Domäne wirklich aus? Ist es normalverteilt? Schräg? Die derzeitige Meinung ist, dass die Leistung stark positiv verzerrt ist, wobei die meisten Ihres Teams mittelmäßig und nur sehr wenige überdurchschnittlich gut sind. Unter der Annahme, dass Ihre Kriterien stichhaltig sind, identifizieren Sie vielleicht in Wirklichkeit nur den Hyper-Performer, der einfach herausstechen könnte.

3) Wenn Sie Ihr Team nur in einer einzigen Dimension betrachten, könnten Sie leicht andere Stärken aus den Augen verlieren, die bei einer Person vorhanden sind, die nach Ihren Kriterien mittelmäßig erscheinen mag, deren Wert jedoch zur Gesamtleistung des Teams beiträgt. Ein langsamer Performer – der nur auf Geschwindigkeit als Kriterium schaut – kann in seiner Arbeit ein hohes Maß an Präzision bieten, das aus einer Teamperspektive ausgenutzt werden könnte, um Qualität im Teamprozess zu ermöglichen. Die Pflege dieser Art von Person in dieser bestimmten Teamrolle wird also die Leistung des Gesamtteams verbessern, was weitaus wichtiger ist als die Leistung des Einzelnen selbst. Und erinnern Sie sich an das Konzept des Apollo-Effekts .

In meiner Praxis bemühe ich mich nicht, eine Person per se zu betrachten. Ich suche nach Schlüsselstärken, die ich nutzen kann, um die Anforderungen des Teams zu erfüllen und dem Team zu helfen, sich mit diesen Rollen ganzheitlich zu entwickeln. Hyperperformer sind selten und werden sich einfach mit der Zeit präsentieren. Extreme und ziemlich seltene Low-Performer werden sich ebenfalls präsentieren und werden im Laufe der Zeit auf natürliche oder unnatürliche Weise aus dem Team ausgewählt. Insgesamt ist die wichtigste zu messende Metrik die Teamleistung mit der zugrunde liegenden Annahme, dass Ihr Team statisch gesehen mit mittelmäßigen bis durchschnittlichen Leistungsträgern besetzt sein wird.

TL;DR

Transparenz und Kommunikation sind das Rückgrat agiler Praktiken, und wenn sie richtig gemacht werden, lassen sie sich sehr gut skalieren. Scrum basiert auf der Teamleistung und funktioniert schlecht, wenn Sie den Scrum-Prozess als Wettbewerb strukturieren oder versuchen, individuelle Leistungen statt Sportsgeist oder Teamwork zu messen.

Messen Sie die richtigen Dinge

Ich kann den langsamen erkennen, weil ich im Büro bin, aber wenn wir größer werden, wird er natürlich schwer zu erkennen sein. Wir möchten langsame Entwickler erkennen, um uns zu verbessern und Maßnahmen zu ergreifen. Wie können wir das auf die Scrum-Art machen?

Viele andere Antworten haben einige großartige Punkte berührt, aber ich möchte hier einige Dinge nach Hause hämmern.

1. Aus agiler Sicht zählt die Effektivität des Teams, nicht die relative Geschwindigkeit einzelner Entwickler im Team.
2. Die Messung der Codierungsgeschwindigkeit als primäre Metrik kommt dem Trugschluss der 100-prozentigen Auslastung nahe , ein Scrum-Implementierungsgeruch zu sein.
3. Sie bekommen das, wofür Sie bezahlen. Wenn sich also eine wirklich erhebliche Qualifikationslücke auf Ihr Projekt auswirkt, müssen Sie entweder mehr Schulungen einplanen, um die Lücke zu schließen, mehr Löhne für eine leistungsfähigere Belegschaft einplanen oder beides.

Bei Agile im Allgemeinen und Scrum im Besonderen geht es darum, die Fähigkeit eines Teams zu messen, Geschäftswert zu liefern. Ein funktionsübergreifendes Team besteht häufig aus Personen mit unterschiedlichen Fähigkeiten und unterschiedlichen Fähigkeiten und Fachkenntnissen. Ein guter Agilist misst die Effektivität des Teams als Ganzes anhand seiner Fähigkeit, Werte zu liefern, anstatt die Mitglieder des Teams einander gegenüberzustellen.

Untersuchen Sie Ihre Annahmen

In der Regel möchten Sie die Projektergebnisse messen, nicht die Geschwindigkeit einzelner Aufgaben. Anstatt anzunehmen, dass Sie ein Personalproblem haben, überprüfen Sie Ihre anfänglichen Annahmen. Fragen:

1. Erreichen wir gemeinsam unsere Projektziele pünktlich und im Rahmen des Budgets?
2. Arbeitet das Team in einem nachhaltigen Tempo?
3. Liefert das Team geschäftlichen Nutzen, ohne übermäßige technische Schulden zu machen?
4. Ist das Entwicklungsteam mit seinen Arbeitsvereinbarungen und mit seinen Teamkollegen zufrieden?
5. Meldet jemand tatsächlich ein Problem oder gehen Sie einfach davon aus, dass ein Problem besteht?

Wenn die Punkte 1-4 „Ja“ sind und niemand sonst ein Problem anspricht, scheint es wahrscheinlich, dass Sie einer Art falscher Ökonomie nachjagen. Messen Sie die richtigen Dinge, stellen Sie sicher, dass Sie einen effektiven Prozess haben, und holen Sie konsequent ehrliches Feedback von Ihrem Team und Ihren Stakeholdern ein.

Traditionell hätten Sie einen DevLead, der dafür verantwortlich ist, Low-Performer zu erkennen, indem er ganz natürlich beobachtet, wie schnell Aufgaben abgeschlossen werden.

Übrigens, ist geringe Leistung ein Problem? Wenn die Person Aufgaben zweimal langsamer erledigt und zweimal weniger Gehalt bekommt, dann scheint alles in Ordnung zu sein, oder?...

Im Scrum sollten wir idealerweise ein selbstorganisierendes Team haben, in dem die Menschen die Leistung des anderen bewerten sollten. Und wenn Low-Performer die Team-Velocity oder -Qualität oder so etwas beschädigen und zu viel Geld bekommen, dann wird das Team es erhöhen – niemand will mit Low-Performern arbeiten. Aber wenn dies nur eine Frage des unterschiedlichen Qualifikationsniveaus und der unterschiedlichen Erfahrung ist, dann sollte dies durch niedrigere Gehälter kompensiert werden, und sie sollten lernen, wie sie Dinge tun können, um diese zu erhöhen.

Wenn es nicht durch Gehalt kompensiert wird, sollten Sie Ihr Team fragen: Wir müssen das Projekt bis zu einem bestimmten Datum abschließen. Wenn der Typ uns auch mit geringer Geschwindigkeit voranbringt und es keine andere Person gibt, die eingestellt werden kann, kann das besser sein, als Liefertermine zu verpassen.

Sie scheinen den „langsamen“ Entwickler bereits identifiziert zu haben. Ihr Team sollte über ein Versionskontrollsystem verfügen und die Arbeit einschließlich des Rückstands verfolgen; Ein Großteil Ihrer Bedenken könnte durch einen täglichen Blick auf die fertiggestellten Features oder die Daten im Nachhinein ausgeräumt werden.

Das Identifizieren langsamer Entwickler ist entweder ein Leistungsproblem, bei dem die Person nicht ausreichend mit den Tools und Entwickleraufgaben vertraut ist, und Sie sollten einen neuen Entwickler finden oder ihm Zeit geben, ihn bei der Verbesserung zu unterstützen, oder der Verweis auf „langsame Entwickler“ ist ein Fehlleitung und Sie sollten bedenken, dass das Management den Entwickler auffordert, Aufgaben auszuführen, und dass das Management versagt.

Grobe Schätzungen der Größenordnung sind ein nützliches Brainstorming-Tool, wenn versucht wird, die Gesamtanstrengungen derselben Person mit ähnlichem Umfang und ähnlichen Technologien zu messen. Sie können dabei helfen, die Fähigkeiten von Entwicklern zu reifen, die verwalten, aber nicht immer vorteilhaft für das Endergebnis sind. Wenn Ihr „langsamer“ Entwickler an der Verwaltung, Planung, Planung und Warteschlangenbildung von Arbeiten beteiligt ist, entwickeln sie sich nicht.

Sie können davon profitieren, From Worst to Best in 9 Months: Implementing a Drum-Buffer-Rope Solution in Microsoft's IT Department zu lesen und mit Ihrem Team zu teilen.

Da sich dies im Projektmanagement-Stack befindet, beachten Sie, dass Ihr lose definiertes Problem nicht spezifisch für (Scrum) Agile ist. Beim Projektmanagement in Software kann im Allgemeinen gesagt werden, dass Teammitglieder die Arbeit innerhalb eines bestimmten Zeitrahmens abschließen. Zu lernen, die Zeit bis zur Fertigstellung einzuschätzen, ist eine Fähigkeit. Ob als Entwickler bei der Schätzung, wie lange die Implementierung einer neuen Funktion dauern wird, oder als Projektmanager, um festzustellen, ob die Anzahl der Personen mal Stunden in das Budget passt.

Projektmanager sind in der Regel keine Personalmanager oder Vorgesetzten. Wenn der Schwerpunkt auf der Bereitstellung von Funktionen durch die Einzelperson oder einen Subunternehmer liegt, kann sich dies auf den Projektzeitplan und die Kosten auswirken. Wenn der Schwerpunkt auf der Leistung des Einzelnen liegt, handelt es sich um eine Personalfrage, die im Zusammenhang mit einer Stellenbeschreibung und den Erwartungen im Einstellungsvertrag berücksichtigt werden sollte, zusammen mit der Fähigkeit, zu dokumentieren, wenn Erwartungen nicht erfüllt werden, damit sie diese verbessern oder ersetzen können um die Ergebnisse innerhalb der Budget- und Zeitbeschränkungen zu erfüllen.

Einfache Messungen der Anzahl von Features, die bei jedem Sprint unabhängig implementiert werden, vielleicht mit Attributen für die Komplexität (z. B. Story Points), pro Person, können Ihnen die Geschwindigkeit zeigen. Es braucht Kontext, um zu wissen, ob das „langsam“ oder für die Gesamtprojektpläne akzeptabel ist.