it-swarm-eu.dev

Wie gehe ich mit einem kontraproduktiven Scrum-Team um?

Hintergrundgeschichte :
Ich arbeite seit drei Jahren als Teil dieses Teams und in dieser Zeit hatten wir drei verschiedene Scrum Master, die alle Dinge anders gemacht haben.

Aufgrund dieser Änderung bei Scrum Masters und ihrer Art, die Show zu leiten, ist mein Team der Idee von Scrum taub geworden, weil die Prinzipien nicht konsequent durchgesetzt wurden und einer der Scrum Masters eine Person war, die nicht an Agilität glaubt Entwicklung und hielt nur Ereignisse und Artefakte als Anfänger, um Unternehmensentscheidungen zu erfüllen.

Jetzt sind meine Teammitglieder verärgert und gelangweilt, wenn wir Scrum-Events durchführen, und eine Person ist darüber sehr verbal.

Gegenwart :
Vor zwei Monaten ernannte mich das Unternehmen zum Scrum Master meines Teams, weil ich mich dem agilen Arbeiten und seinen Prinzipien verschrieben habe.

Ich leide sehr unter dem atmosphärischen Druck meiner Teammitglieder, die nicht bereit sind, Scrum zu machen.

Wie bereits erwähnt, ärgern sie sich über den gesamten Prozess, was es für mich sehr schwierig macht, weil sie nicht die notwendigen Gespräche führen, die erforderlich sind, um Planning, Retrospective und Daily Scrum effektiv zu machen.

Für sie ist Planung nur Zeitverschwendung, da wir nur den Überlauf in den neuen Sprint verschieben und die Arbeit sowieso nicht abschließen. Warum also die Mühe machen?.

Während der Retrospektive kann ich nur spüren, dass sie "Stop Doing Scrum" sagen wollen. Eine Person tut es, aber die anderen schweigen und ich muss mich jedes Mal damit befassen.

Daily Scrum ist wieder nur Zeitverschwendung für sie, weil keiner von ihnen sich die Mühe macht, zu reden und den Tag zu planen. Sie sagen nur: "Ich habe gestern an Aufgabe X gearbeitet und werde heute wieder daran arbeiten." Und die meiste Zeit scherzen sie nur herum, bis ich strenger werde.

Ich war sehr groß, wenn es darum geht, wie sie ihre Zeit während dieser Ereignisse verbracht haben. Aber ich sterbe innerlich, weil ich eine Leidenschaft dafür habe und sie sich nicht mehr darum kümmern.

Heute sagte mir die Person, die immer gegen mich ist, ich solle aufhören zu sagen: "Sie sagten, das ist es, was sie für diesen Sprint verpflichtet haben", weil er in seinen Worten sagte: "Wir absolvieren nie einen Sprint. Wir bewegen uns nur in Aufgaben und nehmen neue in der auf." nächster Sprint, um eine Quote zu füllen. Wir machen KanBan in Wirklichkeit. Also hör auf, das zu sagen. "

Ich verstehe, warum er das sagt, aber er scheint nicht zu erkennen, dass es so ist, weil es ihm und allen anderen im Team egal ist. Sie arbeiten einfach, anstatt mit Hindernissen umzugehen. Sie beschweren sich über die Hindernisse, tun aber nichts dagegen. Und wenn ich versuche zu helfen, schütteln sie es einfach ab.

Früher war es ihnen egal, aber in den letzten zwei Jahren ist ihre Bereitschaft mehr oder weniger auf den Tiefpunkt gesunken.

Wie kann ich ihnen klar machen, dass Scherzen und Zeitverschwendung während dieser Besprechungen das Unternehmen viel Geld kosten?

111
user42401

Möglicherweise haben Sie viele Statistiken über fehlgeschlagene Softwareprojekte gehört und sind zu dem Schluss gekommen, dass der Fehler nicht technischer Natur ist. Technologische Probleme können über Hunderte von technischen Lösungen gelöst werden, aber das Lösen von Problemen in Ihrer Arbeitsatmosphäre mithilfe von Scrum wird nicht funktionieren.

Mein Vorschlag hier ist, dies nicht mehr als technisches Problem zu betrachten. Es geht nicht um Scrum, es geht nicht um tägliche Stand-ups, Sprints, Retrospektiven oder ähnliches. Sie müssen sich mit Ihrem Team in Verbindung setzen und eine effektive Arbeitsweise finden, die sie sowie Sie und Ihre Vorgesetzten zufriedenstellt.

Wenn sie Tageszeitungen für eine schlechte Idee halten, sollten Sie ihnen nicht sagen, dass sie Tageszeitungen machen sollen, und versuchen, Ihre Argumentation in sie einzubringen. Überlegen Sie selbst, was Tageszeitungen Ihnen bieten. Erkundigen Sie sich bei Ihrem Team, ob diese Vorteile ebenfalls geschätzt werden. Finden Sie heraus, warum sie Ihr Verständnis nicht teilen - wie um ihren Standpunkt zu verstehen, nicht um sie von irgendetwas zu überzeugen. Überprüfen Sie dann, ob Tageszeitungen Ihrem Team tatsächlich helfen oder ob Sie mit einem anderen Mechanismus mehr erreichen können. Das Lustige an Scrum-Meistern ist, dass sie Diener ihres Teams sind - Sie können ihnen am besten dienen, indem Sie Scrum ganz abschaffen.

Zusammenfassend gesagt, hören Sie auf, sich auf Scrum zu konzentrieren, und kehren Sie stattdessen zu den Grundlagen der Agilität zurück. Vielleicht möchten Sie gleich am Anfang mit dem agiles Manifest : Wert von Individuen und Interaktionen über Prozesse und Werkzeuge beginnen.

193
Frank

Nach meiner Erfahrung müssen Teams, die desillusioniert sind, zunächst effektive Rückblicke haben. Deshalb sind meiner Meinung nach Retrospektiven der einzige obligatorische Teil eines agilen Prozesses. Alles andere kann sich im Nachhinein ändern.

In effektiven Rückblicken beschweren Sie sich nicht nur über Ihre Probleme, Sie wählen mindestens eines dieser Probleme aus und identifizieren mögliche Lösungen dafür. Versuchen Sie diese Lösung dann in der nächsten Iteration. In der nächsten Retrospektive sprechen Sie darüber, wie diese Lösung funktioniert hat oder nicht, nehmen gegebenenfalls weitere Anpassungen vor oder wählen ein anderes Problem aus, an dem gearbeitet werden soll.

Wenn Teammitglieder sehen, dass sie die Macht haben, tatsächliche Änderungen in ihrem Prozess zu bewirken, werden sie eher bereit sein, sich zu engagieren.

Der retrospektive Prozess ist, warum, wenn Sie alle Teams eines Unternehmens besuchen, das gut agil ist, alle etwas anders vorgehen. Wir haben einige Teams, die Kanban machen, einige, die XP machen, einige, die nur Montag, Mittwoch, Freitag Standups machen.

Wenn Ihr Team nicht mag, wie Sie mit Kater umgehen, überlegen Sie sich verschiedene Ansätze. Ich habe sehr widerstrebende Entwickler überzeugt, indem ich konsequent im Nachhinein zugehört und Lösungen ausprobiert habe.

65
Karl Bielefeldt

Ok, also fangen wir grob an - ein großer Teil des Problems liegt bei Ihnen - Sie hören, aber Sie hören nicht zu. Ihr Team sagt Ihnen deutlich, wo die Probleme liegen. Sie müssen sie ansprechen, anstatt Ihrem Team die Schuld zu geben.

Planung

Für sie ist Planung nur Zeitverschwendung, da wir nur den Überlauf in den neuen Sprint verschieben und die Arbeit sowieso nicht abschließen. Warum also die Mühe machen?.

Genau. Wenn Sie Aufgaben durchweg nicht die richtige Zeit zuweisen und diese durchweg unterschätzt werden, hat dies sehr negative Auswirkungen:

  • Entwickler fühlen sich ständig unter Druck gesetzt.
  • "Ich kann nichts rechtzeitig erledigen".
  • Da der Prozess nicht funktioniert, sehen sie ihn zu Recht als Zeitverschwendung an.

Lösung: Korrigieren Sie Ihre Schätzungen mit der Kombination von:

  • Story Points (als Kombination aus Zeit und Risiko).
  • Erlaube keine Aufgaben in einem Sprint, die> 55 SP sind
  • Vergleichende Schätzungen
  • Evidence Based Scheduling

Als Grundlage hierfür müssen Sie unbedingt die Zeit nachverfolgen, die tatsächlich benötigt hat, um frühere Aufgaben abzuschließen. Dazu gehören Testen, Schreiben von Dokumentation, Schreiben von Tests, Schulung für Endbenutzer, Integrationsbemühungen und Bereitstellung. usw.

Sobald Sie eine Gesamtzeit für eine bestimmte Aufgabe haben, können Sie die erwartete Zeit auf diesen vorherigen Aufgaben basieren.

Fragen Sie jedes Mitglied, ob sich die ihm übertragene Aufgabe komplizierter oder einfacher anfühlt als die Auswahl vorheriger Aufgaben, und passen Sie die Anzahl der zugewiesenen Aufgaben darauf basierend an.

Wenn Sie SP vorher nicht verwendet haben), ist mein Rat, mit 1 Stunde wirklich ehrlicher Arbeit = 5SP als Richtlinie zu beginnen. Denken Sie daran, dass Sie in der üblichen Entwicklungsumgebung erhalten vielleicht 6 davon pro Tag, also 30SP/Tag max. Lassen Sie niemals eine Aufgabe zu, die länger als 2 Tage dauert, um an die Tafel zu gelangen. Nach meiner Erfahrung sollten Sie im Idealfall 2 Aufgaben pro Tag haben.

Wenn Sie die Planung nicht korrekt ausführen, sehen die restlichen Scrum-Aktivitäten wie Zeitverschwendung aus (einschließlich Planung).

Rückblick

Während der Retrospektive kann ich nur spüren, dass sie "Stop Doing Scrum" sagen wollen. Eine Person tut es, aber die anderen schweigen und ich muss mich jedes Mal damit befassen.

Erinnert mich an Daily beatings will continue until morale improves! und zwei der vergangenen Jobs. Wenn Sie Hindernisse nicht beseitigen, ist dies zu Recht Zeitverschwendung.

Hören Sie noch einmal zu, was die Leute tatsächlich sagen. Wenn die während der Retrospektive vorgebrachten Beschwerden nicht behandelt werden, warum überhaupt?

Damit:

  • Betrachten Sie Six Thinking Hats-Techniken, um die Kommunikation zu verbessern.
  • Reduzieren Sie den Zeitaufwand für die Retrospektive auf maximal 30 Minuten.
  • Stellen Sie sicher, dass während der Retrospektive vorgebrachte Beschwerden vor der nächsten bearbeitet werden.

Tägliche SCRUMs

Daily Scrum ist wieder nur Zeitverschwendung für sie, weil keiner von ihnen sich die Mühe macht, zu reden und den Tag zu planen. Sie sagen nur: "Ich habe gestern an Aufgabe X gearbeitet und werde heute wieder daran arbeiten." Und die meiste Zeit scherzen sie nur herum, bis ich strenger werde.

Klingt so, als hätten Sie hier zwei Probleme: SCRUM-Meetings sind zu lang und Ihre Planung und Aufgabenerstellung ist zum Kotzen.

Beides kann so klingen, als wäre ein Scrum-Meeting Zeitverschwendung.

Für die SCRUM-Länge:

  • Versuchen Sie es mit maximal 15 Minuten.
  • Versuchen Sie alle im Stehen.
  • Feste Formel:
    • Was hast du gestern gemacht?.
    • Was planen Sie heute?.
    • Was Ihre Teammitglieder (nicht Sie!) Über die Aufgabe wissen sollten, wie sich dies auf sie auswirkt.
  • Kümmere dich nicht um Hindernisse, wenn du sie nicht ansprechen willst.

Dies ist ein zweiter Beweis dafür, dass Ihre Planung Ihre Situation beeinträchtigt. Wenn Sie nichts Spezielles zu berichten haben, bedeutet dies, dass die Aufgabe normalerweise zu groß ist und Sie nur sagen konnten: Ich habe daran gearbeitet.

  • Teilen Sie Aufgaben in die Aufzählungspunkte auf.
  • Stellen Sie sicher, dass die Aufgaben klein genug sind, um weniger als einen Tag zu dauern. Im Idealfall sollte die IMO-Aufgabe ~ 3 Stunden dauern und ungefähr 13 SP entsprechen, sodass Sie unter den meisten Bedingungen 2 pro Tag ausführen können.

Umgang mit dem Team

Heute sagte mir die Person, die immer gegen mich ist, ich solle aufhören zu sagen: "Sie sagten, das ist es, was sie für diesen Sprint verpflichtet haben", weil er in seinen Worten sagte: "Wir absolvieren nie einen Sprint. Wir bewegen uns nur in Aufgaben und nehmen neue in der auf." nächster Sprint, um eine Quote zu füllen. Wir machen KanBan in Wirklichkeit. Also hör auf, das zu sagen. "

Er hat recht. Sie liegen falsch. Sie machen bastardisiertes SCRUM und/oder Variation von Kanban. Überhaupt nicht ihre Schuld.

Ich verstehe, warum er das sagt, aber er scheint nicht zu erkennen, dass es so ist, weil es ihm und allen anderen im Team egal ist.

Ich glaube du verstehst das überhaupt nicht. Sie kümmern sich vielleicht weniger als früher, aber wenn sie beschuldigt werden, verbessert dies nicht nur nichts, sondern verschlimmert möglicherweise auch die Situation. Wenn es der Tiefpunkt wäre, könnten sie tatsächlich anfangen zu graben.

Sie arbeiten einfach, anstatt mit Hindernissen umzugehen.

Und hier dachte ich, Arbeit zu machen ist das, worum es bei ihrer Arbeit geht. Ich frage mich, wer eigentlich mit Hindernissen umgehen sollte ... oh, richtig. Ein Scrum Master. Es ist dein Job. Sie sagen dir, was los ist. Sie beheben es. Nicht umgekehrt.

Dies ist wahrscheinlich der Grund, warum Sie in der Retrospektive so viele Probleme haben.

Wie kann ich sie erkennen lassen, dass das Herumscherzen und Kreisen während dieser Besprechungen das Unternehmen viel Geld kostet?

Stoppen Sie die nutzlosen Besprechungen und sie scherzen stattdessen über den Wasserkühler. Siehe auch den Abschnitt über Schläge, die die Moral verbessern. Wenn sie Humor als Abwehrmechanismus verwenden, haben Sie einige ernsthafte Probleme, Sir!

Machen Sie einen Witz - wie bei der Arbeit mit Ihrem Team, nicht dagegen. (Wen kümmert das Fuuuuuuck um das Geld des Unternehmens? Sind Sie jetzt Aktionär?)

Zusammenfassend

Ihre schlechte Planung führt dazu, dass andere Teile von SCRUM scheitern und jeder, der daran teilnimmt, unglücklich ist. Sie sehen, dass sich nichts ändert, nichts angesprochen wird und ihre Beschwerden nicht gehört werden.

Verbessern Sie Ihre Planung und verbessern Sie den Fluss und die Moral.

Wenn Sie Ihre Hindernisse beseitigen, wird Ihr Team schneller vorankommen. Fragen Sie sie, was sie Sie tun sollten, um ihnen zu helfen.

Am wichtigsten: Höre auf deine Leute. Sie haben dir (und mir) bereits gesagt, was das Problem ist.

Viel Glück!

47

Eines der wichtigsten agilen Prinzipien ist es, zurück zu gehen und alles zu korrigieren, was falsch ist. Dazu gehören nicht nur Code-Refactoring und Fehlerbehebungen, sondern auch die Behebung des Entwicklungsprozesses.

Warum treffen Sie sich nicht mit Ihrem Team und sehen, wie Sie den Entwicklungsprozess verbessern können? Wenn das bedeutet, keine Scrum- oder Standup-Meetings, dann sei es so.

Außerdem brechen Sie eines der Prinzipien in agiles Manifest : "Individuen und Interaktionen über Prozesse und Werkzeuge".

Wenn Ihr Team jedoch der Meinung ist, dass die iterative Entwicklung schlecht ist, machen Sie es möglicherweise falsch. Es spielt keine Rolle, ob Sie nicht alles fertigstellen, was Sie für eine Iteration geplant haben - Sie können die Dinge jederzeit zur nächsten Iteration verschieben. Das ist auch der Grund, warum Sie Dinge als "muss enthalten", "schön zu haben" usw. markieren. Solange Sie neue Funktionen bereitstellen, machen Sie es gut.


Nur ein kleiner Scherz: In meiner vorherigen und aktuellen Firma haben wir Stand-up-Meetings durchgeführt und führen sie immer noch durch. Nach meiner Erfahrung sind sie eine massive Zeitverschwendung, da sie sich jedes Mal in mehr als 30-minütige Statusberichtssitzungen verwandeln und mir wenig bis gar keine Informationen liefern. Die Leute reden über ihre Probleme, was mir ehrlich gesagt egal ist.
In meiner vorherigen Firma waren sie schlau, erkannten dieses Problem mit Stand-ups und stoppten sie, kurz nachdem die Leute anfingen, sich zu beschweren.


Wenn Sie ein wirklich gutes Video über Scrum sehen möchten, lesen Sie " Robert C. Martin - Das Land, das Scrum vergessen hat ".

10
BЈовић

Als Priorität würde ich mir Aufgaben ansehen, die immer wieder übernommen werden. Das Nichterreichen von Zielen ist äußerst demoralisierend. Verpflichten Sie sich zu viel? Gibt es Fatlogs, die abgebaut werden sollten? Gibt es Engpässe außerhalb Ihrer Kontrolle? Haben Sie eine klare Definition von "erledigt"? Sind die Anforderungen klar? Sind die Stunden pro Entwickler angemessen (d. H. Berücksichtigt Administrator, Standups, Planung, Rückblicke, Tastaturpausen, Nicht-Projektarbeit)?.

Als nächstes lassen Sie alles fallen, was nicht funktioniert. Prozess ohne Wert ist nur ein Zeitdieb. Stand-ups können sehr viel Zeit in Anspruch nehmen, wenn sie nicht fokussiert sind und dem Team keinen Wert bieten. Die Stunden könnten besser woanders verbracht werden. Vielleicht sollten Sie auch in Betracht ziehen, das Team aufzuteilen, wenn es zu groß ist.

Versuchen Sie herauszufinden, was das Team demotiviert. Haben Sie Rückblicke und, was noch wichtiger ist, handeln Sie auf die Ausgabe. Es ist ebenso wichtig, Erfolge zu feiern und Misserfolge zu betrachten.

Schließlich möchten Sie vielleicht die Ansätze von Scrum-Meistern bewerten, die zuvor gegangen sind und die Marke sozusagen beschädigt haben. Ich habe zuvor unter einem Toxic Scrum Master gearbeitet, bei dem jedes Problem, das angesprochen wurde, zu Ihrer Arbeitsbelastung hinzugefügt wurde, unabhängig davon, ob Sie davon wussten oder nicht. Endergebnis: Probleme wurden ignoriert und jeder arbeitete mit sehr wenig Teamwork an seinem eigenen kleinen Bereich.

9
Robbie Dee

Mein Team ist meiner Meinung nach das Wichtigste, was Sie tun können, wenn Sie Ihr Team dazu bringen, Ihren Sprint effektiv zu beenden (wie mindestens 80% der Geschichten). Wenn Ihr Team ständig fehlt, ist dies ein klarer Hinweis darauf, dass Sie Ihre Schätzungen anpassen müssen.

Das Team sollte dafür empfänglich sein, obwohl es sehr schwierig sein kann, Entwickler dazu zu bringen, realistischer mit Schätzungen umzugehen. Ich habe an einem Team gearbeitet, das einen Sprint ein Jahr lang nicht abgeschlossen hat (durchweg weniger als 50% des Sprints). , immer unterschätzt und in jeder Planung/Retrospektive war ich eine einsame Stimme, die ihnen sagte, dass Ihre Schätzungen scheiße sind. Sie sind törichterweise zu zuversichtlich. Machen Sie keine Ausreden mehr für das, was Sie daran gehindert hat, die Schätzung vorzunehmen, und passen Sie die Schätzung stattdessen an die Realität an. vielleicht diplomatischer als das, aber das war das Grundgefühl) - Wenn Sie in dieser Position sind, würde ich dem Curmudgeon in Ihrem Team voll und ganz zustimmen, der sagt, dass der Prozess Zeitverschwendung ist, weil Sie tatsächlich KonBon machen, unabhängig davon wie du es nennst. Ab einem bestimmten Punkt wird seine Meinung durch die Umstände bestätigt. Es ist schwer, diese Trägheit zu überwinden, aber wenn Sie das nicht können, denke ich nicht, dass das Team jemals sehr erfolgreich sein wird.

Irgendwann muss man die Dinge zurücksetzen, man muss das Team dazu bringen, ihre Schätzungen drastisch zu überkompensieren, nur um das System in Bewegung zu setzen. Sobald ein Team anfängt, Geschichten konsequent zu schließen, sollte es erkennen, dass der agile Prozess hauptsächlich dem gesunden Menschenverstand entspricht und dass es Ihrer Produktivität schadet, ihn nicht auf irgendeine Weise zu verwirklichen. Aber solange das "Engagement" und die "Sprintziele" nicht ernst genommen werden, was passiert, wenn sie nicht konsequent erreicht werden, ist das Ganze eine Täuschung und belastet die Produktivität des Teams.

Es ist schwierig, Leute dazu zu bringen, sich auf einen deutlich anderen Sprint einzulassen (in Bezug auf Schätzungen, Planung, Engagement usw.). In diesem Team habe ich dies schließlich aufgrund zweier Faktoren erreicht. Einer sammelte nur die Daten von JIRA und sagte: "Es gibt keine Entschuldigung dafür, die Zahlen sind weit weg, sie sind immer in eine Richtung, wir müssen sie korrigieren, ich will keine Ausreden im Retro, ich will Die zu addierenden Zahlen "- und der andere war der Druck von höheren Führungskräften, den ich ihnen schließlich erklärte wie ..." Der Sinn dieses Prozesses besteht darin, unseren Entwicklungszeitplan vorhersehbar zu machen. Wenn wir alle eine konstante Menge an Arbeit erledigen Unabhängig davon ist unser Sprint in Ordnung. Unser Board muss genau widerspiegeln, was wir tun. Das Management ist sich unseres Erfolgs in Bezug auf das Engagement mehr bewusst als in Bezug auf unsere tatsächliche Leistung Die Ausgabe sieht so aus, als würden Sie Ihre Arbeit erledigen, anstatt die Hälfte jedes Sprints damit zu verbringen, nichts zu tun. Je weiter die Leute von dieser Zeit entfernt sind, desto mehr sehen sie Sie nur scheitern, desto weniger Ausreden machen Sie im Retro-Modus Etwas in ihrem Zuständigkeitsbereich, sie sehen dich nur scheitern G."

Irgendwann bekam unser Team Traktion und die Dinge liefen viel reibungsloser und niedriger und siehe da, wir hatten sogar eine höhere Leistung, sobald der Prozess tatsächlich zu funktionieren begann. Tun Sie also alles Notwendige, um Sprints mit relativ hohem Erfolg zu beenden. Wenn Sie dies nicht tun, wird der Widerstand des Curmudgeons in Ihrem Team weiterhin durch die Ergebnisse bestätigt und letztendlich ist es richtig, dass Ihr Prozess tatsächlich nur eine Täuschung und Zeitverschwendung für jeden ist.

5
evanmcdonnal

Als Scrum Master coachen und leiten Sie das Team, um produktiver zu werden. Das Scrum-Framework ist ein leistungsstarkes Tool, um dorthin zu gelangen, aber das Scrum-Framework darf niemals das Ziel für sich sein - sonst tun Sie Cargo Cult .

Es scheint, dass Sie seit 3 ​​Jahren Cargo Cult betreiben und die Leute haben erkannt, dass dies eine schreckliche Projektmanagementmethode ist. Die gute Nachricht ist du hast kluge Leute, sie haben es richtig gemacht. Leider nennen es einige Leute in Ihrem Unternehmen Scrum, aber wieder Sie haben kluge Leute, sie haben Ihnen sogar gesagt, was das Team tut, heißt nicht Scrum.

Planung ist nur Zeitverschwendung, da wir nur den Überlauf in den neuen Sprint verschieben und die Arbeit sowieso nicht abschließen. Warum also die Mühe machen?.

Genau. Warum die Mühe? Sie müssen eine Antwort finden oder vielmehr die Planung und den Sprint selbst ändern, damit die Planung einen Sinn hat. Entweder das, oder verschwenden Sie keine Zeit mehr mit einer sinnlosen Sprint-Planung. Möglicherweise möchten Sie das Unternehmen bitten, Sie zu einem Scrum Master-Training zu schicken, da die Durchführung einer hervorragenden Sprint-Planung nicht trivial ist.

Während der Retrospektive [...] schweigen die anderen und ich muss mich jedes Mal damit befassen.

Wenn Sie sich in jeder Retrospektive mit demselben Thema befassen, machen sich die Leute nicht einmal (mehr?) Die Mühe, während der Retrospektive zu sprechen, das ist nur Zeitverschwendung. Sofern Sie oder das Team die in der Retrospektive angesprochenen Probleme nicht irgendwie angehen können, ist das Treffen nur eine Demoralisierung des Teams. In der Retrospektive aufgeworfene Fragen müssen angegangen werden, und bis zur nächsten Retrospektive sollten Fortschritte erzielt werden.

Daily Scrum ist wieder nur Zeitverschwendung für sie, weil keiner von ihnen sich die Mühe macht, zu reden und den Tag zu planen. Sie sagen nur: "Ich habe gestern an Aufgabe X gearbeitet und werde heute wieder daran arbeiten."

Warum sollte man sich die Mühe machen, die Zeit aller zu verschwenden, wenn sie nur mehrere Tage an denselben Aufgaben arbeiten? Sie sind absolut richtig, dass Daily Standup in der Tat sinnlos ist. Der Standup ermöglicht eine enge Zusammenarbeit bei vielen Aufgaben, die jeweils innerhalb eines halben Tages oder weniger erledigt werden können. Wenn Ihre Aufgaben auf diese Weise nicht aufgeschlüsselt werden können (aufgrund einer fehlerhaften Sprint-Planung oder weil Ihre Aufgaben tatsächlich nicht gut zu Scrum passen), ist es nicht sinnvoll, das 5-minütige tägliche Standup-Meeting abzuhalten (das ist es) nicht länger als 5 Minuten, oder?).

"Wir absolvieren nie einen Sprint. Wir bewegen uns nur in Aufgaben und nehmen im nächsten Sprint neue auf, um eine Quote zu erfüllen. Wir machen KanBan in der Realität. Also hör auf, das zu sagen."

Ich verstehe, warum er das sagt, aber er scheint nicht zu erkennen, dass es so ist, weil es ihm und allen anderen im Team egal ist.

Nein, du verstehst absolut nicht, warum er das sagt. Sie haben die Grundursache für das Hindernis - das Sie beheben müssen - falsch verstanden. Es ist ihnen egal, weil die Projektmanagementpraktiken des Teams scheiße sind. Sich um Cargo Cult zu kümmern und Cargo Cult härter zu machen, hindert es nicht daran, Cargo Cult zu sein, eine der schlechtesten Projektmanagementmethoden, die es gibt (zu Ihrer Verteidigung: auch die am weitesten verbreitete).


Was können Sie dagegen tun?

  1. Hören Sie auf ihre Bedenken. Auch hier bist du gesegnet du hast kluge Leute.

  2. Helfen Sie ihnen, die Hindernisse zu beseitigen.

Und das war's wirklich. Sie müssen experimentieren, wie Sie Sprint Planning, Daily Scrum und Retrospectives ändern können, um sie für das Team wertvoll zu machen. Selbst wenn Sie das Scrum-Label löschen möchten, haben Sie diese drei Meetings mit ähnlicher Häufigkeit und ähnlichem Zweck in jedem anderen Projektmanagement-Methodik da draußen. Die Art und Weise, wie Sie experimentieren möchten (Häufigkeit, Inhalt, Gastgeber des Meetings, Zeit, Dauer usw.), ist überraschend einfach: Fragen Sie das Team. Erzwingen Sie Ihre Ideen nicht ihnen, wenn überhaupt, sollten Sie sie ihre Ideen aufzwingen lassen (vorausgesetzt, sie können sich auf einige einigen).

Wenn Sie befürchten, die Kontrolle zu verlieren, legen Sie vorher einige Grenzen fest, z.

  • Die Beschriftungen der Besprechungen bleiben unverändert.
  • Die Sitzungen finden weiterhin statt und die Häufigkeit der Sitzungen kann sich nicht um mehr als den Faktor 2 ändern.
  • Sie experimentieren gerade, sodass jede Änderung nur für 2 Sprints gültig ist. Danach kehren Sie zum alten Muster zurück (geben Sie am besten die Zeit in Wochen an, um Unklarheiten zu vermeiden, wenn die Sprintdauer verdoppelt werden soll).
4
Peter

Ich denke, jeder zitiert die gleiche Zeile aus dem Agile Manifesto . Ich werde das Gleiche tun: "Individuen und Interaktionen über Prozesse und Werkzeuge."

Wenn Sie als SCRUM-Master SCRUM für die Arbeit verwenden möchten, müssen Sie sich ihnen als eine Person nähern, die mit einer anderen interagiert. Beginnen Sie mit dem Brainstorming, wie Sie den Prozess verbessern können. Vielleicht können Sie sie davon überzeugen, SCRUM zu mögen. Vielleicht können sie Sie überzeugen, ein anderes Verfahren anzuwenden. Lass es uns herausfinden!

Es hört sich so an, als ob das Team bereits erkennt, dass das aktuelle System die Aufgabe nicht erfüllt. Können Sie sie ermutigen zu glauben, dass es den Job machen kann? Sie erwähnen einige Beispiele. Wenn Sie den Sprint überfüllen, damit er immer ausläuft ... hören Sie auf. Es ist dein SCRUM-Team. Helfen Sie ihnen, nicht mehr zu viel zu tun. Drücken Sie das Management zurück, um etwas Luft zum Atmen zu bekommen. Verwenden Sie SCRUM für das, wofür es gut ist. Verwenden Sie diese Option, um dem Management die Daten zu präsentieren, die sie so stark vorantreiben, dass sie den Wert ihres Prozesses verlieren. Wenn das Management SCRUM als Prozess wünscht, lassen Sie es den Raum und die Energie aufbauen, die Sie zur Behebung benötigen. Als SCRUM-Meister besteht Ihre Aufgabe darin, Probleme zu lösen, damit das Team produktiv sein kann.

Ein weiterer nützlicher Ansatz kann darin bestehen, einen neuen Prozess innerhalb des alten zu erzeugen. Führen Sie das SCRUM weiterhin auf dieselbe nutzlose Weise aus, sperren Sie jedoch einen kleinen Teil des Zeitplans ab und sagen Sie: "In diesem Teil unseres Zeitplans werden wir herausfinden, wie die Tools richtig verwendet werden." Überbeanspruchen Sie dort nicht. Verwenden Sie Ihre Metriken. Konzentrieren Sie sich dort auf alle Ihre Meetings. Nur der verbleibende Teil Ihres "SCRUM" -Projekts als Schutzschild, um das Management bei Laune zu halten, während Sie und Ihr Team "bessere Möglichkeiten zur Entwicklung von Software aufdecken, indem Sie dies tun und anderen dabei helfen". Mit der Zeit werden Sie immer mehr Ihrer geschätzten Aufgaben in diesen Eimer stecken wollen, und der alte Eimer wird langsam sterben. Bald haben Sie eine lebendige Softwareentwicklungsumgebung und niemand ist klüger.

Oder mischen und kombinieren. Ich habe an einem Anti-Scrum-Programm gearbeitet. Die Kunden wollten zu jedem Zeitpunkt des Prozesses neue Aufgaben hinzufügen können und wir sollten sofort darauf reagieren. (Dies war eigentlich eine vernünftige Bitte: Ihre Arbeit war sehr volatil und sie brauchten oft schnelle Unterstützung ... dafür wurden wir bezahlt). Natürlich mussten wir herausfinden, wie wir mit den Problemen "Warum wird X nicht gemacht, wenn Sie es im Sprint versprochen haben" umgehen sollen. Unsere Lösung bestand darin, einen zweistufigen Prozess aufzubauen. Langzeitaufgaben wurden zur richtigen Priorisierung in SCRUM gestellt. Die kurzfristigen Aufgaben wurden in einen selbstgebrauten Prozess gestellt, der sich auf die enge Interaktion zwischen Kunde und Entwickler konzentrierte. Es wurde davon ausgegangen, dass die Kunden willkommen waren, uns mit diesem kurzfristigen Prozess zu pushen, aber dass sie verstanden, dass dies die Zeitachse des Sprints verlängerte, und dass es ihnen verboten war, Anfragen hinzuzufügen, ohne gleichzeitig die von ihnen verursachten Planungsprobleme zu hören und zu beheben. Ergebnis? Es funktionierte. Die meisten Aufgaben wurden so in den SCRUM-Prozess gestellt, wie sie sein sollten, und die Notfälle interagierten nahtlos mit ihnen. Die Einstellung lautete: "Wenn Sie Kunde werden möchten, stellen Sie sich für eine SCRUM-Geschichte an. Wenn Sie Partner werden möchten, können Sie sich gerne täglich an uns wenden und dieses Produkt zum Laufen bringen." ! "

3
Cort Ammon

Ich sage das, weil ich es wirklich weiß. Sie haben ein Problem im oberen Management mit Überplanung, können keine Prioritäten setzen und sind bereit, weitere Elemente hinzuzufügen, aber die Veröffentlichungsdaten nicht zurückzuschieben.

Früher habe ich gesagt, dass es keine Methode gibt, die so funktionieren kann, aber jetzt, wo ich Kanban gesehen habe, sage ich, dass dies möglich ist, aber nur, weil Kanban sich nicht darum kümmern muss. Es funktioniert weiterhin, wenn es überlastet ist. Es wird keine schnelleren Ergebnisse bringen, aber die Sicherung in den Warteschlangen darf nicht bei einer Person erstellt werden, sodass das Verwaltungsproblem beim Management liegt. Die Feedback-Berichte zeigen eine Überlastung, die korrekt ist.

3
Joshua

Aufgrund dieser Änderung in Scrum Masters und ihrer Art, die Show zu leiten

Na ja, das könnte dein Problem sein. Ein Scrum-Master ist nicht da, um eine Show zu leiten, er ist kein Projektleiter. Er ist da, um sicherzustellen, dass alle Beteiligten kommunizieren und der Betrieb transparent ist.

Ich frage mich, woher das Team kommt. Könnte es sein, dass sie mehr oder weniger autonom waren, bevor Scrum (einschließlich des unvermeidlichen Scrum-Masters) auf sie fallen gelassen wurde? Warum wurde Scrum überhaupt eingeführt? Was sollte es lösen?

Scrum soll als Anleitung dienen und Ihr Team macht deutlich, dass es in keiner Weise hilfreich ist. Sie kümmern sich nicht um Anleitung, sie betrachten es als unangemessene Zeitverschwendung. Anscheinend glaubt mindestens ein Entscheidungsträger, dass er trotzdem geführt werden muss. WHO? Warum? Haben sie einen Punkt?

2
Martin Maat

Dies ist ein Problem, das nicht nur auf Software beschränkt ist.

In jedem Arbeitsumfeld gibt es unterschiedliche Menschen mit unterschiedlichen Persönlichkeiten und Fähigkeiten. Selbst wenn Scrum eine perfekte Methode wäre, würde es aufgrund ihrer Persönlichkeit und Fähigkeiten immer noch Menschen geben, die dagegen sind.

Entwickler behandeln schwierige Aufgaben rational. Um dies tun zu können, muss jeder Entwickler mit solchen Dingen umgehen, die sich als Abneigung gegen Dinge wie Scrum herausstellen können. Wenn alle Entwickler auf genau die gleiche Weise von Grund auf geschult wurden, ist es möglicherweise viel einfacher, ein Muster zu verwenden. Andernfalls ist jedoch eine Anpassung auf der Entwicklerseite oder auf der Managementseite erforderlich.

Darüber hinaus möchten unabhängige Denker (Entwickler und andere Spezialisten) oft nicht wissen, wie man Dinge macht, weil dies ihre Aufgabe ist und es leicht zu Meinungsverschiedenheiten kommt. Scrum kann für einen logischen Denker wie ein sinnloses Ritual erscheinen, das normalerweise jedes Problem analysiert und entsprechend handelt.

Das Folgende scheint darauf hinzudeuten, wo das Problem liegt, aber nicht, was es ist. Es gibt definitiv mehr als das. Ich kann nur (aus Erfahrung) davon ausgehen, dass die Entwickler es versucht haben, aber verhindert wurden. Ich habe es oft gesehen, wo Entwickler etwas reparieren wollen, aber etwas Systematisches (Management, Unternehmensrichtlinien usw.) macht es nahezu unmöglich, so dass sie aufgeben. Interessieren sie sich wirklich nicht oder kümmern sie sich nicht nur darum, etwas zu tun, von dem sie glauben, dass es nicht hilft (möglicherweise aus Erfahrung).

Ich verstehe, warum er das sagt, aber er scheint nicht zu erkennen, dass es so ist, weil es ihm und allen anderen im Team egal ist. Sie arbeiten einfach, anstatt mit Hindernissen umzugehen. Sie beschweren sich über die Hindernisse, tun aber nichts dagegen. Und wenn ich versuche zu helfen, schütteln sie es einfach ab.

Früher war es ihnen egal, aber in den letzten zwei Jahren ist ihre Bereitschaft mehr oder weniger auf den Tiefpunkt gesunken.

Wie kann ich sie erkennen lassen, dass das Scherzen und Kreisen während dieser Besprechungen das Unternehmen viel Geld kostet?

Wenn anderen Menschen etwas aufgezwungen wird, liegt es an den Menschen, die die Methode erzwingen, sie von den Vorteilen zu überzeugen. Obwohl ich nicht wirklich daran glaube, Menschen zu zwingen, Dinge zu tun, schlage ich vor, wie in jeder Situation allen zuzuhören und eine Methode zu entwickeln, die für die aktuelle Umgebung funktioniert.

1
Damien Golding

Sie haben viele hervorragende Antworten erhalten. Hier sind einige weitere Punkte, die hilfreich sein könnten:

Das Ändern der Methodik ist schwierig

Es ist eine große Herausforderung in einem Arbeitsbereich, weil Sie unter der Trägheit "So machen wir Dinge" und gegen den Druck von Fristen und Geschäftsanforderungen arbeiten.

Sie sind zu Recht der Meinung, dass Ihr Team mehr Zeit für die Planung aufwenden muss, nicht weniger ; Diese Planung ist etwas, in dem Ihre Zeit derzeit nicht besonders gut ist und das verbessert werden muss. Das Problem ist, dass Sie nicht einfach durch das Diktieren neuer Regeln dorthin gelangen. Neue Regeln sind eine neue Belastung, bevor sie zu einer großen Hilfe werden. Und wenn sie keinen großen Wert bieten sofort, werden Sie eher vermieden als kooperiert.

Ich kann Roy Osherove zu diesem Thema nur empfehlen. Er hat eine kurze Zusammenfassung von wie man Veränderungen in Ihrem Unternehmen plant und bewirkt , und er geht in dieses Video ausführlicher auf das Thema ein.

Osheroves grundlegende Beobachtung ist, dass alle folgenden Herausforderungen bewältigt werden müssen:

Persönliche Motivation: Warum sollte sich jemand dafür interessieren, sich auf eine bestimmte Weise zu verhalten?
Persönliche Fähigkeit: Können sie es buchstäblich tun?
Soziale Motivation: Gibt es Gruppenzwang? Drücken Sie auf dieses Verhalten?
Soziale Fähigkeit: Unterstützen Menschen um mich herum mein Verhalten und helfen mir dabei, wenn ich Hilfe brauche?
Strukturelle Motivation: Gibt es Belohnungen\Strafen für gutes\schlechtes Verhalten?
Strukturelle Fähigkeit: Unterstützt die physische Umgebung dieses Verhalten?

Sie müssen lernen, Aufgaben aufzuschlüsseln

Ihr Team ist der Meinung, dass "ich gestern an Aufgabe X gearbeitet habe und heute wieder daran arbeiten werde", und sie scheinen in dem Sinne richtig zu sein, dass Aufgaben eine Woche lang immer wieder zurückgeschoben werden.

Was hier wirklich hilfreich ist, ist zu lernen, wie man Aufgaben in kleine Komponenten aufteilt. Was Sie suchen, ist die Antwort auf die Frage "OK, Sie arbeiten an Aufgabe X, aber woran arbeiten Sie speziell in Aufgabe X heute?"

Einige Antworten könnten sein:

  • Ich lerne diese Klasse von Legacy-Code.
  • Ich behebe einen Fehler, dessen Symptome (SYMPTOME) sind.
    • Wenn dies ein fortlaufender Fehler ist, der eine Weile dauert: "Heute werde ich versuchen, ... (PLAN)"
  • Ich muss diese Schnittstelle ändern.
  • Ich schreibe Tests.
  • Ich integriere ungetesteten Code.

... und so weiter und so fort. Zu beobachten, was Sie an einem Tag oder in einer Woche tatsächlich erledigen können, ist einer der großen Vorteile von Agile. Aber das bedeutet, dass Sie es tatsächlich brauchen um die Auflösung einzelner Tage zu betrachten, nicht irgendeine monolithische Aufgabe X, die bereit ist, wann immer sie bereit ist.

Fertig vs. Geliefert

Ein häufiges Problem (bei Agile und bei der Arbeitsplatzplanung im Allgemeinen) besteht darin, dass die Fristen in der Regel vom Management und nicht von den Entwicklern stammen. Diese Frist könnte von der tatsächlich zu erledigenden Arbeit getrennt sein - und insbesondere ist es wahrscheinlich, dass die Dinge so schnell wie möglich geliefert werden .

Das Problem ist, "so schnell wie möglich geliefert" ist ein sehr chaotischer Prozess. Es fördert das Schneiden von Ecken; Codierung "schnell und schmutzig"; Richtlinien ignorieren; nicht nach dir aufräumen. Es fördert die Mentalität: "Probieren Sie es aus, sehen Sie, ob es funktioniert. Wenn ja, liefern Sie. Wenn nein, versuchen Sie etwas anderes" - und so ausgedrückt können Sie sehen, warum niemand vorhersagen kann, wie lange etwas dauern wird.

Wenn Sie sind methodisch arbeiten, wenn Sie streng planen und testen usw., dann haben Sie eine Reihe von Wegweisern und Sicherheitsnetzen eingerichtet. Es kann länger dauern - Sie widmen viel Zeit Dingen, die die sofortige Lieferung nicht fördern, und Sie sind möglicherweise noch nicht sehr gut in dieser Art von Workflow - aber es wird viel weniger volatil sein.

Eine Sache, die Sie sich fragen sollten, ist: Setzen die Entwickler die Sprintziele entsprechend den Bedürfnissen und Notwendigkeiten, die sie tatsächlich sehen? Oder ist es Management Festlegen der Fristen, sodass Entwickler versuchen können, ihre Verpflichtungen in einen sprintartigen Zeitplan zu integrieren?

Wenn Entwicklern nicht die Zeit bleibt, Dinge zu planen oder nach einem zuverlässigen Plan zu arbeiten, ist es kein Wunder, dass sie keine hilfreichen Schätzungen vornehmen können. :) :)

0
Standback

Scrum ist nicht ohne Schwächen. Ich kann natürlich für mich selbst sprechen, aber ich denke, Entwickler hassen es aus guter Grund. Ich bin der ehrlichen Meinung, dass es nicht versucht werden darf .

Um zu verstehen warum, lesen Sie was jeder Scrum Master über Scrum wissen sollte . Es ist nicht von mir geschrieben, aber alles dort ist repräsentativ für meine Erfahrung, die ich nur als bloßer Terror zusammenfassen kann.

In meinem Fall litt ich besonders unter Punkt 5. Grundsätzlich behandelte mich Scrum als Kind und als Verlierer. Jetzt bin ich ein findiger Mitentwickler, der meinen Kollegen hilft… kein Wunder, was ich bevorzugen würde!

Ich habe jetzt einen neuen (Nicht-Scrum-) Chef, der einfach herumläuft und mit Leuten spricht, und ich bin so so dankbar dafür! Dies funktioniert unter anderem dadurch, dass wir auch einen Chatraum (den wir am häufigsten nutzen) für die Kommunikation zwischen Entwicklern haben. Wenn jemand eine Agenda hat, nehmen wir sie dorthin. Meetings dienen nur Ad-hoc-Entwicklerdiskussionen, nicht dazu, sich selbst künstliche tägliche Fristen aufzuerlegen.

0
user2394284