Wie verhindere ich als Scrum Master, dass ein Teammitglied zu schnell aufgibt?

Als Scrum Master ist es nicht Ihre Aufgabe, den Entwickler zu managen. Es ist auch nicht Ihre Aufgabe, den Product Owner (PO) einzubeziehen. Es ist die Aufgabe Ihres PO, ein Auge darauf zu haben, was sein Team tut, und es ist Ihre Aufgabe, sicherzustellen, dass sie sich an den Scrum-Prozess halten.

Ihr Entwickler hat völlig recht, wenn er die Details der Bearbeitung des Tickets nicht mit Ihnen bespricht. Sie sind nicht die Person, die ihm Arbeit zuweist oder beurteilt, ob oder wie gut die Arbeit erledigt ist. Der Scrum Master ist nicht der Assistent-PO.

Wenn Ihr Entwickler jedoch nur eine andere Geschichte schreibt, muss er dies dem Team mitteilen. Es ist die Aufgabe des Teams, zu sehen, wer was macht, und es ist die Aufgabe des Teams, dafür zu sorgen, dass alle Geschichten fertig werden.

Das Team könnte entscheiden, dass diese Geschichte größer als erwartet ist, und den PO konsultieren. Das Team kann entscheiden, dass es ein externes Hindernis gibt (z. B. keine Testumgebung) und dies an den Scrum Master delegieren, um es zu lösen. Das Team kann entscheiden, dass jemand anderes aus dem Team dem Entwickler helfen wird, da einige Dinge mit einem einzigen Augenpaar schwer zu erkennen sind. Vielleicht erreichen sie ihr Sprintziel nicht. Es ist dann an der Zeit, dies in der Retrospektive zu diskutieren.

Nochmals: In Scrum ist es weder die Aufgabe des Scrum Masters noch des POs, einem Teammitglied zu sagen, dass es eine bestimmte Geschichte machen soll oder wie eine bestimmte Geschichte zu machen ist. Selbstorganisierendes Team bedeutet, dass das Team organisiert, wie Geschichten gemacht werden. Wenn das nicht funktioniert, überlassen Sie es dem Team, eine Lösung zu finden.

Ein allgemeiner Teil: Denken Sie nicht, dass Scrum nur ein heikles, warmes, flauschiges Zeug ist, nur weil es keinen alten Projektmanager gibt. Unterschätzen Sie den Gruppenzwang nicht. Wenn er den Fehler nicht behebt, muss das Team die Aufgabe erledigen. Und sie werden darüber auch nicht glücklich sein. Aber man muss Scrum tatsächlich machen. Wie immer scheint es, als hättest du allem einen Scrum-Anstrich verpasst, mit SM und PO und Team, aber du verhältst dich nicht so. Sie sind immer noch „sein Chef“ und „verwalten ihn“. Das ist kein Scrum und so wird es auch nicht funktionieren. Scrum funktioniert nur, wenn man Scrum auch wirklich macht . Titel zu vergeben und es auf die alte Schule zu tun, wird nicht funktionieren.

Nicht jeder hält sich bei Scrum an die gleichen Prinzipien, insbesondere in kleinen Geschäften, in denen die Leute mehrere Hüte tragen. Es ist also nicht ganz ungewöhnlich, diese Situation selbst zu meistern.

Das Anhäufen von mehr Funktionen auf Fehlern wird Ihre technischen Schulden in die Höhe treiben. Die Fehler werden nicht leichter zu finden oder zu beheben sein, wenn weitere Funktionen hinzugefügt werden.

Wenn diese Fehler früh im Entwicklungszyklus erkannt werden, kategorisieren Sie sie nicht als Fehler, sondern lehnen Sie die abgeschlossenen Elemente als unvollständig ab.

Es ist wahrscheinlich, dass Sie Ihre Tests und sicherlich Ihre Testabdeckung erhöhen müssen. Eine Investition von ein oder zwei Sprints in Einheiten- und Systemtests erhöht die Codequalität. Sie erhalten auch einfachere Möglichkeiten, die Probleme zu replizieren, und mehr Vertrauen in Codebereiche, die möglicherweise den Fehler verursachen könnten, es aber nicht sind. All dies wird dazu beitragen, den Umfang und die Zeit einzuschränken, die zum Beheben von Fehlern erforderlich sind. Sie können auch eine Codeüberprüfung hinzufügen, falls Sie dies noch nicht getan haben.

Es ist auch möglich, dass das obere Management eine andere Botschaft aussendet. Features verkaufen Produkte und Upgrades; Fehler machen wütend – statistisch gesehen geben Kunden in Umfragen nicht an, dass sie fehlerfreien Code schätzen, und bewerten die Codequalität normalerweise vor dem Kauf nicht gründlich. Wenn ja, ist das der Hauptgrund. Wenn nicht, hilft ein einziges, eindeutiges Edikt von oben. Wenn Sie das obere Management bitten, grundsätzlich zu verlangen, dass alle Fehler behoben werden, bevor neue Funktionen hinzugefügt werden, werden Sie von der Liste der Bösewichte, die ich ignorieren kann, gestrichen. Das obere Management darum zu bitten, würde das Thema für ihn neu fassen.

Er isst nicht gerne Gemüse. Er muss sein Gemüse essen. :-)

"Kurze Antwort?" Zart!

Obwohl Sie nicht der Vorgesetzte dieser Person sind, sind Sie im HR-Sinn des Wortes der Leiter Ihres jeweiligen Teams. (Ob Terminologie wie „Scrum“ verwendet wird oder nicht. Egal, welche „Management-Philosophie“ verwendet wird …) Sie handeln mit delegierter Autorität.

Nachdem Sie Ihre Strategie privat mit dem Manager besprochen und seinen Anweisungen oder Vorschlägen aufmerksam zugehört haben, sprechen Sie daher privat (aber direkt) mit dem Entwickler. Erinnern Sie ihn oder sie daran, dass Sie erwarten, dass er/sie an einer Aufgabe festhält, bis sie erledigt ist, aber auch, dass von ihm/ihr erwartet wird, dass er/sie um Hilfe, Unterstützung und Anleitung bittet. Dass solche Anfragen an Sie gerichtet werden sollten und dass Sie sie annehmen werden. Dass Sie es als Teil Ihrer Aufgabe ansehen, alle Hindernisse zu beseitigen, die ihm/ihr im Weg stehen.

Versuchen Sie, ohne in irgendeiner Weise zu drohen , dieser Person zu verstehen zu helfen, dass „das Team das Team braucht“ und dass seine/ihre angemessene Teilnahme an diesen Angelegenheiten tatsächlich erforderlich ist. Als Teamleiter und im Rahmen des Teams, das Sie führen, haben Sie das Vorrecht und die (delegierte) Verantwortung, solche Dinge zu sagen.

Nachdem Sie sich zunächst die Zeit genommen haben, Ihren Plan mit dem Manager zu besprechen, werden Sie nun von diesem Manager unterstützt. "Ja, Jim oder Jane, ich bin mir bewusst, dass bobo2000 Ihnen das sagen wollte, weil er es zuerst mit mir besprochen hat. Er war und ist effektiv 'für mich sprechen', und ich bin Ihr Manager."

Außerdem:   Seien Sie bereit, "im Handumdrehen" anzuhalten und dieser Person zuzuhören . Warum könnte diese Person vor schwierigen Aufgaben zurückschrecken? Der Kommentar, dass "es keinen Spaß macht" (oder was auch immer) könnte eine Nebelwand sein. Können Sie die offene Sichtweise dieser Person auf die Situation herausarbeiten? Programmierer verschweigen manchmal ihre wahrgenommenen Schwächen, und sie könnten durchaus Schwächen wahrnehmen, wo und wann Sie es nicht tun. Versuchen Sie sehr, dies zu einem privaten (!) und wechselseitigen Gespräch zu machen .

Üben Sie Ihr bestes Taktgefühl, Diplomatie, Überzeugungskraft und ... Entschlossenheit. Ja, du hast Autorität. Ja, das tust du. Aber was Sie wirklich erreichen wollen, ist: (a) die wahre Situation aus der Sicht dieser Person besser zu verstehen und (b) diese Person davon zu überzeugen , sich zum Besseren ändern zu wollen .

Ein Bursche hat es einmal so ausgedrückt: „Biete ihm Butter und Honig auf einer Scheibe Brot an. Wenn er annimmt, nimm dein Schwert und benutze es, um das Brot zu buttern. Er wird den Honig nehmen und schätzen, und er wird auch nicht scheitern zu bemerken, dass du ein Schwert trägst."

Am Ende des Treffens und nachdem Sie der Person das letzte Wort überlassen haben, geben Sie sich die Hand, gehen Sie aus diesem privaten Raum und lassen Sie alles, was in diesem Raum gesagt wurde, "in diesem Raum".

Es gibt manchmal Fehler, die für eine bestimmte Person sehr schwer zu finden sind. Ich habe Fehler gesehen, die sich nur eingeschlichen haben, wenn Ihre Festplatte einen bestimmten Namen hatte. Oder nur abends. Oder nur an einem Tag im Jahr. Das passiert.

Es scheint, dass Sie Fehler haben, die schwer zu finden und zu beheben sind, aber nicht unmöglich. Er gibt auf, dein Chef weist ihn ab, dann arbeitet er weiter und macht es (wenn ich dich richtig verstehe). Der Teil, in dem sich Ihr Chef einmischen muss, damit er weiter an dem Problem arbeitet, ist offen gesagt inakzeptabel. Dass Sie den Chef einbeziehen, ist auch etwas, worüber Ihr Chef wahrscheinlich nicht glücklich sein wird.

Sie können eine Managemententscheidung treffen, dass ein Fehler nicht behoben wird, wenn es wichtigere Fehler gibt, die einfacher zu beheben sind. Aber wenn dieser Fehler behoben werden muss, wird er entweder an jemand anderen weitergegeben (und wenn diese Person ihn behebt, ist dies ein großer schwarzer Fleck gegen die erste Person, es sei denn, es liegen einige ungewöhnliche Umstände vor), oder Sie sagen ihm, dass er fortfahren soll, und er fährt fort. Wenn nicht, ist das nicht das Problem Ihres Chefs, sondern ein HR-Problem.

Nur zur Verdeutlichung: Wenn der Entwickler sagt "es kann nicht repariert werden" und der Manager denkt, dass es wichtig ist, es zu reparieren, und es an jemand anderen weitergibt, der es repariert, wird das wahrscheinlich erinnert (aufgeschrieben) und am angesprochen nächste Leistungsbeurteilung. Wenn der Entwickler sagt „es kann nicht behoben werden“ und Ihnen einen Grund dafür nennt, und der nächste Entwickler, den Sie fragen, aus denselben Gründen sagt „es kann nicht behoben werden“, ist das eine ganz andere Situation.

PS. Mir ist aufgefallen, dass Sie den Titel in „als Scrum Master“ geändert haben. Ein Scrum Master zu sein ist eine Rolle, die Sie spielen. Es geht darum, Scrums zu organisieren, sicherzustellen, dass Aufgaben gut spezifiziert sind und in einen Sprint übergehen, den Fortschritt zu verfolgen usw. Die Qualität der Entwickler ist nicht die Aufgabe des Scrum Masters. Aus reiner Sicht des Scrum Masters gilt: Wenn er eine Aufgabe nicht beendet, dann ist sie unvollendet, es sei denn, jemand anderes übernimmt sie.

Es gibt jedoch zwei verschiedene Rollen in einem Unternehmen, die dafür verantwortlich wären: Eine wäre ein Mentor oder leitender Entwickler, der die Aufgabe hat, anderen zu helfen, ihre Arbeit richtig zu machen, und eine wäre der Manager des Entwicklers, der sieht, wie viel oder wenig diese Person beiträgt An die Firma. Vielleicht sind Sie auch in einer dieser Rollen.

Ich möchte, dass sich jeder meiner Entwickler für die Qualität verantwortlich fühlt.

1. Hat dieser Entwickler Kontakt zu Benutzern des Produkts?
   • Es könnte ihm helfen, Ihre Benutzer als Menschen zu sehen und nicht nur als eine andere Gruppe, die ihn belästigt. Ich möchte, dass die Leute ein Qualitätsprodukt sehen und damit zufrieden sind.
2. Hat das Team interne Rechenschaftspflicht?
   • Können Sie mehrere Entwickler zuweisen, die zusammenarbeiten, um schwierige Probleme zu lösen? Es ist normalerweise schwieriger, einen Kollegen zu ignorieren, als ein Arbeitsticket