Hören Sie zunächst auf, die individuelle Geschwindigkeit zu messen. Die Geschwindigkeit sollte für einen Sprint auf Teamebene gemessen werden und nicht für Einzelpersonen. Ihr Team liefert ein potenziell auslieferbares Softwareprodukt nach einem Sprint, nicht einzelne Personen. Da Scrum auf selbstorganisierenden, funktionsübergreifenden Teams basiert, sollte Ihre Geschwindigkeit alles umfassen, was mit der Erstellung der Lieferung zu tun hat, von der Pflege der Anforderungen bis hin zu Tests und Verifizierung.

Das nächste Problem ist eine Frage des Personalmanagements. Wenn Sie Scrum verwenden, basiert der Prozess auf einem funktionsübergreifenden Team. Wenn das Entwicklungsteam zusätzliche Schulungen benötigt, um ausreichend funktionsübergreifend zu sein, sollten sie über die erforderliche Ausbildung und Schulung verfügen. Dies können Paarprogrammierung, teamübergreifende Schulungen, Lunch-and-Learns, externe Schulungen oder das Einbeziehen von Ausbildern sein. Die Last liegt beim Einzelnen, zu verstehen, welche Fähigkeiten er entwickeln muss, und mit dem Management zusammenzuarbeiten, um diese Fähigkeiten zu entwickeln. Auch das Management sollte dasselbe tun – Qualifikationslücken identifizieren, die notwendigen Ressourcen bereitstellen, um diese Lücken zu schließen, und die Mitarbeiter dazu ermutigen, dies zu tun.

Wenn Sie einen Mitarbeiter haben, der die Anforderungen des Unternehmens nicht erfüllt, ist das ein Problem des Personalmanagements. Es wird im Scrum-Framework nicht behandelt.

Es ist also schwer zu wissen, was genau los ist. [...]

Wie kann ich die Produktivität des langsameren Entwicklers verbessern?

Überprüfen Sie zunächst Ihre Erwartungen. Sollen sie die gleiche Arbeit machen ? Haben sie den gleichen Titel, werden sie gleich bezahlt? Ist der eine absolut gesehen wirklich langsam oder ist der andere einfach nur richtig gut?

Wenn Sie nur zwei der langsamen Art hätten, würden Sie sie trotzdem behalten? Wenn nicht, was würdest du stattdessen tun und warum machst du es jetzt nicht mit nur einem?

Wenn diese Fragen für Sie selbst beantwortet sind, können Sie von außen wenig tun. Fragen Sie Ihren Entwickler, welche Probleme er hat. Frag ihn, ob er etwas braucht. Hilfe, Training, bessere Tools, vielleicht ein anderer Arbeitsplan. Arbeite mit ihm, damit es ihm besser geht. Wenn er dies nicht tut, müssen Sie entsprechend den Antworten, die Sie zuvor gefunden haben, Maßnahmen ergreifen.

Das alles ist kein Scrum-Prozess. Es ist normales Management. Scrum funktioniert nur mit Teams und Ihr Team hat Probleme. Es besteht aus zu wenigen Mitgliedern, es misst Dinge, die nicht gemessen werden sollten (individuelle Geschwindigkeit existiert nicht) und es scheint, dass 50 % Ihres Teams mit der Arbeit der anderen 50 % unzufrieden sind. Wenn Sie dies „agil“ halten wollen, sollten Sie die Fragen, wie Sie Ihren langsameren Entwicklern helfen können, effektiver zu arbeiten, in Ihr Retrospektive-Meeting einbeziehen.

'der andere Entwickler sollte dies tun, es wurde ursprünglich an ihn delegiert'

Scrum funktioniert am besten als Pull-Modell, nicht als Push-Modell. Keine Arbeit sollte jemals an irgendjemanden delegiert werden. Das Team zieht Arbeit in den Sprint. Die Teammitglieder ziehen die Arbeit aus dem Sprint auf ihren Schoß. Wenn Sie diesem Modell folgen, wird sich Ihr leitender Entwickler nicht beschweren, dass „ich das nicht tun sollte“, weil die Arbeit nicht im Besitz ist, bis sie tatsächlich begonnen wird .

An diesem Punkt wird das einzige Problem zur individuellen Geschwindigkeit, was ein Anliegen ist, das innerhalb des Teams selbst behandelt werden sollte.

Der schnelle Entwickler hat mir gesagt, dass der langsame Entwickler manchmal untätig ist und in Schüben arbeitet.

Daran ist nichts auszusetzen. Tatsächlich wäre es unglaublich besorgniserregend, wenn ein Entwickler nicht manchmal untätig wäre. Wenn Sie immer nonstop auf Hochtouren gehen, werden Sie schwer ausbrennen. Ebenso ist das Arbeiten in Schüben eine persönliche Präferenz; an sich ist nichts falsch daran.

Er hat 'ok' gesagt, sagt dann aber 'oh, ich wusste nicht, dass die Arbeit so komplex ist'.

Angenommen, der Entwickler spricht ernsthaft und versucht nicht nur, die Schuld abzulenken (was völlig neue Probleme aufwerfen würde, z angesprochen. Möglicherweise in einer Retrospektive. Wenn Aufgaben aufgrund ihrer unsichtbaren Komplexität unterschätzt werden, besteht eine mögliche Lösung darin, mehr Zeit für die Analyse von Aufgaben während des Planungsmeetings (oder der Vorplanung, falls Ihr Unternehmen ein solches hat) aufzuwenden.

Wie kann ich die Produktivität des langsameren Entwicklers verbessern?

Hast du versucht, ihn das zu fragen? Oder noch besser an das gesamte Team? "Können Sie sich vorstellen, wie wir Ihre Produktivität verbessern können?" Wenn Sie nichts bekommen, fragen Sie nach Beispielen. "Pair Programming? Training? Neue Tools? Koffein?"

Es ist allgemein anerkannt, dass es große Produktivitätsunterschiede zwischen sehr guten und durchschnittlichen Entwicklern gibt. Lesen Sie Michael Lopp Managing Humans für eine gute Erklärung.

Es gibt zwei Probleme:

Erstens ist der langsamere der beiden das Geld wert, das das Unternehmen ihnen zahlt. Wenn ja, dann lass sie weitermachen. Tun Sie, was Sie können, um sie zu trainieren und ihre Entwicklung zu fördern, damit sie besser wird. Andernfalls müssen Sie sich damit auseinandersetzen, dass sie ihre angestellten Aufgaben nicht kompetent und produktiv erledigen können.

Zweitens und noch wichtiger : Stellen Sie sicher, dass Ihr produktiverer Entwickler für seine zusätzlichen Fähigkeiten anerkannt und belohnt wird. Wenn sie sich darüber ärgern, dass ihr Teamkollege das gleiche verdient und nicht so produktiv ist oder so hart arbeitet, laufen Sie Gefahr, dass sie sich ärgern und einen guten Entwickler verlieren (an einen anderen Arbeitgeber wie mich, der sich um sie kümmert :).

Alle Top-Entwickler sind daran gewöhnt, mit anderen zusammenzuarbeiten, die nicht so effektiv arbeiten wie sie. Es ist kein Problem, solange es anerkannt und belohnt wird.

Schnelle vs. langsame Entwickler, schwierige Frage. Schnell heißt nicht gut, quickAndDirtyTM- Lösungen werden Ihnen später immer in den Rücken beißen. Langsamere Lösungen können viel mehr wert sein, wenn sie gut lesbar und wartbar sind. Nachlässig zu denken ist vielleicht auch nicht so schlimm, die meisten Entwickler programmieren nur 10% ihrer Zeit. Den Rest lesen und denken sie.

Das Messen der Produktivität einzelner Entwickler ist schwierig, aber seien Sie vorsichtig mit den Netto-Negativ-produzierenden Programmierern.

„Bei fast allen Projekten gibt es Net Negative Producing Programmers (NNPPs), die genug Verderb einbauen, um den Wert ihrer Produktion zu übersteigen. Daher ist es wichtig, die mutige Aussage zu treffen: Es kann oft produktiver sein, einen schlechten Performer aus dem Team zu nehmen als ein gutes hinzuzufügen."

http://c2.com/cgi/wikix?NetNegativeProducingProgrammer

Es mag hart sein, aber ich habe gesehen, dass das Entfernen des langsamen Programmierers das Team erheblich beschleunigen kann.

Trotzdem würde ich versuchen zu sehen, ob das Team seine Mitglieder auf das gleiche Niveau bringen kann

• Programmieren in Paaren , um das Wissen über Codebasis und Programmiertechnik zu erweitern
• Retrospektiven speziell zum Auffinden von Problemen, die einige Entwickler zurückhalten. Lassen Sie sie versuchen, Lösungen zu finden.

Wenn der langsame Entwickler in seinem Sprint ins Hintertreffen gerät, erledigt der schnelle Entwickler einen Teil der verbleibenden Arbeit.

So soll ein Scrum-Team arbeiten. Sie arbeiten nicht an Ihren Sachen , Ihr einziges Ziel ist es, am Ende des Sprints potenziell auslieferbare Softwareinkremente zu produzieren.

Der schnelle Entwickler hat nichts dagegen , die Arbeit zu erledigen, hat aber Bemerkungen gemacht wie „das sollte der andere Entwickler tun, es wurde ihm ursprünglich übertragen“.

Diese Aussage widerspricht sich, es macht ihm nichts aus, aber er beschwert sich.

Ich mache mir Sorgen, dass mein langsamer Entwickler es hinauszögern könnte, da ich weiß, dass der schnelle Entwickler einen Teil der Lücke auffangen wird, damit wir das Sprintziel erreichen. Ich habe dem langsamen Entwickler gegenüber erwähnt, dass wir daran arbeiten müssen, seine Geschwindigkeit während des Sprints zu erhöhen. Er hat 'ok' gesagt, sagt dann aber 'oh, ich wusste nicht, dass die Arbeit so komplex ist'. Es ist also schwer zu wissen, was genau los ist. Der schnelle Entwickler hat mir gesagt, dass der langsame Entwickler manchmal untätig ist und in Schüben arbeitet.

Dies zeigt einen grundlegenden Mangel an Vertrauen zwischen Ihnen und den beiden Teammitgliedern. Ich möchte den langsamen Kerl nicht verteidigen, aber so ist das bei Software: Schätzungen werden normalerweise nicht eingehalten und es ist einfach zu komplex, um genaue Vorhersagen zu treffen.

Allerdings ... Sie befinden sich möglicherweise in einer Situation, in der Sie tatsächlich Nachlässigkeiten / Underperformer im Team haben und Scrum und Iterationen nichts damit zu tun haben.

Lassen Sie uns die Produktivität der Entwickler verbessern

Wie kann ich die Produktivität des langsameren Entwicklers verbessern?

Sie wissen nicht, warum er "langsamer" ist . Die Frage, die Sie stellen, kann mit "Wie kann ich das Niesen heilen?" verglichen werden. ohne zu fragen woran es gelegen hat .

Ihr „langsamer“ Entwickler könnte: - von seiner Rolle/Projekt/Team demotiviert sein

• fehlendes Know-how für bestimmte Technologien

• einige persönliche Probleme haben (Krankheit/Probleme zu Hause/usw.)

• nicht richtig geeignet sein, um Entwickler zu sein (ja, das passiert)

Kopf hoch fallen mir noch ein paar weitere mögliche Gründe ein.

Lösung für Ihr unmittelbares Leistungsproblem

Versuchen Sie, sich ihm von zwei Wegen zu nähern. Sprechen Sie in erster Linie mit ihm und fragen Sie offen, ob es ihm gut geht, da Sie gemerkt haben, dass er mit der Arbeit ins Hintertreffen zu geraten scheint und Sie nicht raten wollen, was der Grund dafür ist.

Zweitens, wenn Sie sein Manager sind, wäre es gut zu wissen, was seine Geschichte im Unternehmen ist. Wie er eingestellt wurde, wie er bei seinem Team gelandet ist, was seine Berufserfahrung ist. Es gibt Unternehmen, die sehr uneinheitlich in der Einstellungspraxis sind und nur Leute einstellen, die nicht als Programmierer qualifiziert sind, die von Leuten geleitet werden, die keine Qualifikation als Manager haben. Wenn Sie mehr wissen (oder uns weitere Einzelheiten mitteilen), können Sie darüber nachdenken, die Leistung einer Person zu verbessern.

Du musst viel lernen

Wenn Sie sich Ihren Beitrag ansehen, scheinen Sie ein Anfänger-Manager mit einem sehr grundlegenden Verständnis von Scrum zu sein und alle Kernwerte dahinter zu vermissen (z. B. "Ich verwalte die Geschwindigkeit des Teams"). Ich meine das nicht als Beleidigung, sondern als Wissenstest und Lernmöglichkeit. Wenn Sie bereit sind zu lernen, ist der Himmel die Grenze.

Ich würde empfehlen, Peopleware zu lesen, um zu verstehen, was es bedeutet, Manager eines Softwareteams zu sein. Dann folgen Sie ihm durch einige Artikel von Joel Spolsky (beginnen Sie mit TOP10 ganz unten) und dann können Sie ihm ein Buch mit realen Anwendungen von Scrum folgen, die wie folgt erklärt werden: Agiles Projektmanagement mit Scrum . Schauen Sie sich danach Management 3.0 an und lernen Sie modernes Management kennen.

Sie sollten akzeptieren, dass der langsamere Entwickler möglicherweise nie das Tempo des schnelleren erreicht.

Den Background des Entwicklers gibt man im Beitrag nicht an, und ich kann nur vermuten, dass der Schnellere erfahrener ist und/oder schon länger im Projekt ist. In beiden Fällen wird der „Schnellere“ wahrscheinlich immer schneller sein.

Ich kenne dieses Problem immer noch und denke, dass Sie mit den folgenden Rezepten fortfahren sollten:

1) Aus deinem Beitrag habe ich das Gefühl, dass den Entwicklern zu Beginn des Sprints Aufgaben zugewiesen werden. In den meisten Fällen ist dies eine schlechte Praxis – versuchen Sie, eine Liste von Aufgaben zu haben, die als Team im Sprint erledigt werden sollen, keine individuellen Listen.

2) Wenn Sie zu Beginn des Sprints aufhören, Aufgaben zuzuweisen, wird es für die Entwickler viel selbstverständlicher, Aufgaben gemeinsam zu implementieren (auch bekannt als Pair Programming).

Paarprogrammierung mag für Sie beängstigend klingen; Schließlich haben Sie zwei Entwickler eingestellt, um den doppelten Wert zu produzieren, und plötzlich beginnen sie, jeweils an einer Aufgabe zu arbeiten. Wenn Sie jedoch an einer Aufgabe nach der anderen zusammenarbeiten, wird Ihre Geschwindigkeit wirklich verbessert:

• die Kommunikation, die in Paarprogrammierung erfolgt, kann es schneller machen
• es erzwingt eine bessere Konzentration
• Es ist eine großartige Gelegenheit für den langsameren Entwickler zu lernen, wodurch er schneller wird, wenn er einige der Aufgaben alleine umsetzt.

3) Machen Sie Retrospektiven nach jedem Sprint, falls Sie das nicht bereits tun. "Ich dachte, es wäre einfacher", "Ich wusste nicht, dass es so komplex ist" - Reaktionen können in Retrospektive ausgesprochen werden, und der Grund kann ausgesprochen werden - und die Situation kann verbessert werden.

Verdammt, diese Situation kann sogar darauf zurückzuführen sein, dass Ihr schnellerer Entwickler einen so schwer lesbaren/schlechten Code schreibt, dass es für andere Entwickler schwierig ist, daran zu arbeiten. Diese Art von Situation ist von außen sehr schwer zu erkennen, da sich der langsamere Entwickler möglicherweise nicht wohl dabei fühlt, das Problem anzusprechen. Retros & effektivere Kommunikation ist der Weg, um diese Dinge herauszufinden.

Sie haben dies mit #Scrum und #Agilität getaggt, also werde ich die Antworten auf diese beiden Dinge richten.

Dies ist kein Prozess- oder Werkzeugproblem, sondern ein Problem von Personen und Interaktionen. Schauen Sie sich an, was funktioniert, um Einzelpersonen zu motivieren. Ich würde vorschlagen, „Drive“ als grundlegende Zusammenfassung der grundlegenden Motivationswissenschaft des letzten halben Jahrhunderts zu lesen. Hier ist eine kurze Zusammenfassung:

Fahren Sie mit Dan Pink

Konzentrieren Sie sich als Manager auf alle Umwelthindernisse, Anreize, kulturellen Normen usw., die demotivierend sind. Ich fand dieses Modell hilfreich, wenn ich Motivationshindernisse, Effektivität in Scrum-Teams usw. untersuchen wollte

Agilität lehrt uns, dass Individuen und ihre Interaktionen typischerweise wertvoller sind als Prozesse und Tools. Eine logische Folge davon ist, dass ein Problem mit einer Person oder ihren Interaktionen nicht effektiv mit Prozessen oder Werkzeugen gelöst, sondern nur gemildert wird.

Arbeiten Sie zuletzt daran, ein System zu schaffen, in dem sich diese Person selbst aus dem Team oder aus dem Unternehmen auswählen kann, wenn die Dinge wirklich so schlimm sind. Alternativ könnten Sie ein System aufbauen, das eine Hochleistungskultur und Ergebnisse des Scrum-Teams fördert und ermöglicht, und diesem Team einen Rückgriff auf seine eigene Mitgliedschaft geben. Bauen Sie Vertrauen auf, indem Sie diese Mitglieder mit Respekt behandeln und verantwortungsvolles Verhalten fordern. Widmen Sie sich dem Praktizieren von Scrum oder anderen Mitteln, um Transparenz, Inspektion und Anpassung als normative Praxis zu etablieren. Transparenz wird Probleme aufdecken, Inspektion wird die Grundursachen ermitteln und Anpassung wird positive Veränderungen bewirken. Dies kann natürlich die persönliche Verbesserung dieser Person oder ihren Austritt aus dem Team oder der Organisation beinhalten.