Wie sollte ein Scrum Master mit langen Zykluszeiten von Einzelpersonen in einem Team umgehen?

Sehen Sie sich zunächst an, ob Sie Ihre Geschichten nicht mehr aufteilen können.

Zweitens, warum kooperieren die Ingenieure in Ihrem Team nicht? Die Art und Weise, wie Sie Ihr System beschreiben, klingt so, als hätten Sie eine Mindestgrenze für laufende Arbeiten von einer Geschichte pro Entwickler festgelegt. Natürlich ist Ihre Zykluszeit hoch ( Zykluszeit = Wip / Durchsatz immerhin). Kooperieren Sie stattdessen an Dingen, um die laufenden Arbeiten zu reduzieren.

Ich kann Ihnen sagen, dass einige Ihrer Ingenieure besser sind als andere. Ich denke, das, was ich bereits vorgeschlagen habe, die Förderung der Zusammenarbeit bei Aufgaben, wird dazu beitragen, die Fähigkeiten der schwächeren Ingenieure zu verbessern. Es gibt jedoch noch viele andere Faktoren des Personalmanagements. Ich werde sie nicht alle auflisten, aber bekommen die Leute die Werkzeuge, die sie brauchen, das Training, das sie wollen, die freie Zeit, um ihre Fähigkeiten zu verbessern, Zeit, um zu Konferenzen zu gehen usw. usw.? Beziehen Sie Ihre besten Entwickler als wichtige Entscheidungsträger in den Einstellungsprozess ein? Die Leute haben Bücher über solche Dinge geschrieben, also werde ich hier aufhören.

Erstens ist schneller nicht immer besser. Einer der Ingenieure, mit denen ich zusammengearbeitet habe, beendete seine Geschichten extrem schnell, viel schneller als der Rest des Teams. Aber er benutzte oft schnelle und schmutzige Abkürzungen, und die Tester schenkten den User Stories dieses Ingenieurs ausdrücklich besondere Aufmerksamkeit. Er produzierte andere Fehler als der Rest der Ingenieure, schwieriger zu finden, aber oft mit großer Wirkung.

Wenn genügend Vertrauen in das Team besteht, besprechen Sie die Geschwindigkeitsunterschiede mit dem gesamten Team und fragen Sie sie, welche Faktoren ihrer Meinung nach die Unterschiede erklären können. Einige Möglichkeiten umfassen persönliche Faktoren (Motivation, Antrieb, Perfektionismus), Fähigkeiten und Kenntnisse, das Ausmaß der Ablenkung (Solisten vs. Menschen, die anderen immer helfen, anstatt ihre eigenen Aufgaben zu erledigen) oder unterschiedliche Ansichten zu Qualität/Umfang/Definition of Done.

Versuchen Sie, die schnelleren Ingenieure mit den langsameren zusammenzubringen (und fördern Sie im Allgemeinen die Zusammenarbeit) – beide können von der Zusammenarbeit lernen.

Wenn Sie Ihre Zykluszeit verkürzen möchten, ist es an der Zeit, die Theory of Constraints anzuwenden . Suchen Sie nach Stellen, an denen sich die Arbeit häuft, und arbeiten Sie dann daran, den Engpass zu beseitigen.

Natürlich muss die Arbeit erst einmal sichtbar genug sein. Ein einfaches Todo-doing-done-Board wird es nicht schaffen. Sie müssen den tatsächlichen Workflow modellieren, um den Engpass zu erkennen. Backlog-Ready-In Progress-Review-QA-Ready to Deploy-Done ist ein wahrscheinlicher Workflow. Wenn sich die Dinge in der QA häufen, lassen Sie sich von einigen Entwicklern helfen. Wenn Dinge schneller überprüft werden müssen, finden Sie heraus, wie Sie dies erreichen können. Dauern Bereitstellungen Stunden? Automatisieren Sie sie. Usw.

Wie von anderen erwähnt, ist der andere Hebel, den Sie ziehen müssen, das WIP-Limit. Reduzieren Sie Ihr WIP-Limit und den durchschn. Zykluszeit sollte fallen.

Am wichtigsten ist, dass das Team genügend Spielraum im Zeitplan lässt, damit es sich verbessern kann . Es hilft nicht, einen Engpass zu identifizieren, wenn niemand das Gefühl hat, Zeit zu haben, ihn zu beheben.

Wir hatten die gleichen Probleme: Das Team, das ich als Scrum Master übernahm, wurde von den POs, anderen Entwicklern und so weiter als langsam angesehen.

Bei der Untersuchung sind dies die identifizierten Probleme (und die von uns implementierten Lösungen):

• Rückstandsposten waren nicht klar. Während des Sprints wurde viel Zeit damit verbracht, Stories zu untersuchen => wir teilen Stories in Spikes (Recherche), Stories, Tasks/Sub-Tasks, Bugs auf. Nun konnte man deutlich sehen, wie lange die Recherche für eine Geschichte gedauert hat und wie lange die eigentliche Codierung. Ich habe auch mit der PO zusammengearbeitet, um mehr zu recherchieren, bevor ich Geschichten in den Rückstand schiebe.
• Das nächste Problem war, dass die Geschichten (nach der Implementierung des vorherigen Elements) nicht richtig aufgeteilt wurden. Wir teilen eine Geschichte so auf, dass sie so lang wie ein Sprint oder kürzer ist, wenn möglich. Ich habe dieses Problem mit Mike Cohn bei seinem kürzlichen User Stories-Training angesprochen; Seine Empfehlung ist, Geschichten so viel aufzuteilen, wie es für die Entwickler sinnvoll ist, verschwenden Sie nicht viel Zeit, um sie so klein wie möglich aufzuteilen, aber definitiv kürzer als ein Sprint.
• Als nächstes haben wir uns mit dem von Ihnen erwähnten Problem befasst – sind einige Entwickler langsamer als andere? Natürlich, aber in unserem Fall lag es nicht daran, dass die Schnellen zu den Abkürzungen gehörten, es liegt an der Betriebszugehörigkeit und dem Wissen über Geschäft und Produkt. Also haben wir uns für Pair Programming entschieden: Ein erfahrener Programmierer paart sich mit einem Junior, um Wissen und Lernen zu verteilen.

Das obige hat sehr gut funktioniert. Wir haben unsere Geschwindigkeit in nur 4 Sprints um mindestens 30% gesteigert. Aber ich bin mir bewusst, dass der Anstieg darauf zurückzuführen sein könnte, dass wir die Stories von Anfang an nicht richtig geschätzt haben, also arbeiten und überwachen wir weiter.

TL;DR alles beginnt mit der Planung, wie Sie Geschichten aufteilen und schätzen. Beginnen Sie von dort aus.