Wie man niedrige/hohe Leistungen innerhalb der Mannschaft entdeckt

Wir sind ein Team von 3 Personen. Wir passen Scrum-Methoden an.

Alles basiert auf Kanban (Trello), wo wir täglich arbeiten, Retrospektiven und Sprintplanung (die Aufgaben werden durch Arbeitszeiten vorhergesagt).

Die Sache ist, dass ich schnellen Entwickler und langsamen Entwickler habe. Der schnelle Entwickler muss sich immer auf dem langsamen "schminken". Ich kann den Langsamen erkennen, weil ich im Büro bin, aber natürlich, wenn wir größer werden, wird es schwer zu erkennen sein. Wir wollen langsame Entwickler erkennen, um zu verbessern und Maßnahmen zu ergreifen. Wie können wir das so machen?

1
Was ist Ihre Rolle in diesem Team von 3?
hinzugefügt der Autor Lexible, Quelle

7 Antworten

Lesen Sie diese Antwort mit Begeisterung und einem offenen Herzen :)

Ich beantworte die Frage "Wie kann ich dafür sorgen, dass Entwickler langsame Entwickler sprechen?" Im Allgemeinen jedes Problem - "anstatt" langsam Entwickler zu erkennen ", wie ich denke, das ist nicht das zugrunde liegende Problem.

Der Weg dies auf den Punkt zu bringen ist:

  • Erstellen Sie eine sichere Umgebung. Jeder sollte sich sicher fühlen, seine Bedenken zu äußern und Vorschläge zu machen
  • Trainiere Menschen auf Soft Skills. Es klingt offensichtlich, aber die Leute trainieren sich oft nicht in Aspekten wie Kommunikation, Arbeitsweisen, Zeitmanagement, intra-personalen Fähigkeiten (wissen, wann man aufleveln muss oder Hilfe bekommt!)
  • Stellen Sie sicher, dass jeder die Ziele des Projekts versteht (dies ist ein Teil der Kommunikation, aber ich denke, es erforderte einen separaten Aufzählungspunkt)

Der Hauptgrund für meinen Vorschlag ist, weil ich denke, dass dies auf lange Sicht viel mehr Wert für Ihr Team generieren wird. Der zweite Grund ist, weil ich denke, dass es einfacher ist, Probleme zu erkennen, indem Sie sicherstellen, dass Sie mit Personen arbeiten, die proaktiv auf Probleme und Lösungen reagieren, indem Sie Metriken, KPIs oder allgemein mechanische Systeme zur Leistungsüberprüfung einsetzen Sie erkennen nur, wofür sie geschaffen sind, nicht neue Probleme, die sich aus "menschenbezogenen" Problemen ergeben.

Eine letzte Anmerkung: Sorgen Sie dafür, dass Retrospektiven richtig gemacht werden. Dieses spezielle Problem mit dem "langsamen Entwickler" hätte während der Retrospektiven angesprochen werden müssen, und Sie hätten es offen und transparent mit Ihren Kollegen besprechen sollen.

I suggest you to have a look at one of my favourite books that expands a lot about working on safe environments and how to increase productivity: Creativity Inc.

6
hinzugefügt

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

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

  • Sie haben keine Zeit damit verschwendet, ihre Ideen mit Kollegen (z. B. Testern) zu validieren.
  • Sie waren nicht durch Teamvereinbarungen belastet, z. Test-Driven Development (TDD) Ansatz ist viel langsamer als einfach Retro-Fitting-Tests.
  • Sie haben es geschafft, Code für Artikel zu schreiben, die sich noch im Product Backlog befinden.
  • Sie haben den alleinigen Besitz mehrerer lebenswichtiger Prozesse übernommen.
  • Sie wurden von Endbenutzern geliebt, weil sie nur die Dinge reparieren würden (keine Notwendigkeit, den Product Owner zu stören!).
  • Sie haben ihren Code schnell überarbeitet, wenn Tester einen verpassten Anwendungsfall gefunden haben.
  • Sie haben Kollegen bei Übungen zum Wissensaustausch nicht abgelenkt.
  • Sie haben die Scrum Zeremonien nicht dominiert (indem sie nie wirklich gesprochen haben).

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

4
hinzugefügt

Nur weil ein Entwickler langsam ist, heißt das nicht, dass er verbessert werden muss.

Ich bin und bin seit einigen Jahren einer der am wenigsten Code produktiven Mitglieder des Entwicklungsteams, in dem ich arbeite. Warum? Weil ich ein Teamleiter bin, habe ich viele andere Verantwortungen, die Mentorship, Training, Stakeholder-Kommunikation, Unterstützung von Live-Problemen und die Entwicklung von Firmengemeinschaften beinhalten. Keiner von diesen zeigt sich auf unserer Kanbantafel.

Zweitens, am Ende des Projekts ist die einzige Geschwindigkeit, auf die es ankommt, die Geschwindigkeit deines Teams . Ihr "langsamer Entwickler" arbeitet möglicherweise hinter den Kulissen, um dem Team zu helfen, und da @OneDayWen darauf hinweist, dass Ihr "schneller Entwickler" möglicherweise in einem Silo- und Lern-Wissen sitzt. Sie können Testeinheiten überspringen, die Ihr "langsamer Entwickler" gewissenhaft ausführt.

Sie haben gefragt, was die Scrum-Antwort darauf ist. Die Antwort ist, dass Sie Ihre täglichen Standups verwenden, um sich auf Aufgaben zu konzentrieren. Ihr Board enthält alle Aufgaben, die Ihr Team vereinbart hat, um das Sprint-Ziel zu erreichen. Wenn Sie es schaffen, müssen alle Aufgaben erledigt werden.

Wenn eine Aufgabe/Story/Feature/Bug zurückfällt und es aussieht, als wäre sie in Gefahr, dann hebe sie beim Standup auf. Dies könnte daran liegen, dass Ihr "langsamer Entwickler" abgelenkt ist oder dass er damit zu kämpfen hat. Es könnte auch sein, dass jemand krank war oder in einen Live-Vorfall gerufen wurde.

Als ein Scrum-Teammitglied kümmern Sie sich nicht um persönliche Leistung, das ist die Aufgabe des Managers und sollte in 1: 1s behandelt werden. Als Scrum-Master sehen Sie sich Aufgaben an, die gefährdet sind, und fragen das Team, was getan werden kann, um sie wieder aufzufangen.

2
hinzugefügt

Ich hoffe, dies ist offensichtlich, aber die Schnelligkeit, eine Aufgabe zu erfüllen, ist nicht das einzige Kriterium, vor dem Sie einen Praktiker bewerten möchten. In vielen Fällen ist die Geschwindigkeit möglicherweise nicht einmal eine Überlegung.

Interessant ist auch, dass das OP nur die Performance-Extreme hervorhebt: hoch, niedrig.

Außer für extrem kleine Teams, für mittlere bis große Teams, existiert diese Dichotomie nicht.

Ich denke, es gibt drei Aspekte, die bei der Bewertung Ihres Teams zu beachten sind: 1) die zu verwendenden Kriterien; 2) die Leistungsverteilung; und 3) die Dynamik unterschiedlicher Stärken und Schwächen, die kumulativ ein leistungsstarkes Team bilden.

1: Zu oft begrenzen wir die Definition von hoher Leistung auf ein oder zwei Kriterien, während andere Metriken minimiert oder ignoriert werden, ähnlich wie bei der Frage dieses OP. Eine zu enge Fokussierung auf ein Kriterium auf Kosten anderer führt dazu, dass einem ansonsten mittelmäßigen Performer die Bezeichnung "high performance" verliehen wird.

2: What does the distribution of performance really look like on any team in any domain? Is it normally distributed? Skewed? Most current thinking is that performance is severely positively skewed, where most of your team are mediocre and very few are hyper performers. So perhaps in reality, assuming your criteria are sound, you are really only identifying the hyper performer who might simply stand out.

3) If you only look at your team in a single dimension, you could easily lose sight of other strengths that exist with an individual who may appear mediocre against your criteria, but whose value contributes to the overall team's performance. A slow performer--looking only at speed as a criterion--may offer a high degree of precision in his/her work that could be exploited from a teaming perspective to enable quality in the team's process. So grooming that type of person in that particular team role will enhance the overall team's performance, which is far more important than the individual's performance itself. And remember the concept of The Apollo Effect.

In meiner Praxis beschäftige ich mich nicht mit einer Person an sich. Ich suche nach Stärken, die ich ausschöpfen 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 im Laufe der Zeit präsentieren. Extreme und ziemlich seltene Low-Performer werden sich ebenfalls präsentieren und werden im Laufe der Zeit natürlich oder unnatürlich aus dem Team ausgewählt. Insgesamt ist die wichtigste Messgröße die Leistung des Teams mit der zugrundeliegenden Annahme, dass Ihr Team statisch gesehen nur mittelmäßige bis durchschnittliche Leistungsträger aufweist.

2
hinzugefügt

Traditionell hat man ein DevLead, das dafür verantwortlich ist, Schwachstellen zu erkennen, indem man einfach nachschaut, wie schnell Aufgaben abgeschlossen sind.

Übrigens, ist eine geringe Leistung ein Problem? Wenn die Person Aufgaben zweimal langsamer erledigt und zweimal niedrigeres Gehalt bekommt, dann scheint alles ok, oder?

In Scrum sollten wir idealerweise ein selbstorganisierendes Team haben, in dem sich die Mitarbeiter gegenseitig bewerten sollten. Und wenn Low-Performer Team-Geschwindigkeit oder Qualität oder etwas beschädigen und zu viel Geld bekommen, wird das Team es erhöhen - niemand möchte mit Low-Performern arbeiten. Aber wenn dies nur eine Frage der unterschiedlichen Fähigkeiten und Erfahrung ist, dann sollte dies durch niedrigere Gehälter kompensiert werden, und sie sollten lernen, wie man Dinge tut, um sie 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 vorwärts bewegt, selbst mit geringer Geschwindigkeit, und es keine alternative Person zu mieten gibt, dann kann es besser sein als fehlende Lieferdaten.

1
hinzugefügt

TL; DR

Transparenz und Kommunikation sind das Rückgrat agiler Praktiken, und wenn sie richtig gemacht werden, skalieren sie sehr gut. Scrum basiert auf team Leistung und funktioniert schlecht, wenn Sie den Scrum-Prozess als Wettbewerb strukturieren oder versuchen, individuelle Erfolge zu messen, anstatt Sportlichkeit oder Teamarbeit.

Messen Sie die richtigen Dinge

Ich kann den langsamen erkennen, weil ich im Büro bin, aber natürlich, wenn wir größer werden, wird es schwer zu erkennen sein. Wir wollen langsame Entwickler erkennen, um zu verbessern und Maßnahmen zu ergreifen. Wie können wir das Gedränge machen?

Viele andere Antworten haben einige wichtige Punkte berührt, aber ich möchte hier ein paar Dinge hämmern.

  1. Aus agiler Sicht zählt nicht die Effektivität des Teams, sondern die relative Geschwindigkeit einzelner Entwickler im Team.
  2. Die Codierungsgeschwindigkeit als primäre Metrik zu messen liegt nahe bei dem 100% -Nutzungsfehler , da es sich um einen Scrum-Implementierungsgeruch handelt.
  3. Sie bekommen das, wofür Sie bezahlen. Wenn es also wirklich erhebliche Qualifikationslücken gibt, die sich auf Ihr Projekt auswirken, müssen Sie entweder für mehr Schulungen budgetieren, um die Lücke zu schließen, mehr Löhne für eine leistungsfähigere Belegschaft budgetieren oder beides.

Agile in general, and Scrum in particular, are about measuring the ability of a team to deliver business value. A cross-functional team will often have people with varying skill sets, and different abilities and levels of expertise. A good agilist measures the effectiveness of the team as a whole in terms of its ability to deliver value, rather than contrasting members of the team against one another.

Untersuche deine Annahmen

In der Regel möchten Sie die Projektergebnisse messen, nicht die individuelle Aufgabengeschwindigkeit. Anstatt anzunehmen, dass Sie ein Personalproblem haben, untersuchen Sie Ihre ursprünglichen Annahmen. Fragen:

  1. Erreichen wir gemeinsam unsere Projektziele zeit- und budgetgerecht?
  2. Arbeitet das Team in einem nachhaltigen Tempo?
  3. Liefert das Team einen geschäftlichen Wert, ohne übermäßige technische Schulden zu verursachen?
  4. Ist das Entwicklungsteam mit seinen Arbeitsvereinbarungen und mit seinen Teammitgliedern zufrieden?
  5. Hat jemand tatsächlich ein Problem angesprochen, oder nehmen Sie einfach an, dass ein Problem besteht?

If items 1-4 are "yes" and no one else is raising an issue, it seems likely that you're chasing a false economy of some sort. Messen Sie die richtigen Dinge, ensure you have an effective process, and consistently elicit honest feedback from your team and your stakeholders.

1
hinzugefügt

Sie scheinen den "langsamen" Entwickler bereits identifiziert zu haben. Ihr Team sollte ein Versionskontrollsystem haben und die Arbeit, einschließlich Rückstand, verfolgen; Ein Großteil Ihrer Bedenken könnte durch eine tägliche Überprüfung der ausgefüllten Funktionen oder der Daten im Nachhinein behoben werden.

Das Identifizieren von langsamen Entwicklern ist entweder ein Leistungsproblem, bei dem die Person nicht ausreichend mit den Tools und den Entwickleraufgaben vertraut ist, und Sie sollten einen neuen Entwickler finden oder ihnen ein Training geben, um sie bei der Verbesserung zu unterstützen, oder der Verweis auf "langsame Entwickler" ist Fehlleitung und Sie sollten in Betracht ziehen, dass das Management den Entwickler auffordert, Aufgaben auszuführen, und dass die Verwaltung fehlschlägt.

Schätzungen in groben Grössenordnungen sind ein nützliches Brainstorming-Tool, wenn es darum geht, die allgemeinen Bemühungen derselben Person zu messen, die in Bezug auf Umfang und Technologien ähnlich sind. Sie können dabei helfen, die Fähigkeiten von Entwicklern zu entwickeln, die nicht immer von Vorteil sind. Wenn Ihr "langsamer" Entwickler an der Verwaltung, Planung, Planung und Warteschlangenplanung beteiligt ist, werden diese nicht entwickelt.

Sie können davon profitieren, zu lesen und zu teilen Vom schlimmsten zum besten in 9 Monaten: Implementierung einer Drum-Buffer-Rope-Lösung in der IT-Abteilung von Microsoft mit Ihrem Team.

Da dies im Projektverwaltungsstapel enthalten ist, beachten Sie, dass Ihr lose definiertes Problem nicht spezifisch für (Scrum) Agile ist. Im Allgemeinen kann gesagt werden, dass das Projektmanagement in Software Teammitglieder die Arbeit innerhalb eines bestimmten Zeitrahmens erledigt. Lernen, die Zeit bis zur Fertigstellung zu schätzen, ist eine Fertigkeit. Ob als Entwickler bei der Einschätzung, wie lange eine neue Funktion benötigt wird, oder als Projektmanager, um zu bestimmen, ob die Anzahl der Personen Stunden im Budget liegt.

Projektmanager sind typischerweise keine Personalmanager oder Supervisoren. Wenn der Schwerpunkt auf der Bereitstellung von Features durch die Einzelperson oder den Unterauftragnehmer liegt, kann dies Auswirkungen auf den Zeitplan und die Kosten des Projekts haben. Wenn das Hauptaugenmerk auf der Leistung des Einzelnen liegt, ist dies ein Personalproblem, das im Zusammenhang mit einer Positionsbeschreibung und Erwartungen im Einstellungsvertrag sowie mit der Fähigkeit, zu dokumentieren, wann Erwartungen nicht erfüllt werden, berücksichtigt werden kann, damit sie diese verbessern oder ersetzen können Erfüllung der Vorgaben im Rahmen von Budget und Zeit.

Einfache Maße der Anzahl von Merkmalen, die bei jedem Sprint unabhängig voneinander implementiert werden, vielleicht mit Attributen für die Komplexität (z. B. Geschichtenpunkte), können von Personen Geschwindigkeit zeigen. Es bedarf des Kontextes, um zu wissen, dass dies "langsam" oder akzeptabel für die gesamten Projektpläne ist.

0
hinzugefügt