Ratschläge für einen nicht-technischen Neuling Scrum Master

Ich würde sehr darauf achten, direkt als Scrum Master einzusteigen, da Sie riskieren, von Teams sehr negativ wahrgenommen zu werden. Ich bin ein Scrum Master mit Entwicklungshintergrund, was es viel einfacher macht, sich natürlich in das Team einzufügen und nicht als „Management“ zu wirken.

Es gibt drei Phasen von Scrum-Teams, die manchmal mit Shu-Ha-Ri bezeichnet werden; ein Begriff aus der Kampfkunst. Aufgrund Ihres Hintergrunds passen Sie in einigen dieser Staaten viel einfacher in Teams als in anderen.

In der Phase „Shu“ (Gehorchen) lernen die Teams die Grundlagen. Dies erfordert eher eine Durchsetzungshaltung des Scrum Masters, und hier wäre technisches Wissen am nützlichsten. Hier erstellen Teams wahrscheinlich ihre „Best Practices für die Entwicklung“ – daher sollte der Scrum Master meiner Meinung nach Code-Reviews durchsetzen, bei der Implementierung von XP oder einem anderen Ansatz der Organisation helfen und (häufig technische) Ergänzungen zur Definition vorschlagen fertig. Hier scheinen mir viele 'Scrum-Berater' (die oft nicht technisch sind) die Branche zu versagen - sie bringen 2-wöchige Sprints, selbstorganisierte Teams und Rückstände ein, gehen aber nicht auf den wichtigsten Teil ein - die zugrunde liegende Entwicklung Standards, die Scrum entwickelt hat und auf die es sich stützt. Die meisten Teams verlassen diese Phase nie,

Die nächste Stufe, die Teams erreichen, ist „Ha“ (Digress), wo sie als gutes Scrum-Team arbeiten und anfangen zu verstehen, warum sie Dinge tun, anstatt nur dem Prozess zu folgen. Hier hat das Team die Grundlagen und arbeitet bereits als gutes Team. An diesem Punkt müssen sie über gute Entwicklungsmethoden verfügen, sodass ein Scrum Master, der weniger technisch versiert ist, wahrscheinlich auskommen könnte. Das Team ist motiviert, seine technische Exzellenz aufrechtzuerhalten, daher muss der Scrum Master dies nicht vorantreiben, möchte das Team jedoch möglicherweise daran erinnern, seine technische Exzellenz aufrechtzuerhalten. Es besteht immer noch das Risiko, dass Entwicklungspraktiken verrutschen und das Team es nicht bemerken könnte, und ohne technisch versiert zu sein, wird ein Scrum Master es vielleicht nie erfahren.

Wenn Sie die seltene Gelegenheit bekommen, mit einem Team bei „Ri“ (separat) zusammenzuarbeiten, das hyperproduktiv ist, müssen Sie meiner Meinung nach nicht technisch versiert sein. Dies ist wahrscheinlich die beste Art von Team, das zu Ihrer Situation passt. Ihr psychologischer Hintergrund würde Sie wahrscheinlich besser als die meisten Scrum Master machen, wenn es darum geht, tiefgründigen, versteckten Problemen auf den Grund zu gehen, die viele Scrum Master möglicherweise übersehen, also sollten Sie versuchen, sich auf die Arbeit mit großartigen Teams zu spezialisieren, die versuchen, zusätzliche herauszuarbeiten Verbesserung. Hier entwickeln Teams ihre eigenen Arbeitsweisen und geben Scrum vielleicht alle gemeinsam auf.

Ich habe einen Hintergrund in der Softwareentwicklung und habe mehrere Organisationen durch die Shu- und wohl Ha-Phasen geführt – oft nachdem agile Berater bereits viel Schaden angerichtet haben, indem sie Scrum eingeführt haben, ohne die Entwicklungspraktiken zu berücksichtigen, auf die es sich stützt. Wenn Sie an agilen Einführungen beteiligt sind, stellen Sie sicher, dass Sie mit einem Entwicklungsmanager oder leitenden Entwickler zusammenarbeiten, um Best Practices einzuführen, BEVOR Sie Agile einführen. Ohne dies können nicht-technische Scrum Master Teams und Organisationen ernsthaft kaputt machen. Sie können es tun, aber je mehr technisches Wissen Sie haben, desto besser.

Technische Fähigkeiten sind nicht zwingend erforderlich. Man könnte tatsächlich in beide Richtungen argumentieren:

• Aufgrund fehlender technischer Fähigkeiten müssen Sie nicht versuchen, das technische Problem zu analysieren und eine technische Lösung zu liefern, während Sie dem Team helfen, die Zusammenarbeits- und Kommunikationsprobleme zu identifizieren und nicht-technische Hindernisse zu beseitigen. Mit Ihrem Hintergrund in Psychologie wären Sie in der Lage, den Teammitgliedern direkte, zum Nachdenken anregende Fragen zu stellen, die zu einer Lösung der Hindernisse führen oder Ihnen helfen würden, an die richtigen Personen zu eskalieren.

• Wenn Sie über technische Fähigkeiten verfügen, können Sie zwischen einfachen Hindernissen, die durch kleine Probleme oder mangelndes Wissen verursacht werden, und viel größeren Problemen unterscheiden, die durch tiefgreifende Komplexitäten verursacht werden, die möglicherweise nicht sofort gelöst werden. Ein tieferes Verständnis der Technologie würde es Ihnen ermöglichen, schnell zu erkennen, an wen Sie ein Hindernis eskalieren können, oder dem Team sogar vorzuschlagen, dass es den geschäftlichen Wert nicht wert ist, „tiefer zu graben“ zu einem bestimmten Hindernis/Thema.

Wenn es darum geht, Junior zu sein und als Mentor zu fungieren, müssen Sie meiner Meinung nach die Rolle des Scrum Masters eher als dienende Führungsrolle als als Mentorenrolle sehen. Während Sie in Bezug auf den Prozess selbst als Mentor fungieren, sind Sie in Bezug auf den täglichen Ablauf und das Ziel, geschäftlichen Nutzen zu erzielen, ein Diener des Teams. Sie konzentrieren sich darauf, die Hindernisse zu beseitigen, mit denen sich Entwickler sowieso nicht gerne auseinandersetzen ("Personalkram", Managementprobleme usw.), und konzentrieren sich darauf, die richtigen Leute zur richtigen Zeit zusammenzubringen. Aus meiner persönlichen Erfahrung als Scrum-Entwickler, Scrum-Master und jetzt Teammanager kann ich sagen, dass ich bisher keine Entwickler erlebt habe, die nur aufgrund des Alters/der Erfahrung mit einem Junior-Scrum-Master ungern zusammenarbeiten. Ich habeEntwickler haben gesehen, dass sie zögern, mit einem Scrum Master zu arbeiten, der den Prozess nicht vollständig versteht: Konzentrieren Sie sich beispielsweise als Junior Scrum Master zu 100 % darauf, Scrum, Agile und Lean zu verstehen und einen geschäftlichen Mehrwert zu schaffen, indem Sie den Prozess ständig hinterfragen und verbessern.

Ja, es ist möglich, auch mit einem geringen technischen Hintergrund in die IT-Branche als Scrum Master einzusteigen. Das ist nicht der springende Punkt in Ihrem Job. Es geht vielmehr darum, ein Team zu verstehen und Hindernisse aus dem Weg zu räumen.

Trotzdem möchte ich Sie ermutigen, sich Ihren eigenen kleinen technischen Hintergrund zu schaffen, denn manchmal müssen Sie einige technische Probleme verstehen, die sich in Meetings äußern, oder vielleicht Hindernisse beseitigen oder Hilfe für andere Bereiche des Unternehmens anfordern.

1. Achten Sie darauf, hören Sie, was passiert, und lesen und lernen Sie danach die Konzepte kennen. Nur Konzepte, nur die Hauptideen.

2. Wenn Sie die grundlegenden Konzepte verstehen und verstehen, wie die Konzepte zusammenhängen, wäre es vielleicht an der Zeit, einen zusätzlichen Schritt zu machen: zu überprüfen, was mit dem X-Konzept passiert, Fragen an Ihr Team auf informelle Weise zu stellen, indem Sie fragen: Ich verstehe Y, weil in Beim letzten Treffen ist es passiert Z, irre ich mich?

Es verursacht nichts, solange das Team, mit dem Sie arbeiten, es positiv bewertet. In den meisten Fällen erwarten die technischen Teams jedoch, dass der Scrum Master über technisches Wissen verfügt. Als neue Biene, wenn Sie es nicht haben, verursacht es Ihnen kein Problem. Im Laufe der Zeit können Sie sich Wissen über Technologie und Entwicklung Ihres Projekts/Produkts aneignen, das Ihnen helfen würde, zu verstehen, worüber Tech-Teams sprechen.

Wenn Sie nicht auf dem neuesten Stand sind, würden die Teams Sie als Problem betrachten. Denn ein technisches Team lange zu leiten, ohne seine Probleme zu verstehen oder was es tatsächlich tut, würde nicht länger funktionieren.

Beginnen Sie einfach mit '0' und sammeln Sie Wissen, während Sie fortfahren. Das sollte funktionieren.

Zunächst werden sie sich möglicherweise mit Ihren Organisationsfähigkeiten und PM-Fähigkeiten befassen. Wenn sie beeindruckt sind, würde jedes positive Teammitglied Sie sicher unterstützen, damit Sie lernen.

Meiner Meinung nach sollten Sie mindestens 3-4 Jahre Erfahrung sammeln, indem Sie in verschiedenen Rollen wie Entwickler (Backend oder Frontend) und QA arbeiten, bevor Sie in die Rolle des Scrum Masters eintauchen. Die Erfahrung, die durch die Arbeit als Teammitglied gewonnen wird, ist von unschätzbarem Wert und wird der Rolle von SM gerecht. Andernfalls würden Sie Buchwissen aus dem 2-tägigen SM-Workshop anwenden.

Wütend. Bitte tun Sie dies nicht. Ich glaube wirklich nicht, dass du weißt, worauf du dich einlässt. Lassen Sie einen Entwickler den „Scrum Master“ sein und Sie sollten sich auf die Projektmanager-artigen Dinge wie das Planen von Meetings und das Erstellen von Tabellenkalkulationen und so weiter konzentrieren.

Schauen Sie, ich kann verstehen, warum tertiäre Spieler auf der Bühne sich mit diesen Dingen beschäftigen wollen. Den Lebenslauf mit Buzzwords auffüllen, etwas Glaubwürdigkeit „auf dem Papier“ in der Branche gewinnen etc. Aber aus reiner Effizienzsicht geht das nicht. Ich habe es mehrere Male gesehen – es kann ein Team wirklich auseinander reißen. Diese ganze Sache mit "Psychologie" und "Menschen helfen, zusammenzukommen", das ist großartig und edel, aber das wird nicht passieren, es wird das Gegenteil sein. Vertrau mir.