Was wird von einem Scrum Master auf verschiedenen Karrierestufen erwartet?

Ich denke, die verschiedenen Ebenen können sich auf die Agile Onion beziehen, wie sie von Simon Powers beschrieben wird .

Einstiegsniveau : Kann die Tools und Prozesse implementieren, hat aber kein gutes Verständnis dafür, warum die Prozesse, Praktiken, Prinzipien und Werte existieren. Könnte zu Cargo-Kult führen Agile .

Mittelstufe : Kann auf Teamebene arbeiten, hat aber noch nicht die Erfahrung, Organisationen zu verändern. Versteht Prinzipien und Werte, ist aber möglicherweise noch nicht der Beste, um andere Scrum Master zu unterrichten. Aber sollte Teams in agilen Praktiken wie technischer Exzellenz coachen .

Senior : Unterstützt das Management bei der Schaffung struktureller und kultureller Veränderungen in der Organisation, um agiler zu werden. Führt den Weg durch Agile Fluency .

Guru : Führt (größere) erfolgreiche agile Transformationen an, schreibt Bücher usw.

In unserer Organisation erleichtern Junior-SMs den Rhythmus des Projekts. Sie stellen sicher, dass die Meetings stattfinden, stellen sicher, dass die richtigen Leute da sind, helfen den Teammitgliedern bei der Selbstorganisation und verfolgen auch Dinge wie Story Point Burndown usw. Sie liefern Zusammenfassungen der Teamarbeit bei internen Sprint-Reviews und bringen Probleme im Team zur Sprache muss zur Verwaltung. Wie bei der klassischen Definition von agilem Scrum suchen sie immer nach Hindernissen und versuchen, diese zu beseitigen.

SMs auf mittlerem Niveau fallen im Allgemeinen aufgrund ihrer sozialen Fähigkeiten auf. SMs auf mittlerer Ebene sind Führungskräfte (nicht im Sinne eines traditionellen Managers, aber sie sind jemand, auf den das Team schaut und auf den er sich verlässt). SMs auf mittlerem Niveau sind großartig darin, Teamzusammenhalt zu erzeugen, und die Teammoral ist tendenziell hoch. Auf dieser Ebene neigt der Sm dazu, sich mit seiner Erfahrung viel wohler zu fühlen, um vergangene Sprints zu betrachten und Prognosen über die zukünftige Arbeit zu erstellen, die sie für PMO-Typen sehr nützlich machen. Ein SM auf mittlerer Ebene kann nicht nur helfen, ein Planungsmeeting zu moderieren, sondern hat auch Erfahrung mit dem Team und kann Schätzungen dazu beitragen, was auf der Grundlage der bisherigen Leistung möglicherweise zu groß oder nicht zu groß ist. Dies hilft den technischen Leitern und BAs in der Regel sehr.

Senior SM neigen dazu, in die Managementfunktionen hineingezogen zu werden, die (meiner Meinung nach) der schwache Bereich von agilem Scrum sind. Senior SM sind oft an der Organisation projektweiter Initiativen beteiligt, halten die SQA-Bemühungen (organisatorisch) auf Kurs und stellen sicher, dass die Teams die erforderlichen Bereiche abdecken, wenn es um Release-Probleme, Fehlerpriorisierung usw. geht. Bei einem größeren Projekt neigen sie dazu, zu füllen die Lücke, die dort verbleibt, wo "Selbstorganisation" im Grunde versagt (alles, was größer als 40 Personen oder so ist) und viele Rollen übernimmt, die traditionell von einem PM- oder PMO-Personal abgedeckt werden. Leider bedeutet dies, dass Senior SM oft zu dünn auf viel zu viele Verantwortlichkeiten verteilt sind.

Junior

Ein Junior Scrum Master sollte die grundlegenden Prinzipien und Gründungsideen hinter Agilität verstehen und erklären können. Sie sollten in der Lage sein, den eher zurückhaltenden Mitgliedern eines Teams zu erklären, warum sie agil arbeiten.

JSMs (wenn ich es so abkürzen darf) sollten in der Lage sein, alle grundlegenden Agile-Zeremonien auf einer sehr informellen, ungezwungenen Ebene zu erleichtern und zu vermitteln. Dazu gehören tägliche Standups, Sprint-Planung, Backlog-Verfeinerung, Sprint-Review und Retrospektive-Meetings. Sie sollten den grundlegenden Zweck jedes Meetings verstehen und dem Team eine gewisse Richtung geben sowie das Meeting lenken, ohne sich einzumischen. Lassen Sie zu, dass die richtigen Gespräche auf natürliche Weise stattfinden, aber lenken Sie sie auch davon ab, auf eine Tangente zu geraten.

Dazwischenliegend

Auf dieser Ebene muss der Scrum Master die Arbeit des Teams besser verstehen und sie erklären oder bei Bedarf über Neuigkeiten informieren. ISMs sollten bei der Arbeitsaufnahme helfen. Sie sollten in der Lage sein, grundlegende Diskussionen mit dem Business Analyst des Teams und anderen Stakeholdern zu führen, um bei der Definition und Aufgliederung von Anforderungen und Dokumentation der Arbeit zu helfen und sicherzustellen, dass die Anforderungen und die Arbeitsaufnahmekapazität mit den Teamzielen und früheren Sprintkapazitäten übereinstimmen. Sie sollten in der Lage sein, mit dem Product Owner zusammenzuarbeiten, um die Prioritäten zu verstehen, und sollten dann sicherstellen, dass die Sprintpläne des Teams mit diesen Prioritäten übereinstimmen, und dem Team helfen, dem PO alle Verzögerungen, Hindernisse oder unerwartete eingehende Arbeiten mitzuteilen.

Der Scrum Master sollte auch als Roadblock-Mover fungieren. Sie sollten in der Lage sein, bei der Eskalation und Lösung von Problemen zu helfen, damit das Team effizienter arbeiten kann, und sie sollten beginnen, sich mit der Dynamik zwischen den Teams zu befassen. Beispielsweise sollten sie während Retrospektiven anfangen zu sehen, ob bestimmte Teammitglieder anderen Ärger bereiten, und nach Möglichkeiten suchen, dies zu beheben. Sie sollten sich wohler fühlen, wenn es nötig ist, schwierige Diskussionen zu führen („Ihr Verhalten schadet Ihrem Team, welche Ideen haben Sie, um das zu beheben?“). Er übernimmt nicht die Rolle des Managers, aber er muss Tag für Tag bestimmte Dinge verwalten und sicherstellen, dass das Team seinen Verpflichtungen nachkommt. Der Scrum Master sollte sich als integraler Bestandteil des Teams fühlen und die Erfolge seines Teams feiern und sich schlecht fühlen über Dinge, die sein Team ausbremsen.

ISMs sollten dem Team helfen, seinen Rückstand in Bezug auf die Grunzerarbeit des Erstellens von Karten und des Ausfüllens von Anforderungsdetails und die Priorisierung der Arbeit aus Diskussionen mit Interessenvertretern zu verwalten; Sie sollten in der Lage sein, sich ein paar Notizen darüber zu machen, was erledigt werden muss, und es später erledigen zu können, ohne während der Agile-Meetings wertvolle Zeit zu verschwenden, die für die Zusammenarbeit und Diskussion im Team genutzt werden könnte.

Meetings sollten strukturierter und formalisierter werden. Das Team-Backlog sollte gut dokumentiert sein, entweder digital oder physisch, und es sollten einige Anstrengungen unternommen werden, um sicherzustellen, dass Karten bei jedem Standup verschoben werden, und Teammitglieder sollten für die Bereitstellung eines Updates verantwortlich gemacht werden. Wenn sie nicht physisch bei der Besprechung anwesend sein können, sollten sie eine Aktualisierung per E-Mail oder auf andere Weise bereitstellen und eine andere Person für sie einspringen lassen. Das Team sollte das Gefühl haben, dass es synchron ist. Es sollte irgendwo ein Arbeitsvereinbarungsdokument ausgehängt sein und das gesamte Team sollte sich dessen bewusst sein und es in die Praxis umgesetzt haben.

ISMs sollten damit beginnen, ihrem Team dabei zu helfen, sich selbst zu organisieren und sich immer weniger auf den Scrum Master zu verlassen. Je größer ihre Fähigkeiten, desto weniger sollten sie gefordert werden, in den Hintergrund treten und weniger ein aktiver Teilnehmer und mehr ein Ermöglicher und ein Beobachter sein.

Senior

Auf der obersten Ebene sollten Scrum Master ein feines Gespür für die Schwächen und Stärken ihres Teams entwickeln und einen Plan entwickeln, um diese Erkenntnisse gezielt anzugehen. Sie sollten sich wohl fühlen, das Team als Ganzes und mit einer gewissen Autorität anzusprechen, nur um es zu motivieren und zu befähigen, seine beste Arbeit zu leisten. Sie sollten in der Lage sein, Verstöße zu beheben und das Team zu ermutigen, weiterhin agile Praktiken anzuwenden. Auf dieser Ebene sollte der Wechsel von „Doing Agile“ zu „Being Agile“ abgeschlossen sein. Sie sollten verstehen, wenn sich ihr Team unwohl fühlt oder sich dagegen sträubt, agil zu sein, selbst wenn diese Bedenken nicht laut ausgesprochen werden.

Sie sollten in der Lage sein, dem Spiel einen Schritt voraus zu sein und dem Team zu helfen, auf Disruptoren zu reagieren, schnell eine Lösung zu finden oder dem Team zumindest dabei zu helfen, die Hindernisse effektiv zu kommunizieren und herauszufinden, was mit den entsprechenden Stakeholdern zu tun ist. Sie sollten Experten darin sein, Feedback zu erhalten und sich zu verbessern, nicht nur das Team, sondern auch sich selbst und wie sie die Agile-Zeremonien moderieren. Sie sollten jedes Meeting gut nutzen, sich in die Tiefen der Arbeitsbelastung des Teams einarbeiten, jeden Erfolg veröffentlichen und, wenn Probleme auftreten, zum Kern dessen gelangen, was schief gelaufen ist, und wie es in Zukunft behoben werden kann.

Sie sollten ihr Team für ihre Arbeitsvereinbarungen verantwortlich machen und keine Angst davor haben, Teammitglieder herauszufordern und hart zu werden, wenn es erforderlich ist. Dies sollte immer noch in einer agilen Denkweise erfolgen und bereit sein, sich anzupassen, wenn das Team als Ganzes entscheidet, dass sich die Dinge ändern sollten. An diesem Punkt sollte es einfach sein, ein Gefühl dafür zu bekommen, wo das Team steht und was es denkt. Das Arbeitsvereinbarungsdokument sollte weiter verfeinert werden und Teamrichtlinien für Agile-Meetings und Erkenntnisse aus vergangenen Fehlern erfassen. Der Senior Scrum Master sollte in der Lage sein, Konflikte zwischen Teammitgliedern zu schlichten und zu lösen und Teambesprechungen fokussiert und produktiv zu halten.

In dieser Phase sollten sie sicherstellen, dass die gesamte Arbeit vor Beginn eines Sprints in Aufgaben im Sprintumfang und während des Sprints weiter in Aufgaben im Tagesumfang oder kleiner unterteilt wird, damit die Karten währenddessen verschoben werden können das tägliche Aufstehen. Standups sollten zu diesem Zeitpunkt obligatorisch sein, obwohl der Zeitplan etwas flexibel wäre.

Gerade die Retrospektive sollte recht ausführlich sein und das Team wirklich zum Nachdenken anregen. Senior Scrum Master wissen, wie sie ihr Team bis ins letzte Detail ausarbeiten können, ohne darum betteln zu müssen, und wie sie jeder Person helfen können, sich daran zu beteiligen und es zu genießen.

Der SSM soll der „Mann hinter den Kulissen“ werden – dem Team in seiner Agile-Reife helfen, ohne sich einzumischen, und dem Team beibringen, die Scrum-Prozesse mehr und mehr alleine zu führen.

Guru

Scrum-Master-Gurus sollten in der Lage sein, ihr Wissen weiterzugeben und neue Scrum-Master zu betreuen. Sie sollten Agile in- und auswendig kennen und in der Lage sein, seine Grundprinzipien leicht zu erklären und zu verteidigen. Sie sollten in der Lage sein, ihren Ansatz auf ein einzelnes Team zuzuschneiden, und Experten darin sein, Menschen zu lesen und die Interaktionen des Teams zu verstehen.

Sie sollten eine große Begeisterung für Agile mitbringen und in der Lage sein, jede Situation mit dem entsprechenden agilen Prinzip in Beziehung zu setzen. Sie sollten in der Lage sein, die Scrum-Zeremonien vortrefflich für jedes Team durchzuführen, egal ob neu in Agile oder schon ziemlich ausgereift. Sie sollten mehrere Pläne und Ideen für jeden Aspekt der Agilität haben und in der Lage sein, schnell den besten Plan auszuwählen, der für jedes Szenario, jedes Team oder sogar jeden Einzelnen gilt. Sie sollten in der Lage sein, schnell ein fundiertes technisches Wissen über die Arbeitsbelastung ihres Teams aufzubauen, das es ihrem Team ermöglicht, weitaus produktiver und effizienter zu arbeiten. Sie sollten in der Lage sein, die Arbeit des Teams im Detail zu erklären und kleinere Entscheidungen in Bezug auf die Arbeitsaufnahme zu treffen, und sollten Versuche zurückdrängen, den Teamrückstand zu überfüllen oder das Team auf einer früheren Geschwindigkeit zu halten.

Sie sollten in der Lage sein, dem Team beizubringen, sich selbst zu organisieren und ihren eigenen Rückstand zu verwalten und die Agile-Meetings und -Zeremonien reibungslos und ohne Intervention oder Moderation abzuwickeln. Sie sollten agile Praktiken vorleben und in der Lage sein, Kritik vom Team anzunehmen, sogar einzufordern, und sie nutzen, um sich selbst zu verbessern. Sie sollten in der Lage sein, dem Team zu helfen, sich zu verbessern, aber dabei im Grunde unsichtbar zu sein.

TL;DR

Sie versuchen, eine Legacy-Hierarchie auf ein Framework anzuwenden, das den Begriff einer Teamhierarchie ausdrücklich ablehnt. Das macht die Frage selbst zu einem Anti-Pattern innerhalb von Scrum.

Während Personalabteilungen und Linienmanager solche Unterscheidungen oft aus organisatorischen oder politischen Gründen treffen müssen, die nichts mit dem Scrum-Framework oder den Werten und Prinzipien des agilen Manifests zu tun haben, ist dies – insbesondere in Kulturen oder Organisationen mit hoher Machtdistanz – das einzig Richtige Antwort innerhalb des Scrum-Frameworks ist, diese Unterscheidungen überhaupt nicht zu machen. Das Scrum-Team ist kollektiv für den Erfolg oder Misserfolg seiner Prozesse und Lieferungen verantwortlich, und externe Definitionen von Dienstalter sind für diese Verantwortung nicht relevant.

Analyse und Empfehlungen

Der 2020 Scrum Guide macht keine solchen Unterscheidungen. Es gibt nur drei definierte Rollen/Verantwortlichkeiten innerhalb des Frameworks, und es gibt keine Vorkehrungen für die Zeit in der Klasse oder Erfahrungsstufen für Rollentitel.

Abgesehen davon gibt es sicherlich reife Teams und (im Sinne von CMMI ) unreife Teams. Es gibt auch Leute, für die das Framework oder ihre Rolle darin neu sind. Obwohl diese Unterscheidung hilfreich sein kann, um dem Team zu helfen, das Framework zu übernehmen oder sich erfolgreich daran anzupassen, ist es wichtig zu verstehen, dass das Scrum-Framework solche Unterscheidungen nicht anerkennt:

Innerhalb eines Scrum Teams gibt es keine Unterteams oder Hierarchien.

Darüber hinaus ist das Dienstalter für die internen Prozesse des Scrum-Teams an sich nicht relevant . Während ein Scrum-Team idealerweise funktionsübergreifend ist, was bedeutet, dass das Team gemeinsam über alle notwendigen Fähigkeiten verfügt, um in jedem Sprint einen Mehrwert zu liefern, haben die Einzelpersonen innerhalb des Teams oft unterschiedliche Fähigkeiten und Erfahrungsniveaus. Das bedeutet, dass es Sache des Teams ist, zu bestimmen, wie die kollektive Verantwortung für die Bereitstellung geteilt wird, denn:

[Ein Scrum-Team ist] selbstverwaltend, was bedeutet, dass sie intern entscheiden, wer was, wann und wie tut.

Da es keine formalen Hierarchien gibt und alle Entwickler einfach „Entwickler“ sind, basieren solche Entscheidungen im Allgemeinen darauf, wer für eine bestimmte Aufgabe am besten geeignet ist. In diesem Fall ist „am besten geeignet“ oft eine Einschätzung, die das Team kollektiv vornimmt, basierend auf den individuellen Fähigkeiten aller, der Zusammensetzung des Teams und der verfügbaren Kapazität jeder Person, um Arbeit innerhalb des aktuellen Sprints zu übernehmen. Dies sollte immer gelten, unabhängig vom externen Rang oder Titel einer Person außerhalb des Scrum-Teams. Letztendlich ist das gesamte Scrum-Team für die Lieferung des Sprint-Ziels und des Produktinkrements für den Sprint verantwortlich, und die Unterscheidungen, die Sie zu treffen versuchen, ändern daran nichts.

Wenn Ihre Organisation solche Unterscheidungen außerhalb des Scrum Frameworks vornimmt, hat dies wahrscheinlich finanzielle oder kulturelle Gründe. Dies liegt im Zuständigkeitsbereich der obersten Führung. Ich würde es jedoch als die Rolle des Product Owners, des Scrum Masters und (in geringerem Maße) des Scrum-Teams als Ganzes betrachten, die Organisation darüber aufzuklären, warum dies gegen Agilität arbeitet, und zu versuchen, der Unternehmensführung dabei zu helfen, zu kommen einen besseren Weg zu finden, um die Effektivität seiner Scrum-Teams zu bewerten und Mitarbeiter basierend auf individueller Leistung einzustellen/zu entlassen/zu belohnen, wenn sie sich dafür entscheiden, trotz der klaren Branchenbeweise, dass dies ein Agilitäts-Anti-Muster ist.

Für den „Tone at the Top“ ist immer die oberste Führung verantwortlich. Wenn sie den Scrum-Prozess brechen, absichtlich oder nicht, dann dürfen sie beide Hälften behalten. QED

Schlussbemerkung: Definitionen sind relativ

Es sollte auch darauf hingewiesen werden, dass Unterschiede in der Erfahrung – und der monetäre oder politische Wert dieser Unterschiede – oft relativ sind. Während viele IT-Organisationen häufig ihr eigenes Lexikon oder ihre eigene Einstufung für Erfahrungsstufen entwickeln (z. B. verwenden viele Unternehmen 5 Jahre als willkürlichen Grenzwert, während andere die häufig entlarvte 10.000-Stunden-Methode verwenden ), sieht die Realität so aus, dass die Unterscheidungen sind in der Regel eigenwillig und unternehmensspezifisch und werden oft auf der Grundlage einer Kombination aus bestehender Unternehmenskultur, spezifischem Problembereich und dem aktuellen Erfahrungsniveau (wie auch immer definiert) der vorhandenen Mitarbeiter formuliert.

Nehmen wir zum Beispiel an, ich habe über 20 Jahre Erfahrung in bestimmten Programmiersprachen. Wenn Sie nur 10 haben, aber in dieser Sprache besser sind als ich, wer von uns ist „Senior“? Wenn ich seit einem Jahrzehnt ein professioneller Fachexperte (KMU) in etwas bin, Sie aber ein Meister des gleichen Fachs mit fünf Jahren Erfahrung sind, macht Sie das dann zu einem "Gesellen-KMU" oder sind wir vielleicht Kollegen? einige andere Karriereerfahrungen?

Betrachten Sie auch dieses Gegenbeispiel. Was ist, wenn ich drei Jahre lang meinen Hintern abgearbeitet habe, um in etwas so gut wie möglich zu sein, während Sie fünf Jahre lang in einer bequemen Sinecure herumgefahren sind? Wer von uns ist wahrscheinlich erfahrener oder besser geeignet für ein bestimmtes Projekt? Wer von uns verdient mehr eine Gehaltserhöhung oder einen Bonus?

Ich würde argumentieren, dass diese Unterscheidungen sowohl relativistisch als auch weitgehend unerheblich dafür sind, wie viel Wert eine bestimmte Person in eine Rolle, ein Team oder ein Projekt einbringen kann. Hier sind ergebnisbasierte Bewertungen für das gesamte Scrum-Team oft wertvoller als der Versuch, willkürlichen Titeln oder einzelnen Zeiten in der Klasse einen inneren Wert zuzuweisen. Ihre organisatorischen Werte werden sicherlich variieren, aber die zugrunde liegende Wahrheit der Aussage nicht.

Als Scrum Master haben Sie viele Karrieremöglichkeiten. Je mehr Erfahrung Sie mit Scrum haben, Sie werden feststellen, dass Sie die Rolle eines Agile Coaches, eines Mentors und Guides, eines Produktmanagers oder Product Owners oder vieles mehr übernehmen könnten. Ein Scrum Master kann ein Experte für organisatorische Transformation werden, indem er nicht nur einem Team, sondern mehreren Teams und Abteilungen in der Organisation hilft. Sie können Managementteams, Kundenorganisationen, andere Scrum-Teams usw. coachen, um schließlich eine entscheidende Rolle bei der Organisationsentwicklung und -transformation zu spielen.