Dominante Teammitglieder in einem Scrum-Team

Was würden Sie in einer Situation tun, in der ein Teammitglied versucht, Verantwortlichkeiten zu übernehmen, die ursprünglich nicht ihm, sondern dem Scrum Master zugewiesen wurden?

Das Scrum-Team ist selbst organisiert und bietet Platz für jemanden, der etwas dominanter ist. Andere sollten ihn nach seinen Vorstellungen zu den Aufgaben fragen, an denen sie arbeiten, aber seine Dominanz muss unter Kontrolle gehalten werden.

Was du tun kannst:

• Andere motivieren, unabhängig, aber kollaborativ zu sein - dies lässt sich am besten erreichen, wenn Sie mit ihrem Manager und der Personalabteilung zusammenarbeiten, die ihnen einige Erwartungen stellen, die regelmäßig bewertet werden.
• Während Stand-ups, Planungen und Rückblicke; Lassen Sie andere Teammitglieder zuerst sprechen. Lassen Sie andere Teammitglieder während der Überprüfungen User Storys präsentieren, die sie implementiert haben.
• Lassen Sie andere zuerst Aufgaben auswählen, damit der dominierende Entwickler nicht nur die Aufgaben auswählen kann, die er ausführen möchte.
• Beziehen Sie die Paarprogrammierung für einige Aufgaben mit ein, damit das dominierende Teammitglied mit anderen Entwicklern zusammenarbeitet.
• Seien Sie demokratisch - die Meinung eines Teammitglieds reicht nicht aus, um Änderungen am Prozess vorzunehmen - Scrum funktioniert nur, wenn das Team klar kommuniziert, oder Sie blockieren sich gegenseitig.
• Wenn dies nicht hilft, sollten Sie mit dem dominierenden Teammitglied sprechen und ihm die Situation erklären - aber achten Sie darauf, dass es in Scrum keinen Teamleiter aus einem bestimmten Grund gibt. Wenn Sie Unterstützung vom Management haben, könnten Sie auch seine Arbeitsplatzstabilität gefährden, aber dies sollte die allerletzte Option sein.

Wenn das dominante Teammitglied seine Dominanz nicht verlieren und die passiven Teammitglieder nicht aktiver werden möchten, benötigen Sie die Unterstützung ihres Managers und der Personalabteilung. Dies kann ein Problem sein, wenn das Management den Scrum-Prozess nicht unterstützt.

Vermutlich liegt der Grund für diese Frage darin, dass Sie das Gefühl haben, dass das Team aufgrund dieser dominanten Person in irgendeiner Weise unterdurchschnittlich ist. Vielleicht, weil der Rest des Teams nicht 100% beiträgt, weil, na ja, worum geht es?

Wenn Sie es sind, liegt es in Ihrer Verantwortung, als Manager sicherzustellen, dass alle Ihre Mitarbeiter verstehen, was ihre Rollen sind. Insbesondere, was von ihnen erwartet wird und wie sie bewertet werden. Als Teammitglied in einem Scrum-Team ist jede Person persönlich für den Erfolg des Teams verantwortlich. Dieses dominierende Teammitglied muss also wissen, dass es dieser Verantwortung nicht nachkommt, und wird entsprechend bewertet.

Feedback ist ein zentraler Punkt. Wenn es eine Teambesprechung gibt und diese Person die Diskussion dominiert, dem Rest des Teams seine Entwürfe und Herangehensweisen aufdrängt und den Rest in passive Rollen drängt, muss ihm direkt und privat mitgeteilt werden, dass er die Anforderungen nicht erfüllt der Rolle. Wenn Sie feststellen, dass er nur seine persönlichen Erfolge auffällig hervorhebt, muss er darauf hingewiesen werden und verstehen, dass persönliche Erfolge weitaus weniger geschätzt werden, als dem Team zu einer Gruppenleistung zu verhelfen.

All das ist hart, aber genau dafür sind Manager und Scrum Masters da.

Es gibt noch einen anderen Weg, dies zu tun. Machen Sie es zu einem Teamproblem. Rufen Sie sie zusammen und sagen Sie ihnen, dass sie unterdurchschnittlich sind und warum. Bitten Sie sie, eine Lösung zu finden. Sie könnten überrascht sein.

Fragen Sie den Alpha-Entwickler nach seiner Meinung. Es ist durchaus möglich, dass er keine Ahnung hat, welchen Effekt er hat. Nehmen Sie ihn beiseite und sagen Sie ihm, was Sie denken. Sie könnten sogar die Diskussion über "Hey, Sie sind unser Hauptentwickler, aber wir müssen diese Leute auf Ihr Niveau bringen. Ich brauche Ihre Hilfe bei der Ausarbeitung, wie wir das machen können." Verwandle seine Dominanz in einen Aktivposten. Sehen Sie, ob er Möglichkeiten dafür sieht.

Wenn er misst, wie gut er sein Team unterstützt und auf sein Niveau bringt, wird er mehr Motivation haben, genau das zu tun.

Sie implizieren, dass er tatsächlich nicht im Interesse des Teams arbeitet (meine Vermutung), dh er ist in irgendeiner Weise böse, dann entfernen Sie ihn. Aber ein weiser Mann sagte einmal zu mir: Nimm keinen bösen Willen an, wenn Unfähigkeit oder einfache Unwissenheit wahrscheinlicher sind.

Sieht aus wie er versucht, der Scrum Master zu sein.

Klären Sie Ihre Positionen und handeln Sie entsprechend.

Die Rolle des Scrum Masters ist es, Teamgeist zu ermöglichen. Wenn Sie diese einzige Person nicht zum Teamplayer machen können, entfernen Sie sie aus dem Team .

Kurzer Hinweis: Ihr dominanter Entwickler ist nicht problematischer als Ihr passiver Entwickler.

Derzeit ist die Sprintplanung eine teamübergreifende Aufgabe

Die Sprintplanung sollte das gesamte Team einbeziehen und nicht an jeweils eine Person weitergegeben werden. Sofern es keinen triftigen Grund dafür gibt, sehe ich dies als ernstes Problem an.

Wenn das, was Sie sagen, wahr und objektiv ist, haben Sie ein großes Problem: Menschen, die nicht teilnehmen, und der "Dominator", der einen wirklich agilen Prozess verhindert. Als Spielleiter liegt es an Ihnen, Maßnahmen zu ergreifen. Vielleicht möchten Sie Ihren Projektmanager in dieser Situation vertrauen.

Viele Teams verlassen den Kern von Agile und es ist Ihre Aufgabe , sie zurückzubringen. Sie müssen dem Team agile Werte beibringen und wieder einbetten. In der Tat sollten Sie ständig agile Werte vermitteln. Halten Sie Ihre Vision von Agilität aufrecht, machen Sie sie klar und überzeugend. Zeigen Sie ihnen Ihr Engagement für "Agile gut gemacht".

Führen Sie sie dazu durch die agilen Manifest- und Scrum-Werte. Fragen Sie sie, was Zusammenarbeit für sie bedeutet und warum es wichtig ist. Fragen Sie sie nach der Rolle des Vertrauens in Agile. Dies ist eine großartige Zeit, um darüber zu sprechen, warum es in Scrum keine Teamleiterrolle und keine Projektleiterrolle gibt und dass es in der Verantwortung des gesamten Teams liegt , großartige Software zu entwickeln, nicht der Einzelne.

Planen Sie eine komplette Retrospektive. Bringen Sie sie dazu, sich auf einige Werte zu verpflichten und diese in der nächsten Retrospektive zu verfolgen. Zeigen Sie nicht mit den Fingern, sondern wenden Sie neutrale Methoden an.

Führen Sie Methoden ein, die die anderen Mitglieder zwingen, ihre Meinung sicher zu äußern. Etwas Einfaches wie Fünffaches ist großartig, um die leisen Stimmen im Team zu hören. Es macht schmerzlich deutlich, dass das Team mit dem dominierenden Mann nicht einverstanden ist. Planning Poker funktioniert gut, aber der Schlüssel ist, keine Diskussionen zuzulassen, bevor die Karten gezeigt werden. Alles, was dazu beiträgt, die anderen anzuhören, ohne Konflikte auszulösen, ist hilfreich.

Wenn das gut geht, sind Sie fertig. Ansonsten sprechen Sie mit ihm über das Problem. Setzen Sie Coaching ein und stellen Sie schlagkräftige Fragen, die ihm helfen können, das Problem klar zu erkennen. Versuchen Sie, die Ursache zu finden, warum er die dominierende Rolle übernommen hat. Vielleicht hat er kein Vertrauen in die Mannschaft (warum?) Und vielleicht fühlt er sich für den Erfolg verantwortlich (warum?). Ich vermute, diese Rolle ist nicht etwas, das er will und möglicherweise möchte er, dass es sich ändert. Er kommt vielleicht vorbei und merkt es.

Vielleicht wird der "dominante" Entwickler eher durch seine individuelle Leistung als durch Teamleistungen belohnt?

In der Vergangenheit habe ich dafür gesorgt, dass Menschen, die sehr lautstark sind und klare Ideen haben, auch (über ihre Ziele) belohnt werden, indem sie andere Beiträge fördern.

Generell halte ich es für eine schlechte Idee, Scrum-Mitglieder solide für ihren individuellen Beitrag zu belohnen und nicht für Teamleistungen.

Sie können auch versuchen, in Ihrem Team eine 360-Grad-Runde für alle Teammitglieder durchzuführen, wenn Sie der Meinung sind, dass die Kommentare der anderen Teammitglieder wahrheitsgetreu sind.

Schlagen Sie vor, dass er der Scrum Master für den folgenden Sprint wird.

Menschen, die bereit sind, Verantwortung zu übernehmen, sind kein Problem (solange sie kein Monopol über sie haben wollen), sondern genau das, was wir mit Selbstorganisation erreichen wollen.

Teams mit einer rotierenden Scrum-Master-Rolle sind übrigens keine Seltenheit.

Die einzige Aufgabe des Scrum-Masters ist es, sicherzustellen, dass alle die Regeln des Scrum-Buches einhalten. Wenn Nicht-Scrum-Meister dies ohne Einmischung des Scrum-Meisters selbst tun würden, würde dies nur zeigen, dass Sie in hervorragender (Scrum-) Form sind! Je weniger der Scrum-Meister tun muss, desto gemeiner und schlanker ist Ihr Team aus der Perspektive von Scrum. Irgendwann könnte / sollte die Rolle des Scrum-Meisters beseitigt werden, er ist da, um Ihnen den Einstieg zu erleichtern und Ihnen Scrum beizubringen.

Auch hier ist der Scrum-Master nicht am Entwicklungsprozess beteiligt. Er sollte sicherstellen, dass alle Stakeholder rechtzeitig über die richtigen Dinge kommunizieren, er kennt Scrum und gibt Hilfestellung bei Scrum, er ist kein Product Owner oder Projektleiter. Wenn Sie etwas anderes erleben, tun Sie Scrum möglicherweise nicht im agilen Geist. Natürlich könnte Scrum Master in kleineren Umgebungen eine Rolle sein, die eines der Teammitglieder oder Stakeholder nebenbei spielt. Dann ist es nur eine Kappe, die man aufsetzt, wenn es Zeit für Formalitäten ist. Verwechseln Sie es nicht mit einer Führungsrolle, es ist eine Führungsrolle.

Umfassen Sie Individualismus und individuelle Leistung, aber versuchen Sie auch, passive Personen dazu zu befähigen, partizipativer zu werden.

Meine Erfahrung sagt, dass Kommunismus und Agilität nicht dasselbe sind, obwohl sie auf den ersten Blick ähnlich erscheinen mögen. Agile zielt nicht auf eine klassenlose Gesellschaft (Team) ab, sondern auf eine funktionierende Software.

Versuchen Sie, Ihrem Alpha-Entwickler klar zu machen, dass er Ihnen beim Entwickeln anderer Fähigkeiten helfen kann, indem er fragt und coacht, anstatt immer zuerst zu antworten und individuelle Erfolge zu erzielen. Sicherlich ist Ihr Alpha-Entwickler einer, dem gute Software am Herzen liegt, und das können Sie sich nicht erlauben, zu verlieren.