Direkt zum Hauptbereich

Wie liest man sich in die Aufgaben als Scrum Master:in ein?

Nehmen wir an, jemand hat keine Lust oder keine Zeit, an einem Training für Scrum Master teilzunehmen. Vielleicht sagt jemand auch, dass er sich die Themen lieber erst einmal selbst beibringen will, bevor er ein Training macht. Es gibt eine Vielzahl von Büchern zu Scrum. Mit welchen Büchern oder anderem Material sollte man starten? Hier ist eine Liste zum Einarbeiten.

Was erwarten scrum.org, Scrum Inc. und Scrum Alliance von Scrum Master:innen?

Es gibt viele Anbieter, die einem helfen, ein:e Scrum Master:in zu werden. Ich beschränke mich hier auch scrum.org, Scrum Inc. und Scrum Alliance, weil diese Organisationen von den Scrum-Erfindern Ken Schwaber oder Jeff Sutherland gegründet wurden.

  • Die scrum.org hat eine Seite mit Professional Scrum Competencies zusammengestellt. Von dort aus kann man sich durch die einzelnen Themen durcharbeiten.
  • Die Scrum Inc. hat ebenfalls ein Ausbildungsprogramm. Auf dieser Seite finden sich ausführliche Lernziele (eng. Learning Objectives).
  • Die Scrum Alliance hat eine Einstiegseite zur Zertifizierung zum Scrum Master. Ziemlich weit unten gibt es einen Link zu einer PDF-Datei mit den Learning Objectives für CSMs.

In der ersten Zertifizierungsstufe wird im Prinzip abgefragt, ob jemand den Scrum Guide und die Denkweise hinter Agilität verstanden hat. 

Diese Listen wurden von kompetenten Trainer:innen zusammengestellt. Wer sich auf eine Prüfung bei einem dieser Anbieter vorbereitet, tut gut daran, diese Listen zu kennen.

Ich habe zwei Kritikpunkte daran: ich finde sie zum einen zu lang. Zum anderen braucht man doch einige Zeit, um dieses Wissen und diese Sprache in den betrieblichen Alltag zu übersetzen. Viele Scrum-Begriffe werden den übrigen Mitarbeiter:innen erst einmal nichts sagen und eher verwirren. Deswegen habe ich mich nach Quellen umgeschaut, die vielleicht etwas verständlicher sind.

Was ist die Aufgabe von Scrum Master:innen?

Das ist der Job: Scrum Master:innen müssen (wie alle mittleren Führungskräfte) die Lieferfähigkeit ihrer Teams und Organisationen signifikant verbessern.

Scrum Master sind keine Kindergärtner. Sie sind keine (Psycho-) Therapeuten und keine Psychologen. Sie sind keine Besserwisser und sie stehen nicht über ihren Teamkolleg:innen oder über den Führungskräften. Wie gute Trainer:innen verhelfen Scrum Master:innen ihren Teams zu Spitzenleistungen. Das erfordert Empathie, Kompetenz und Durchhaltevermögen.

Foto von Martin Podsiad auf Unsplash

Das im Folgenden vorgestellte Wissen, dient dazu, Scrum Master:innen auf diese Aufgabe vorzubereiten.

Warum einlesen?

Warum muss man als neue:e Scrum Master:in das ganze Material lesen? Reicht da nicht die Praxis? Reichen nicht die offiziellen Scrum-Kurse?

Ich bin mit der Qualität der Scrum Master:innen NICHT zufrieden. Es gibt doch immer noch viele, die ihren Job von der Verbesserung nicht verstanden haben. Dieser Punkt wird - wenn man genau hinhört - auf den Trainings auch angesprochen. Aber, dass dieser Punkt wesentlich ist, bleibt nicht hängen.

Viele Kurse gehen gut auf die Mechanik von Scrum ein. (Das ist ja auch das Ziel der Kurse.) Aber für die Hintergründe und Zusammenhänge bleibt keine Zeit. Die müsst Ihr Euch selbst nehmen. Ich habe für Euch gute und relevante Quellen herausgesucht. Es ist immer noch viel, aber es ist das Wesentliche. 

Plant Euer Lernen und reseviert Euch jede Woche Eure Lese- und Nachdenkzeit. Noch besser wird es, wenn Ihr zu zweit oder zu dritt arbeitet. Die Diskussion über die Texte verbessert Euer Verständnis.

Was muss ein:e Scrum Master:in wissen?

Jeff Sutherland, einer der Miterfinder von Scrum listet vier Themenbereiche auf, mit denen sich ein Scrum Master auskennen sollte:

  • Kenntnis des Scrum Guides
  • Kenntnis von Lean Thinking für die kontinuierliche Verbesserung und für die Produktentwicklung
  • Kenntnis der Scrum Patterns
  • Kenntnis über skaliertes Scrum, d. h. wie koordinieren mehrere agile Teams ihre Arbeit.

Ken Schwaber, der andere Miterfinder, betont stets die Wichtigkeit eines empirischen Vorgehens und eines angemessenen Umgangs mit komplex-adaptiven Systemen.

Wenn Ihr die folgende Leseliste durchgearbeitet habt, habt Ihr folgendes Wissen:

  • Was sind die wesentlichen Begriffe bei Scrum und wie ist Scrum entstanden?
  • Wie kann ich einem Team helfen, seine Leistung zu verbessern? Wie mache ich es durch Training flexibler? Wie reduziere ich unnötige Konflikte? Wie formuliere ich Zielzustände und wie sorge ich täglich für die Verbesserung der Lieferfähigkeit? Wie rede ich mit Teammitgliedern, damit sie sich selbst verbessern?
  • Auf welche Themen muss ich im Alltag achten, um die Produktivität des Teams zu verbessern?
  • Wie können mehrere Teams gemeinsam an Ergebnissen arbeiten?

Mit diesem Wissen könnt Ihr souveräner mit Euren Teams und mit Führungskräften kommunizieren. Ihr könnt Dinge verständlicher erklären. Ihr wisst, worauf Ihr wirklich achten müsst, um bessere Ergebnisse zu bekommen.

Eine geführte Leseliste

Wie liefert Euer Team Wert?

Jede Managementrolle, jeder Managementansatz muss sich daran messen lassen, ob die Organisation damit erfolgreicher ist. Das erreicht sie durch zufriedene Kunden, die für eine gute Leistung auch einen angemessenen Preis bezahlen. Dafür braucht man kompetente und fröhliche Teams. Die ersten Fragen lauten:

  • Welchen Anteil hat Euer Team oder Eure Einheit am Umsatz?
  • Wie hoch sind die Kosten für Euer Team oder Eure Einheit?

Die Fragen sind nicht immer leicht und auch nicht immer sofort zu beantworten. Aber wenn Ihr und Eure Teams die Antwort nicht wisst, wird sie jemand anders beantworten. Und diese Antwort wird Euch vielleicht nicht gefallen. Ein gutes Scrum Team weiß immer, was es wert ist.

Zum Einstieg in das Thema Business Value empfehle ich zwei Quellen:

  • Christiaan Verwijs (ein erfahrener Scrum.org-Trainer) hat einen Beitrag über Five Types Of Value veröffentlicht.
  • Die Trainer:innen der scrum.org haben einen kurzen Leitfaden mit vielen guten Kennzahlen zum Thema veröffentlicht. Man muss sich etwas durch den Text arbeiten. Aber es lohnt sich: Evidence-Based Management Guide

Was ist Scrum? Wie ist Scrum entstanden?

Zum Einstieg gibt es einen Blogbeitrag von mir: Wie liest man sich in Scrum und Agilität ein?  Damit bekommt Ihr einen ersten Überblick. Ich empfehle, sich einen halben Tag zu reservieren und einigen Artikel aus dieser Übersicht zu folgen:

Als Nächstes folgt der Scrum Guide. Vielleicht muss man den sogar mehrfach lesen. Am Anfang wirkt er etwas unverständlich, weil es viele neue Begriffe gibt. Aber jeder Scrum Master muss diese Begriffe kennen. Ich bin ganz froh, dass es den Scrum Guide als Referenz gibt.

Auf welche Ursprungsideen greift Scrum zurück?

Die Rolle Scrum Master hat eine lange Geschichte. Das erste Scrum-Team wurde zwar "erst" im Jahr 1993 aufgebaut. Aber die Konzepte hinter dieser Rolle gehen bis ins 19. Jahrhundert zurück. 

Als ich das TWI-Programm kennenlernte, habe ich die Aufgaben des Scrum Masters viel besser verstanden. Das TWI-Programm ist die Mutter von Lean. Schaut Euch dieses Programm an. Dazu gibt es folgende Beiträge:

Jetzt wisst Ihr vielleicht besser, was mit Lean Thinking gemeint ist.

Welche Muster zeigen gute Scrum Teams?

Jeff Sutherland und andere haben untersucht, ob es wiederkehrende Muster in guten Scrum Teams gibt. Und sie haben eine ganze Reihe gefunden. Einige Muster verdoppeln jeweils die Produktivität eines Teams, wenn man weiß, wie und warum man sie anwendet. Die Liste der Scrum Patterns ist kostenfrei im Netz verfügbar. 

Jede:r Scrum Master:in sollte diese Liste, besser noch auch einige der Muster kennen. Zu jedem Muster gibt es eine kurze Beschreibung sowie Hintergründe und Literaturquellen. Nehmt Euch auch hier einen halben Tag Zeit, um die Patterns zu erkunden.

Nehmt Euch als Scrum Master:in immer wieder diese Muster vor und prüft, wie gut die schon in Eurer Organisation umgesetzt wurden.

Wie arbeiten mehrere Teams zusammen?

Wir wissen, dass Hierarchien nicht gut funktionieren. Jeff und andere Praktiker empfehlen eine fraktale Skalierung. 

Fraktale Skalierung bedeutet, dass ein Teil immer wie das Ganze aussieht. Bei einem Scrum of Scrums vertritt eine Person ein ganzes Team. Für die anderen Vertreter der anderen Teams ist diese Person das Team. 

Aus diesem und anderen Prinzipien heraus haben die scrum.org und die Scrum Inc. ihre Skalierungsmodelle entwickelt:

Zur Synchronisation der verschiedenen Einheiten gibt es verschiedene Techniken, die aber alle das gleiche Ziel haben: Fokussieren, nicht ablenken lassen und gemeinsam etwas erreichen, was man als einzelnes Team nicht schaffen kann.

  • OKRs: John Doerr ist wahrscheinlich der bekannteste Förderer von OKR. Auf seiner Webseite gibt es einen guten Einstieg: Get Started With OKRs. In Deutschland finde ich die Arbeit von Cansel Sörgens sehr gut. In ihrem Blog gibt es einen Einstiegsartikel: How does the OKR Process work? (Wenn Ihr Euch mit OKRs weiter beschäftigt, werdet Ihr von allein auf die guten Quellen stoßen.)
  • Mich stört der Hype um OKRs etwas. Ich sehe die Gefahr, dass wieder nur eine Methode implementiert werden soll, ohne zu verstehen warum. Deswegen möchte ich Euren Blick etwas weiten. Seht Euch auch Strategy Maps, Balanced Scorecards und Hoshin Kanri als Methoden an. Die gehen zum Teil etwas anders vor. Aber das Ziel bleibt das gleiche.

Natürlich gibt es noch eine Reihe weiterer Themen und besonderer Praktiken. Aber die findet Ihr auch selbst heraus. Lasst Euch von den Details nicht ablenken. Scrum Master:innen haben die Aufgabe, die Produktivität ihrer Teams und der Organisation zu verbessern. Mit dem hier vorgestellten Wissen könnt Ihr das schrittweise tun.

Macht die Dinge beim Skalieren bitte nicht zu kompliziert. Versucht immer erst, den Teamschnitt zu verbessern. Je weniger Abhängigkeiten die Teams zu anderen Einheiten haben, desto schneller können sie liefern.

Jetzt habt Ihr eine Liste zur Einarbeitung. Andere Expert:innen sind eingeladen, Ihre Listen vorzustellen. Ich verlinke gerne darauf. Meine Wünsche: die Liste geht auf die wesentlichen Punkte ein und ist kurz. Sie soll eine Einarbeitungshilfe sein.


Ihr wollt mehr über Scrum wissen? Wir haben eine Übersichtsseite zu Scrum, über die man sich in die wichtigsten Artikel in diesem Blog einlesen kann.


Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Scrum und Hardware: Es kommt auf die Basics an

Man kann Hardwareprodukte agil entwickeln. Zum einen kommt Scrum aus der Hardwareentwicklung. Die Softwerker haben die Hardwarekonzepte auf ihre Situation übertragen. Zum anderen hat Hardwareentwicklung heute ganz viel mit Software zu tun. Gerade in frühen Phasen kann man sich mit Simulationen noch viele Wege offen halten und mehrere Pfade parallel verfolgen. In diesem Beitrag empfehle ich eine Podcastfolge und ein Buch, für alle, die mit der Geschwindigkeit ihrer Hardwareentwicklung nicht zufrieden sind.