Ich bin ein technischer Leiter, der auch Entwickler leitet. Einer der Entwickler (nennen wir sie Alice), den ich leite, arbeitet in einem anderen Scrum-Team als die, für die ich der technische Leiter bin. Die Teams arbeiten alle am selben Projekt. Alice wurde kürzlich in ein Team versetzt, das nicht sehr gut funktioniert und begonnen hat, direkt Möglichkeiten aufzuzeigen, wie es sich verbessern kann. Mein Äquivalent in diesem Team, nennen wir ihn Bob, bevorzugt einen sehr technischen Führungsstil von oben nach unten und hat diesen Neuzugang im Team nicht gut aufgenommen. Er findet auch, dass das Team gut spielt.
Es gab einige Meinungsverschiedenheiten, mehrmals hat Bob seine Autorität genutzt, um Alice zum Schweigen zu bringen und weitere Diskussionen über Möglichkeiten zur Verbesserung des Teams zu verhindern. Ich habe auch Rückmeldungen über Alice erhalten, die sich darüber beschwert hat, dass sie das Team stört und dass sie entlassen worden wäre, wenn sie ein Auftragnehmer gewesen wäre.
Praktischerweise haben wir auch einen Berater/Coach im Team, der seine Arbeitsweise verbessern möchte, mit dem ich dies besprechen konnte, um ein ausgewogeneres Bild zu erhalten. Ihre Ansicht ist, dass Alice in 90 % der Fälle Recht hat und dass das Team eine gesunde Störung braucht, Alice könnte jedoch versuchen, ihre Punkte auf diplomatischere Weise zu vertreten. Ich habe auch mit Alice gesprochen und vorgeschlagen, dass sie damit beginnt, alle ihre Punkte aufzulisten, wo sich das Team verbessern kann, diese Liste zu priorisieren und dann mit dem Trainer zusammenarbeitet, um herauszufinden, wie sie diese dem Team am besten einzeln mitteilen kann anstatt jedes Problem hervorzuheben, sobald es auftaucht.
Obwohl Alice diesem Ansatz für die meisten Dinge zustimmt, glaubt sie nicht, dass sie ein Problem nicht hervorheben und immer wieder hervorheben kann, wenn es sich ihrer Ansicht nach um ein erhebliches Problem handelt, z. B. das Deaktivieren fehlgeschlagener Tests oder das Betrachten eines Tickets trotz eines fehlgeschlagenen Jenkins-Builds als abgeschlossen. Ich stimme ihr in dieser Hinsicht voll und ganz zu, aber Bob ist weiterhin frustriert über Alice, und ich befürchte, dass sich die Situation von einer gesunden Störung zu einer einfachen Störung entwickelt.
Ich habe keine Autorität über Bob, weil er ein Äquivalent ist, und ich glaube nicht, dass es mir helfen würde, mich direkt auf jeden einzelnen von Alice angesprochenen Punkt einzulassen, ich habe auch nicht die Zeit, dies zu tun. Ich habe mich mit mir, Alice, Bob, dem Scrum Master des Teams und dem Coach zusammengesetzt, um zu sehen, ob wir einen Weg nach vorne finden können, und um einige der Punkte zu besprechen, die Alice unbedingt hervorheben möchte. Wenn dieses Treffen nicht gut verläuft und ich allen Grund zu der Annahme habe, dass dies nicht der Fall sein wird, bin ich etwas ratlos, was ich als nächstes versuchen soll, und fühle mich derzeit ziemlich in der Mitte gefangen. Es gibt keine wirkliche höhere technische Instanz, an die dies aufgrund einer ziemlich flachen technischen Managementstruktur eskaliert werden kann, während eine Unternehmensreorganisation weitergeht.
Das ist eine schwierige Situation.
Ich denke, der einfachste Ausweg wäre (vorerst), Alive aus Bobs Team zurück zu Ihrem oder an einen Ort zu bringen, der besser mit ihrem Stil und ihren Werten vereinbar ist. Vielleicht gibt es einen Austausch, der orchestriert werden kann.
Langfristig muss es einen Weg geben, das Missverhältnis zwischen Bob und dir/Alice zu beheben. Sie müssen eine konsistente Kultur und einen einheitlichen Wertekanon aufbauen, sonst werden Sie ständig solche Konflikte haben. Das wird ohne übergeordnete Instanz schwierig, aber vielleicht ändert sich das ja nach der Reorg. Bis es eine einheitliche Kultur gibt, ist das Beste, was Sie tun können, die Kontaktpunkte zu minimieren.
Bob will Alice "feuern", wegen Meinungsverschiedenheiten über die Substanz, nicht nur über den Ausdruck. In der Zwischenzeit denken Sie, dass Alice gute Arbeit leistet, aber vielleicht könnte sie etwas Coaching in Sachen Kommunikation gebrauchen.
Klingt so, als müssten Sie Alice wirklich aus Bobs Projektteam in Ihres versetzen.
Der Versuch, "Hilfe" zu erzwingen, wo sie nicht erwünscht ist, wird einfach nicht funktionieren. Dabei spielt es keine Rolle, wer im objektiven technischen Sinne „Recht“ hat, es reicht, dass es einfach nicht passt.
Frag Bob, ob er sie freilassen will. Dann können die Probleme oder Fortschritte seines Teams seine Probleme oder Errungenschaften sein, und Sie können Alice helfen, ihre Lösungen noch effektiver in einem Kontext zu präsentieren und anzuwenden, in dem ihre Absicht allgemein willkommen ist.
Wenn Ihre Organisation Alice nicht aus einer Situation, in der ihre Hilfe nicht willkommen ist, in eine Situation versetzen kann, in der sie es ist, dann wird sie sie wahrscheinlich als Ressource an eine andere Organisation verlieren, wo ihre Beiträge geschätzt werden.
"Mehrmals hat Bob seine Autorität genutzt, um Alice zum Schweigen zu bringen und weitere Diskussionen über Möglichkeiten zur Verbesserung des Teams zu verhindern."
"separates Scrum-Team".`
Ein Scrum-Team ist ein Team von Entwicklern ohne Rollen. Dies sollte vom Scrum Master dem Entwicklerteam mitgeteilt werden, ob es so arbeiten möchte.
Sprechen Sie mit dem Scrum Master des Entwicklerteams, dem Bob angehört, und informieren Sie ihn über den aktuellen Stand des Entwicklerteams. Auf einem anderen Weg wäre Alice die beste Serverin, indem sie dies auch mit dem Scrum Master und während der Sprint-Retrospektive mit dem gesamten Entwicklerteam bespricht.
Laut OP handelt es sich um ein Scrum-Projekt, daher ist mein erster Tipp, das Scrum-Tag zu verwenden, mit dem der Beitrag leichter gefunden werden kann. Die zweite Kritik ist, dass der Anfangssatz nicht viel Sinn macht.
zitat: „Ich bin ein technischer Leiter, der auch Entwickler leitet. Eine der Entwicklerinnen (nennen wir sie Alice), die ich leite, arbeitet in einem anderen Scrum-Team als die, für die ich der technische Leiter bin.“
In der Scrum-Management-Technik ist der Manager dem externen Kunden gleichgestellt, aber im OP wird behauptet, dass er ein Scrum-Manager innerhalb des Unternehmens ist. Der Grund, warum Scrum agil genannt wird, liegt darin, dass der Product Owner nicht Teil des Teams ist, aber Stress von außerhalb der Organisation erzeugt.
Anstatt die Teammitglieder namentlich anzusprechen, ist es besser, die Benutzer mit ihrer sozialen Rolle anzusprechen. Jedes Teammitglied ist entsprechend dem Jahresgehalt in der Hierarchie eingeordnet. Und der Typ, der nichts bekommt, steht an der Spitze der Pyramide, während die Person, die am meisten verdient, die ganze Arbeit für die anderen machen muss.
Eine Erklärung für die Verwirrung mit Matrixorganisation, sozialen Rollen und fehlender Hierarchie lässt sich damit erklären, dass Scrum ein sehr neues Managementkonzept ist. Es ist normal, dass die meisten klassischen Manager am Anfang Schwierigkeiten haben, sich in ihre Rolle hineinzufinden. Eine empfehlenswerte Art, Scrum während eines Praxisprojekts zu verstehen, ist sich vorzustellen, dass das Team eine Aufgabe in der Notfallleitstelle lösen muss. Eine solche Umgebung tendiert dazu, alleine in Richtung Scrum zu gehen, insbesondere wenn der Stresspegel für den Benutzer erhöht wird, die Anzahl der Ressourcen begrenzt ist und Konflikte sichtbar werden.
Wenn es keine höhere Autorität gibt, könnten Sie die anderen Teamleiter bitten, beim Schreiben einiger technischer Standards zu helfen.
In erster Linie zeigt das Bob (oder möglicherweise Ihnen ;-) den Standard, den alle anderen wollen.
Wenn dies fehlschlägt, können Sie sich an eine nicht-technische Behörde mit dem Beweis wenden, dass Bob kein Teamplayer ist und die heutigen „Unternehmensstandards“ nicht einhält.
Spieler Eins
paulj