Ich arbeite als Scrum Master in einem Team mit Entwicklern und QAs. In der Organisation, für die ich arbeite, haben wir alle sechs Monate einen Überprüfungszyklus. Direktoren führen die Bewertung des Scrum-Teams basierend auf agilen Prinzipien und Teamergebnissen durch, und Manager führen die Bewertung von Einzelpersonen durch. Aber wir haben keinen formellen Feedback-Prozess vom Scrum-Team an die Manager für einzelne Teammitglieder .
Was ist zum Beispiel, wenn ein Teammitglied seinen/ihren Arbeitsstil ändern möchte und dies auch nach mehreren Diskussionen nicht geschieht? Der Grund, warum ich denke, dass ein formaler Prozess notwendig ist, weil ich das Gefühl habe, dass die Leute glauben, dass sie nicht zum Scrum-Team gehören, da das Scrum-Team bei Beurteilungen / Bewertungen nicht beteiligt ist und alles immer noch in den Händen des Managements liegt.
Ich habe mich gefragt, ob Sie sich mit so etwas befasst haben. Was war Ihre Lösung?
BEARBEITEN
Etwas mehr Informationen: Wir haben gemischte Ziele – ein Teil der Ziele ist teambasiert, die die Direktoren basierend auf der Leistung des Teams betrachten, und ein Teil davon sind individuelle Ziele, die Manager auf der Grundlage ihres Verständnisses von Einzelpersonen und Erwartungen festlegen. Es gibt keine Diskussion zwischen Scrum-Team und Managern, während die individuellen Ziele festgelegt werden. Dabei kann es um Soft- oder Hard Skills gehen. Aber die Arbeit wird im Scrum-Team erledigt und das Scrum-Team kennt keine individuellen Ziele. Aber sie sinddennoch nach sechs Monaten ausgewertet. Wenn es nur teambasierte Ziele wären, würde ich mir keine Sorgen machen. Aber wenn Einzelziele mit Teamzielen kollidieren, dann würden Mitarbeiter Einzelzielen den Vorzug geben (oder was auch immer die Führungskraft sagt), denn am Ende entscheidet zumindest bei Einzelzielen ihre Meinung über die Beurteilung.
Das Beispiel, das ich gegeben habe, war ein allgemeines Beispiel. Es kann auch gut sein (jemand geht aus dem Weg). Das Problem, das ich sehe, ist, dass es keine Möglichkeit gibt, das zu erkennen. All dies braucht einen Prozess, in den es einfließen kann. Ich habe in der Vergangenheit versucht, Feedback an den Manager zu senden, da der Manager über die Bewertung individueller Ziele entscheidet, aber dies wurde, wenn überhaupt, nur vorübergehend berücksichtigt. All diese Komplexität lässt mich glauben, dass es Feedback vom Scrum-Team zum Management geben muss. Die 360-Grad-Feedback-Vorschläge erscheinen mir in Ordnung. Ich möchte überhaupt nicht zum Manager erhoben werdenaber ich weiß nicht, wie ich das Team schützen kann, wenn das Feedback des Scrum-Teams nicht Teil des Bewertungsprozesses ist. Wäre es ideal, ein 360-Grad-Feedback zu haben (machen Sie das in Übereinstimmung mit Agilität) oder ist es nur irgendwie, agile Arbeit in einer Mischung aus traditionellem Management und Agilität zu machen? Oder wäre es ideal, nur teambasierte Ziele zu haben, oder sollte das Scrum-Team Diskussionen mit Managern führen, während es über individuelle oder andere Ziele entscheidet?
Was ist Ihre Interpretation eines ScrumMasters ?
Ich frage, weil eine Mitarbeiterbeurteilung keine klassische Aufgabe eines ScrumMasters ist . Unabhängig davon, ob die Evaluation irgendwie mit dem agilen Prozess zu tun hat oder nicht.
Aber wir haben keinen formellen Feedback-Prozess vom Scrum-Team an die Manager für einzelne Teammitglieder.
Ich bin mir nicht sicher, ob dies überhaupt ein fruchtbarer Prozess wäre. Ein solcher Prozess könnte einige kritische Teamprobleme aufwerfen. Trotzdem widerspricht es einigen Prinzipien von Scrum.
Und bedenken Sie, dass das Management in erster Linie an der Teamleistung interessiert ist, nicht an der Einzelleistung.
Was ist zum Beispiel, wenn ein Teammitglied seinen/ihren Arbeitsstil ändern möchte und dies auch nach mehreren Diskussionen nicht geschieht?
Aus reiner Scrum-Perspektive muss das Team das Problem handhaben. Das bedeutet, dass das Team einen Weg finden muss, den Teamkollegen so zu integrieren, dass er/sie unabhängig von seinem/ihrem eigenen Arbeitsstil für das Projekt wertvoll wird. Wie ich bereits geschrieben habe, liegt die Bewertung der Leistung eines Teammitglieds nicht in der Verantwortung eines ScrumMasters .
Wie von JDRodger entwickelt, ist der ScrumMaster dafür verantwortlich, bei der Lösung solcher Probleme zu helfen, um die Teamproduktivität zu verbessern. Es ist vielleicht ein bisschen off-topic, aber mal sehen, was Sie tun können.
[...] was ist, wenn ein Teammitglied seinen/ihren Arbeitsstil ändern möchte und dies auch nach mehreren Diskussionen nicht geschieht?
Das Wort Diskussionen (wie Sie es verwendet haben) hat für mich eine negative Konnotation. Daher deutet die von Ihnen beschriebene Situation bereits auf einen Konflikt hin, und ich schätze, Sie befinden sich sehr wahrscheinlich mittendrin.
Leider beschreiben Sie wichtige Details nicht, wie wer beteiligt ist, wie Sie das Problem erkannt haben, was Ihrer Meinung nach die Ursache des Problems ist usw. (bitte weitere Details hinzufügen).
Wie auch immer, als Faustregel gilt, versuchen Sie, solche Situationen zu vermeiden, mischen Sie sich nicht ein, nehmen Sie niemanden auf die Seite, versuchen Sie, immer so neutral wie möglich zu bleiben. Ich weiß, das ist nicht einfach, aber es ist die beste Position, die man haben kann (um solche Konflikte zu lösen).
Sicherlich können Sie als ScrumMaster Konfliktsituationen nicht immer vermeiden . Sie haben bestimmte Verantwortlichkeiten, die zu Konfrontationen führen können.
Nehmen wir zum Beispiel an, ein Teammitglied erscheint nicht regelmäßig zum Daily Scrum. Irgendwann sieht man es als notwendig an, dass sich das gesamte Entwicklerteam dem Daily anschließt (zumindest wenn es möglich ist).
Das Schlimmste, was Sie tun können, ist, den Teamkollegen direkt zu konfrontieren und eine Diskussion zu beginnen wie "Warum bist du nicht bei den Dailies dabei?", "Du musst wie alle anderen mitmachen!"
Etwas besser, aber auch nicht perfekt „Es wäre gut für das Projekt und auch für deine Teamkollegen, wenn du bei den Dailys mitmachen könntest. Du bist ein wichtiger Teil davon.“
Versuchen Sie also niemals, jemanden zu konfrontieren, indem Sie herrisch oder erzieherisch sind, und behandeln Sie ihn wie ein Kind. Das Beste, was Sie in einer solchen Situation tun können, ist, tief durchzuatmen und einen Schritt zurückzutreten. Sehen Sie, wie sich die Situation entwickelt, sehen Sie, ob dies wirklich ein Problem für das Team und den Projekterfolg ist.
Stellt sich heraus, dass dies ein Problem darstellt, müssen Sie handeln. Sprechen Sie das Problem während einer Sprint-Retrospektive an (wenn kein anderes Teammitglied dieses Problem anspricht); und noch einmal, seien Sie neutral, ergreifen Sie keine Partei und hören Sie zu.
Bestenfalls finden die Teammitglieder eine Lösung. Wenn nicht, versuchen Sie, sie in die richtige Richtung zu drängen; Denken Sie daran, seien Sie nicht herrisch, keine Erziehung. Geben Sie eine neutrale Aussage ab: „Vielleicht sollten Sie das nächste Mal in Ihren Tageszeitungen besprechen?“.
Konflikte zu lösen ist also nicht einfach. Und wie man sie richtig löst, hängt vom konkreten Konflikt ab. Die Ultima Ratio ist, es zu eskalieren und direkt an das Management zu gehen (oder indirekt durch einen Feedback-Prozess). Aber solche Aktionen spielen nicht unbedingt gut für Sie oder das Team.
Merken,
Individuen und Interaktionen über Prozesse und Tools (1) .
Ich habe gesehen, dass die folgenden Dinge funktionieren:
Hat Spotify Manager? „Spotify hat Manager, es ist nur eine andere Perspektive.“
Dies ist ein weiterer weit verbreiteter Irrglaube. Wir haben Manager, es ist nur eine andere Perspektive. Anstelle von Teammanagern haben wir Linienmanager, die wir Chapter Leads nennen. Sie kümmern sich um all die Leute mit den gleichen Fähigkeiten in den Trupps. Zum Beispiel könnte ich der Chapter Lead für alle Android-Entwickler sein. Das Coole ist, dass Chapter Leads Teilzeit-Entwickler sind, sie sitzen normalerweise selbst in einem der Squads.
Ich würde beides machen. Behandeln Sie Menschen als Menschen und nicht als Ressourcen. Trainieren Sie sie, aber wenn das Team denkt, dass sie keine Leistung bringen und sie sich Veränderungen widersetzen, werfen Sie sie aus dem Team. Lassen Sie das Management herausfinden, was mit ihnen zu tun ist. Teamwork ist in Agile so wichtig, dass es effektiver ist, mit weniger Menschen zu arbeiten als mit jemandem, der sich Veränderungen widersetzt. Finden Sie etwas zu tun für sie, wo sie ein Einzelgänger sein können :)
Dies wurde bereits beantwortet und vorgeschlagen, aber ich glaube, dass 360-Grad-Feedback die richtige Lösung ist, vorausgesetzt, das Team ist reif genug.
Geben Sie jedem Mitglied des Scrum-Teams eine anonyme Umfrage, um andere Teammitglieder zu bewerten. Stellen Sie ihnen die 5 wichtigsten Fragen, von denen Sie glauben, dass sie die KERNwerte Ihres Unternehmens und Ihre Erwartungen an diese Person sind. Versuchen Sie, die Fragen objektiv zu halten und lassen Sie die Leute auf einer Skala von 1 bis 10 bewerten. Geben Sie die letzte Frage als "Feedback über Person X, die Sie haben" und lassen Sie die Leute schreiben, was sie wollen. (Sie anleiten, konstruktive Kritik zu äußern)
Problem Nr. 1. „Das Teammitglied muss seinen/ihren Arbeitsstil ändern und es geschieht auch nach mehreren Diskussionen nicht?“ - Es ist schwer, Menschen ohne Daten zu überzeugen. Wenn Sie mit ihm/ihr mit Daten wie „4 von 5 Teammitgliedern bewerten Ihren Beitrag zum Erfolg des Teams mit 4/10, während der Teamdurchschnitt für diese Frage bei 8/10 liegt“ diskutieren. Dies würde andere Leute glauben machen, dass, wenn jeder so denkt, er/sie besser hart arbeiten sollte.
Problem Nr. 2. „Die Leute denken, dass sie nicht zum Scrum-Team gehören, da das Scrum-Team bei Beurteilungen/Bewertungen nicht involviert ist und alles immer noch in den Händen des Managements liegt.“: Verwenden Sie diese Daten auch in Beurteilungen, nicht vollständig, aber möglicherweise X% zu Beginn. Jetzt werden die Menschen glauben, dass Beurteilungen/Bewertungen wissenschaftlicher sind und nicht nur auf einer einzelnen Meinung beruhen, die voreingenommen sein kann.
Gummiente