Kategorien
Agile Scrum Team Excellence

Scrum Master Aufgabe Nr. 1 ist Wertmaximierung des Teams


Wie sieht die Scrum Master Aufgabe im Gegensatz zu der des Product Owners aus? Gibt es wirklich einen so großen Unterschied zwischen diesen Scrum Rollen? Der Product Owner hat das Ziel, das Produkt für den Nutzer maximal wertvoll zu machen. Der Scrum Master hat den Fokus, die Team- & Zusammenarbeit maximal wertstiftend zu machen. Als Scrum Master solltest du dabei im Prinzip genauso vorgehen wie der Product Owner, indem du das Team selbst als „Produkt“ ansiehst, Ownership übernimmst und Scrum auf die Teamentwicklung anwendest.

Die Scrum Master Aufgabe mithilfe vom Scrum Prozess selbst lösen.
Die Entwicklung des Scrum Teams mithilfe vom Scrum Prozess selbst

Hinweis: Die Rollen „Scrum Master“ und „Product Owner“ verwende ich für bessere Lesbarkeit im gesamten Text synonym für alle Geschlechter (m/w/d).

Begreife den Prozess als Produkt

Scrum ist ein Framework mit wenigen, schlanken Vorgaben, doch wenn es so klar und einfach wäre, bräuchte es keine Scrum Master. Scrum is easy to understand but difficult to master, so sagen selbst die Erfinder. Am Prozess muss daher genauso gearbeitet werden wie am Produkt selbst, genau das ist die Scrum Master Aufgabe.

Eat your own dog food

Das heißt für dich als Scrum Master, für kontinuierliches, schnelles Lernen im Team und für eine stetige Verbesserung des Arbeitsprozesses zu sorgen. Gute Produkte fallen schließlich auch nicht vom Himmel, ebenso wenig wie exzellente Teams!

Und was liegt näher, als Scrum Master Vorbild zu sein und sich eben jenen Prozessen, Methoden und Tools zu bedienen, welche man dem Product Owner täglich „predigt“? Practise what you preach!

Wem das Bild von Evangelisten und Predigern ebenso wenig gefällt wie mir, der kann dieses Prinzip auch wunderbar mit Eat your own dog food beschreiben. Warum auch solltest du die Scrum Master Aufgabe anders lösen als der Product Owner? Nur euer Fokus ist anders!

Als Scrum Master hast du einen konkreten Auftrag

Es wird dir als Scrum Master helfen, deine Arbeit mit dem Team und den Zusammenarbeitsprozess selbst als ein „Produkt“ zu sehen. Der Kunde ist in diesem Fall dein Unternehmen, genauer gesagt, die Entscheider im Unternehmen.

Denn diese „kaufen“ deinen Service in Form von Gehalt und Personalkosten ein, um gewisse Probleme zu lösen bzw. zu einem bestimmten Ziel zu gelangen. Das ist bei (digitalen) Produkten doch nicht anders, oder?

Deswegen ist eine der ersten Fragen, die du als Scrum Master beantworten solltest: Wer sind meine Kunden, Nutzer und weiteren Stakeholder? Frag auch mal dein Team, ihnen fällt sicher noch jemand ein.

Es ist Scrum Master Aufgabe, für die Kunden und Nutzer der Arbeitsweise die bestmögliche Lösung zu entwickeln.
Mögliche Stakeholder eines Scrum Masters (Ergebnis einer Übung mit Teilnehmer*innen der „Agile Cologne“ im September 2020)

Agilität darf niemals ein Selbstzweck sein

Ebenso wie das Produkt selbst, entwickelst du eure Prozesse also vor allem für deine Kunden (Entscheider im Unternehmen) und für die Anwender (Scrum Team). Und du erfüllst damit einen konkreten Zweck.

Dieser kann zum Beispiel der folgende sein: „Die agilen Prozesse sollen Probleme X, Y und Z in der Zusammenarbeit des Teams und in der Entwicklung des Produktes lösen.“ Und damit sollen sie den Erfolg des Unternehmens stützen.

Denn das ist für gewöhnlich das eigentliche Ziel hinter dem Lösungsweg der Agilität. Zumindest, wenn man das Management fragt, welches mit Blick auf die Wirtschaftlichkeit und das Weiterbestehen des Unternehmens eine enorme Verantwortung trägt.

Wir wollen ja alle weiterhin unsere Brötchen bezahlen können. „Wir sind Marktführer!“ klingt doch besser als „Wir sind agil!“…nicht wahr?

Ownership für agile Prozesse übernehmen

Als Scrum Master bist du ein wichtiger Teil des Teams und du bist ebenfalls ein Owner – der Owner des Prozesses. Daher ist deine Rolle im Prinzip auch gar nicht so anders als die des Product Owners. Bei der Entwicklung und Verbesserung von „eurem Scrum“ und eurem Team kannst du im Prinzip genau so wie ein Product Owner vorgehen!

Was ist deine Team Excellence Vision?

Als Owner für die Zusammenarbeit der Menschen solltest du wissen, in welche Richtung du dein Team und damit mittelbar auch das Produkt und das Unternehmen führen und begleiten möchtest.

Diese klare Vision solltest du festhalten und anderen erklären können. Auf die Vision wirst du gemeinsam mit dem Team hinarbeiten und deine Aktivitäten und Bemühungen im Coaching des Teams sollten auf deine Vision einzahlen. Klingt strategisch? Sollte es auch sein!

Stattdessen aber löschen wir als Scrum Master oft nur Tag für Tag neue Feuer… Die wichtigen und richtigen Fragen aber sind:

  • Wohin möchtest du, wie sieht das perfekte Team aus?
  • Wozu arbeitet ihr agil und mit einem entsprechenden Framework wie Scrum?
  • Was soll dadurch im Ergebnis anders und vor allem besser werden?

Diese Frage solltest du nicht nur dir selbst sondern vor allem auch deinen Stakeholdern und Auftraggebern stellen.

Eine klare Team Vision im Einklang mit den Unternehmenszielen ist Scrum Master Aufgabe
Was Scrum für ein Unternehmen erreichen soll, steht in der „Team Excellence Vision“ (Ergebnis einer Übung mit Teilnehmer*innen der „Agile Cologne“ im September 2020)

Hast du ein gepflegtes Team Excellence Backlog?

Sicherlich hast du viele Themen im Kopf, die du mit deinem Team einmal angehen müsstest. Aber nimmst du dir dies wirklich bewusst vor? Priorisierst du regelmäßig dein Team Excellence Backlog? Und zahlen die Items im Backlog auf deine Vision und Ziele ein?

Ist das Backlog transparent für alle Mitglieder des Teams? Das ist wirklich noch einfacher als es klingt, oft reicht im ersten Schritt schon ein simples Kanban-Bord auf einem Flipchart an der Wand im Büro mit Spalten wie To Do, Doing und Done.

Ich nenne es übrigens bewusst Team Excellence Backlog, um meinen Anspruch deutlich zu machen: Wir wollen als Team gemeinsam richtig gut werden in dem, was wir tun!

Sind die Items in deinem Backlog refined?

Ein Buzzword wie „Testing“ auf einer Sticky Note reicht für ein gemeinsames Verständnis im Team nicht aus. Für dein Team Excellence Backlog sollte der gleiche Anspruch gelten wie für das Product Backlog auch.

Daher solltest du auch hier eine Definition of Ready anwenden, welche z.B. folgende Informationen in einer „Story“ erfordert:

  • Weißt du, welche Ziele du mit deinen Initiativen erreichen möchtest?
  • Was sind die Akzeptanzkriterien?
  • Wie wichtig vs. aufwendig ist welche „Story“?

Es geht also darum, die nächsten richtigen Schritte klar zu haben. Die Beschäftigung mit den Backlog Items ist zudem eine wichtige Grundlage für deine Priorisierungsentscheidungen. Nur wenn die der Wert bewusst ist kannst du Themen mit deinem Team ganz gezielt angehen und eure Zeit und Energie sinnvoll investieren.

Iterative und experimentelle Umsetzung & Validierung

Oft möchten Teams die sogenannte „Slack Time“ für Verbesserungen der Zusammenarbeit und Arbeitsprozesse nutzen. Das meint jene kleinen Zeitfenster, die nicht aktiv für die Arbeit am Produkt verwendet werden können, z.B. weil man auf etwas wartet um fortfahren zu können. Aber mal ehrlich: Welches Team hat denn im Sprint zu viel „freie“ Zeit?

Auch Arbeit am Team gehört mit in den Sprint

Ich bevorzuge es, Team- & Prozessverbesserungen ebenfalls im Rahmen der gegebenen Sprints einzuplanen, und zwar gemeinsam mit dem Team im Rahmen des Sprint Plannings. So ziehen wir Items aus dem Team Excellence Backlog ganz bewusst mit in das Sprint Backlog, denn nur dann gibt es ein Committment zur Umsetzung.

Neben dem gedanklichen Raum, den wir dadurch einräumen, spielt natürlich auch er zeitliche Aspekt eine Rolle. Denn auch die Arbeit am System ist mit Aufwänden verbunden, für die man bewusst Ressourcen einplanen sollte.

Eine Entscheidung für Arbeit am Team und ihren Prozessen heißt ja automatisch auch immer, dass diese Energie dann nicht in die eigentliche Produktentwicklung fließt. Das sind klassische Opportunitätskosten, man sollte dennoch bewusst entscheiden. Auch wirtschaftliches Denken ist Teil der Scrum Master Aufgabe.

Meine Empfehlung ist es, „Team-Stories“ und den Status der Umsetzung zum Ende des Sprints nicht in der eigentlichen Sprint Review zu besprechen. Denn die Review sollte den Fokus auf das Produkt behalten und für Themen der Teamzusammenarbeit gibt es bereits die Retrospektive. In der Retro sollte ohnehin zu Beginn immer ein Blick auf den Status von bereits definierten Maßnahmen aus vorherigen Retros geworfen werden – oder eben auf das Team Excellence Backlog.

Aktivitäten mit dem Team als Experimente ansehen

Du hast durch die Priorisierung des Team Excellence Backlogs eine Annahme getroffen – dass eine „Story“ eure Arbeitsprozesse und -ergebnisse in irgendeiner Weise verbessert. Die tatsächliche Wirkung solltest du in den Wochen nach der Implementierung kontinuierlich überprüfen.

Die Ergebnisse deiner Experimente und die damit verbundenen Hypothesen solltest du wenn möglich anhand von Metriken validieren können. Mindestens aber anhand von klaren qualitativen Kriterien. Scrum ist schließlich ein empirischer Prozess.

Verantwortungsvoller Umgang mit Team Ressourcen ist auch Scrum Master Aufgabe
Auch als Scrum Master hilft experimentelles und empirisches Arbeiten (Ergebnis einer Übung mit Teilnehmer*innen der „Agile Cologne“ im September 2020)

Natürlich kann man unmittelbar nach der Umsetzung einer Verbesserungsmaßnahme meist nicht direkt valide Aussagen über die Wirkung treffen. Es muss erst einmal ein wenig Zeit vergehen.

Aber als Scrum Master solltest du die für dich wichtigen KPIs und die damit verbundenen Ziele kennen und im Blick behalten. Das könnte z.B. die Reduktion der Anzahl neuer Bugs pro Release sein oder die Durchlaufzeit von Tickets.

Die GO Product Roadmap von Roman Pichler geht hier aus meiner Sicht in genau die richtige Richtung, weil sie auch die Ziele und die Ergebnissmessung anhand von Metriken beinhaltet. Und sie ist auch für Scrum Master nutzbar.

Die "GO Product Roadmap" von Roman Pichler erfordert - ähnlich OKRs - ein klares Ziel und Metriken
Die „GO Product Roadmap“ von Roman Pichler erfordert – ähnlich OKRs – ein klares Ziel und Metriken
Quelle: https://www.romanpichler.com/tools/the-go-product-roadmap/

Inspirationsquellen für dein Team Excellence Backlog

Bis hierher sind wir von einem gefüllten Team Excellence Backlog ausgegangen. Aber woher kommen eigentlich die Themen in deinem Backlog?

Beobachten… und Muster erkennen

Meistens setzt man als Scrum Master zuerst bei den Scrum Events an. Die Scrum Events sind natürlich wichtige Rituale und Konstanten im Sprint. Es ist daher völlig natürlich und auch richtig, diese zu optimieren, denn sie sind Orte für Insepct & Adapt, keine Frage. Gerade aus der Retrospektive werden vom Team identifizierte Themen für dein Backlog herausfallen.

Die Scrum Events sind jedoch nur EINE Gelegenheit von vielen, zu denen gemeinsam gearbeitet wird. Versuche, die Dysfunktionalitäten hinter den Symptomen zu erkennen, die sich in diesen gemeinsamen Runden und auch im täglichen Miteinander (immer wieder) zeigen. Vieles Backlog Items werden sich aus deinen Beobachtungen und Interpretationen ergeben, in Form von Hypothesen.

Zusätzlich wirst du Anhaltspunkte aus Gesprächen mit einzelnen Teammitgliedern ziehen.

Frag auch deine Kunden, was ihnen wichtig ist

Auch die Stakeholder außerhalb des Teams darfst und sollst du fragen, ob sie Verbesserungspunkte hinsichtlich der Zusammenarbeit mit eurem Team sehen. Das sind vielleicht Kollegen aus anderen Teams, die viele Schnittstellen mit euch haben. Oder die Bereichsleitung oder die Führungskräfte deiner Teammitglieder…

Gerade mit den anderen Scrum Mastern im Unternehmen lohnt sich ein regelmäßiger Austausch. Sicher könnt ihr Synergien nutzen und Themen eventuell auch gemeinsam übergreifend angehen.

Team-Backlog-Priorisierung ist Scrum Master Aufgabe
Strategische Planung anhand des „Team Excellence Backlogs“ statt reaktivem Aktionismus (Ergebnis einer Übung mit Teilnehmer*innen der „Agile Cologne“ im September 2020)

Die finale Verantwortung für das Team und den Prozess trägst immer du

Manche Coaches sehen sich in einer stark passiven Rollen und überlassen alles dem Team. In der Annahme, das Team müsse von selbst darauf kommen, dass es etwas verbessern möchte. Das sehe ich persönlich anders.

Ich bin der Überzeugung, dass die Scrum Master Aufgabe eher analog zur Rolle eines Fußball-Trainers gesehen werden sollte. Die Regeln zu kennen macht noch lange keine Top-Mannschaft! Wie spielt man das Spiel erfolgreich? Mit welchen Taktiken und Hilfsmitteln wird man richtig gut? Wenn Jogi nur zugeschaut und Fragen gestellt hätte, dann hätte Deutschland 2014 sicher keine WM gewonnen…

Das heißt bei weitem nicht, alles vorgeben zu müssen. Das „Wie“ – also die Ausgestaltung – liegt immer beim Team. Und du berätst sie dabei, wo hilfreich und nötig. Aber über das „Was“ entscheidest letztlich du als Owner. So wie es beim Product Owner mit Blick auf das Produkt auch der Fall ist. Du trägst schließlich die Verantwortung für eine wertstiftende Zusammenarbeit.

Auch hier, will ich nicht sagen, dass du auf Biegen und Brechen alles durchdrücken sollst. Du musst deine Themen einfach gut verkaufen, angefangen beim „Wozu“.

Aufgaben- und Handlungsfelder eines Scrum Masters

Du wirst von allen Seiten Inputs und Ideen für dein Backlog bekommen. Nimm dir aber immer mal wieder Zeit, auch auf das Big Picture zu schauen. Frage dich, ob im Team alle drei Erfolgsfaktoren für einen wertstiftenden Scrum-Prozess gegeben sind.

Erstens – Die RICHTIGEN Dinge tun

Macht der Product Owner einen guten Job? Ein Development Team kann noch so gut funktionieren… wenn es an den falschen Dingen arbeitet, wird das Produkt nicht erfolgreich. Als Scrum Master bist du für den Erfolg des Produktes maßgeblich mitverantwortlich.

Vielleicht sagst du jetzt: „Moment mal, das ist doch genau der Unterschied zwischen Scrum Master und Product Owner… Der Product Owner muss doch dafür sorgen, dass der Wert des Produktes maximiert wird!?“

Stimmt auch. Und als Scrum Master trägst du die Verantwortung, dass der Product Owner dies verstanden hat und entsprechend handeln kann. Denn der Produkt Owner ist Teil des Teams und dein Team ist dein Fokus.

Zu diesem Thema habe ich auch mit Oliver Winter in der Folge „Mein Freund der Scrum Master“ des Podcasts von Die Produktwerker gesprochen. Hört mal rein!

Ein Beispiel: Wenn dem Team die Motivation und das Verantwortungsbewusstsein für das Produkt fehlt, dann solltet ihr vielleicht zunächst mithilfe einer Produktvision dafür sorgen, dass die Arbeit sinnstiftend wird.

Oder wenn der Product Owner Schwierigkeiten hat, für das Team verständliche Anforderungen zu formulieren, dann könnt ihr z.B. an einem Template für User Stories arbeiten. Und in den Refinements gemeinsam mit dem Team verifizieren, ob die Stories klarer werden.

Zweites – Die Dinge RICHTIG tun

Liefert das Development Team kontinuierlich Werte aus? Ein weiteres Handlungsfeld des Scrum Masters ist die erfolgreiche Umsetzung der Produktentwicklung.

Denn was nützt die tollste Produktvision, wenn nichts davon auf die Straße – also zum Nutzer – gebracht wird? Oder wenn der User ständig Fehlermeldungen bekommt? Oder technische Schulden angehäuft werden?

Auch in diesem Feld können sich Items für dein Team Excellence Backlog ergeben, z.B. die Einführung von Code Reviews bei Merge Requests. Oder auch die Nutzung bestimmter technischer Tools. Oder gemeinsame Vereinbarungen für die Testautomatisierung oder ein Arbeiten mit dem Ansatz des Test Driven Developments. Oder oder oder…

Drittens – Die Dinge richtig GERNE tun

Der Spruch „Happy parent – happy kids“ gilt sinngemäß auch für Mitarbeiter und die Auswirkung ihres Befindens auf das Produkt und dessen Nutzer. Arbeit darf nicht nur Spaß machen, sie soll es auch!

Ob die Arbeit für das einzelne Teammitglied erfüllend ist, liegt an vielen Faktoren. Unter anderem an der Stimmung im Team, am Umgang miteinander, an den Arbeitsbedingungen. An der Möglichkeit, Dinge zu gestalten, an der entgegengebrachten Wertschätzung und vielem mehr.

Mit diesen „Soft Factors“ zu arbeiten, ist ebenfalls ein Teil der Scrum Master Aufgabe. Und das dahinterliegende positive Menschenbild ist ein enorm wichtiger Wert für exzellente Teams, die exzellente Arbeit leisten.

Wichtig dabei ist jedoch: Als ScrumMaster bist du kein Feel Good Manager. Leistung kann nicht optional sein, weswegen eine Balance zwischen den drei genannten Handlungsfeldern enorm wichtig ist.

Ein erfolgreiches Produkt ist mittelbar auch Scrum Master Aufgabe

Wie man sieht, ist die Aufgabe eines Scrum Masters gar nicht so anders, als die eines Product Owners. Es geht um weit mehr, als um die Moderation von Meetings oder das Verwalten von JIRA!

Nichtsdestotrotz: In vielen Unternehmen, die mit Scrum arbeiten, gibt es für jedes Produkt einen Product Owner aber keine oder nur wenige Scrum Master. Was erscheint dem Management also offenbar wichtiger? Alleine an diesem Symptom wird sichtbar, warum du auch als Scrum Master empirisch arbeiten und Mehrwerte intern vermarkten solltest.

Wer immer noch mehr als ein Scrum Team parallel begleiten muss, der kann seiner Führungskraft gerne diesen Artikel weiterleiten.

Der Köder muss dem Fisch schmecken

…nicht etwa dem Angler. Sonst wird sich kein Erfolg einstellen. Es ist nicht primär die Scrum Master Aufgabe, ein Team agil zu machen – mache es erfolgreich! Und denke wie ein guter Product Owner also immer daran, das „Wozu“ zu erklären. Wie werdet ihr durch deine Ideen potentiell besser? Dann können die einzelnen Teammitglieder mitziehen. Es muss erkennbar sein, welchen Mehrwert du schaffen möchtest. Und ob es sich lohnt, hier Zeit und Energie zu investieren.

Gleiches gilt auf einer höheren Ebene. Du brauchst für eine erfolgreiche agile Arbeitsweise das Buy-In des Managements. Und auch hier läuft es wie bei einem Produkt: Als Kunde gebe ich einen Vertrauensvorschuss und wenn ich nach drei Monaten nicht zufrieden bin, dann kündige ich mein Abo. Daher hast du als Scrum Master eine Bringschuld!

Wenn du der Überzeugung bist, dass Agilität der beste Weg für dein Unternehmen ist, dann zeige allen in Form von Ergebnissen, dass es stimmt. Schritt für Schritt, nach dem Prinzip der kontinuierlicher Verbesserung. Sei neugierig, transparent in deinem Handeln und forciere das gemeinsame Lernen!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.