Der ScrumMaster als „Servant Leader“

Neuerdings reden wir in der IT alle darüber, agile Organisationen zu bilden, agiles Leadership aufzubauen, agile Teams zu bilden. Der ScrumMaster wird dabei oft etwas mythologisiert. Mancherorts erscheint es so, als ob eine erfolgreiche agile Prozessreise (Journey) einzig und allein vom ScrumMaster als „Servant Leader“ abhinge. Nur was dieses Servant Leading sein soll, da scheiden sich die Geister wieder. Auch bleibt vielfach die Frage danach offen, was ein ScrumMaster genau zu tun hat und was einen guten ScrumMaster recht eigentlich ausmacht.

Die wichtigsten Fähigkeiten eines ScrumMasters sind laut meiner Erfahrung hohe soziale Kompetenz, ausgeprägte Kommunikationsfähigkeiten und tiefgreifende Leadingerfahrung. Bereits an dieser Stelle ist es mir wichtig anzumerken, dass man die Rolle des ScrumMasters keinesfalls aus dem Lehrbuch, durch Zertifizierungen oder Seminarbesuche lernen kann. Unternehmen die mit Scrum starten, oder Scrum bereits eingeführt haben, aber noch unsicher im Doing sind, sollten m. E. einen erfahrenen ScrumMaster für 1-2 Sprints als Coach hinzuziehen. Dieses Investment macht sich spätestens ab Sprint 5 bezahlt, das heißt hat sich für den Kunden amortisiert. Warum das so ist, versuche ich im Weiteren zu diskutieren, indem ich entlang meiner Erfahrung ein paar Insights aufzeige, die man nur über längjährige Praxis lernen kann. Meines Erachtens ist es für einen ScrumMaster neben der Praxis extrem wichtig mit anderen ScrumMastern in Austausch zu stehen, Blogs zu lesen und an agilen Konferenzen teilzunehmen. Mir erscheint es auch wichtig zu sein, dass ein ScrumMaster Applikationen wie Atlassian JIRA & Confluence gut bedienen kann. Ohne derartige Tools kann er seiner Verpflichtung des Trackings der Velocity nicht nachkommen. Velocity ist die Maßeinheit für die Schnelligkeit des Teams. Da der Scrum Prozess per definitionem empirisch ist, sollte ein ScrumMaster diesen Skill schon abdecken. Häufig konzentrieren sich ScrumMaster zu stark auf derartige Administrationen und übersehen dabei den wesentlicheren Teil des Leadings, der ein viel erfolgskritischer Faktor ist. Für mich hat sich eine Aufteilung von 70% Leading und 30% Administration im Laufe der Jahre als sehr erfolgreich herauskristallisiert.

Der ScrumMaster als Leader

Scrum Rollen: Kobald Agile Expert & IT-Projects, 2017

Der ScrumMaster steht dem Development Team sehr nahe. Er muss im Sinne der Effizienz, Kunden-Satisfyers und Velocity dafür sorgen, dass das Team ohne Außenstörung innovativ, prozessbezogen und selbstorganisierend die Performance für den Kunden bringen kann. Wer ist aber der Kunde? Den Rollen Stakeholder, Projektleiter, Auftraggeber, Steering-Kommitees, Endkunden und natürlich dem Product Owner begegnet man  natürlich auch beim Scrumen. Bisher bin ich am Besten damit gefahren, wenn der Product Owner, das Developement-Team und ich als ScrumMaster uns darauf einigen konnten, den End-User als die Kunden zu sehen. Das ist in einer E2E-Betrachtung des personenzentrierten Entwicklungsprozesses einer Software für mich das Um und Auf. Die End-User, oder anders ausgedrückt die Anwender, bestimmen in ihrem täglichen Arbeiten den tatsächlichen Nutzen einer Software. Nur wenn die Anwender den Nutzen in der Usability für ihr Tun sehen, wird der erwartete Business Nutzen eingefahren werden. Daher ist es enorm wichtig für den ScrumMaster dafür zu sorgen, dass er selbst, der oder die Product Owner und das Development Team (Scrum Factory) ein gemeinsames Produktbild, mit Blick auf die Anwendbarkeit der End-User hin, entwickeln. Eine erste erfolgskritische Regel der Agilität wird damit erfüllt: See the whole picture! Diese erste wichtige Arbeit des Scrum Masters für das Team, dem Product Owner und einem E2E-Scrum-Prozess ist für mich wirklich erfolgsentscheidend. Im herkömmlichne Projektmanagement wird beispielsweise die Vorprojektphase nach wie vor für die positive Entwicklung eines Projekts völlig unterschätzt. Ähnliches gilt hier: Diese Sichtweise ins Team und zum Product Owner zu bringen und davon zu überzeugen, ist m. E. der zentrale Erfolgsfaktor. Dies passiert auch in eigener Sache. Ohne viel Tam Tam kann der ScrumMaster damit bereits von Beginn an sein Verantwortungsbewusstsein und seinen Leadingcharakter einbringen.

One Product = One Vision = One Product Vision Box

Ein wichtiges innovative Game, das das Teambuilding aller Scrum Rollen unterstützt ist die Entwicklung einer Product Vision Box. Diese Methode kommt aus dem UX-Design. Ich habe damit gute Erfahrungen gemacht. Die Voraussetzung dazu ist aber, dass der Product Owner und das Developement Team diesem Vorschlag zustimmen. Öfter mal werden die so genannten Personas gerne verwendet. Eine Persona ist ein Prototyp für  eine Gruppe von End-Nutzern. Persönlich habe ich mit dem Ziel das whole picture zu sehen mit der Product Vision Box bessere Erfahrungen gemacht. Der riesen Vorteil dieses innovation games liegt für mich darin, dass man es mit wenig Zeitaufwand schafft, das gegenseitige Vertrauen sowie Verständnis zwischen Product Owner und Development Team aufzubauen. Wesentlich erscheint mir auch, dass das Scrum Team

Product Vision Box
Product Vision Box, Kobald Agile Expert & IT-Projects, 2017

ein besseres Gefühl für das Planning Poker des Sprint Backlog entwickelt.

Luke Hohmann ist der Founder und CEO von „The Innovation Games® Company“ und meint zur Product Box:

The Product box is one of the most useful and popular “innovation games”. The technique is both very close to the previous format and different (due to its strong “UX” connotation”). With the product box we really have the VOICE of THE CUSTOMER.

Die Product Box basiert auf den User Storys des Product Backlog. Der gemeinsame Workshop ist End-User orientiert. Damit ist gemeint, dass wir aus dem Product Backlog ein Produkt entwickeln, dass der End-User gerne verwenden möchte. Der Zweck ist, dass zentrale Funktionalitäten, Schnittstellen und Usability-Anforderungen kurz und bündig gemeinsam zusammengefasst werden.

Wie lange dauert dieses innovation game?

  • 40 Minuten um die Box zu bilden
  • Jeweils 5 Minuten pro Teilnehmer, um die Box den anderen „zu verkaufen“

Die Product Vision Box ist eine Cereals-Box mit weißem Packpapier umklebt. Auf Vorderseite wird die Product Vision geschrieben und 3-4 Verkaufsargumente. Auf der Rückseite werden zentrale Funktionalitäten, Usability-Anforderungen und Schnittstellen angeführt. Für mich liegt der Mehrwert dieser Methode darin, dass damit gerade für die Schnittstellenthematik sensibilsiert wird. Allenthalben wird die Product Box so etwas wie ein Maskottchen. Ich nehme sie zu jedem Meeting mit. Die Signalwirkung ist sensationell: Seht her, darüber reden wir, das ist das Produkt für unseren Kunden!

Jim Highsmith meint dazu:

The “Product Vision Box” is a very appropriate technique when starting a project to create the vision and share it with the team responsible to design the product (and why not, those in charge of the sale).

Menschenzentriertes Coaching und Prozess-Consulting

Scrum Team Building Prozess, Kobald Agile Expert & IT-Projects, 2017

Die Selbstorganisation eines Scrum Teams ist keinesfalls einfach oder banal. Die Kunst des ScrumMasters liegt darin, dass er das Team dabei unterstützt sich selbst zu organisieren. Wie kann diese schwieriege Aufgabe gemastert werden? Ich persönlich rede einfach gerne mit meinen Kollegen und Kolleginnen. Auch interessiere ich mich für sie. Welche Skills haben sie, welchen Background haben sie und was sind ihre Wertehaltungen. Besonders die Wertehaltungen sind für mich essentiell. Nur wenn die Wertewelt halbwegs zusammenpasst, wird das Team innovativ sein, selbstorganisiert agieren und performen können.

Wie ich in der Skizze weiter oben zeige, unterliegt der Teambuildingprozess in Scrum meiner Erfharung nach, besonderen gruppendynamischen Mechanismen. Die Besonderheit ist, dass es keine Führung im herkömmlichen Sinn gibt. Die Aufgabe des ScrumMasters ist es nun, in allen vier Phasen gruppendynamisch zu unterstützen. Der wichtigste Mechanismus ist und bleibt die Aufrechterhaltung der Selbstorganisation des Teams. Daher ist es meiner Meinung nach umso wichtiger die gegenseitigen Erwartungshaltungen abzuholen. Soweit ich in der Praxis erfahren habe, ist es wichtig, dass der Product Owner, der ScrumMaster und das Scrum Team ihre gegenseitigen Erwartungshaltungen austauschen. Ansonsten bleiben sie unbekannte Rollen, also als Menschen nicht greifbar. Wenn ein Mensch nicht greifbar ist, dann ist er für uns nicht gut einschätzbar und das schürrt innere Abgrenzung. Setzt man sich zusammen, um die Erwartungshaltungen abzuholen,  schafft das erstens Vertrauen, zweitens Glaubwürdigkeit und drittens friktionsfreien Raum. Daher ist eine meiner dringlichsten Empfehlungen die Erwartungshaltungen gleich zu Beginn festzustellen. Dabei sollten folgende Fragen geklärt werden:

  • Was kann man von mir erwarten?
  • Was erwarte ich vom Team?
  • Was erwarte ich vom Product Owner, SrumMaster, Scrum Team?
  • Was erwarte ich von der Organisation?

Nur so kann ich als ScrumMaster auch wirklich erfahren, wo ich einen Schwerpunkt zu setzen habe. Das Abholen der Erwartungshaltungen beeinflusst meine Herangehensweise für Sprint Plannings, Backlog Grooming, Retrospektiven, Dailys, Testing oder Pair Programming wesentlich. Diese Themenfelder sind mein technisches Metier als Scrum Masters. Über die Erwartungshaltungen kann ich erkennen, was speziell die einzelnen Teammitglieder und das gesamt Team im Zusammenspiel mit dem Product Owner, dem Prozess und der Aufbauorganisation benötigt. Diesen Flow im laufenden Geschäft aufrecht zu erhalten, ist ein ganz zentrale Aufgabe des ScrumMaster. Mit den richtigen Hilfestellungen, wie etwa Coaching, Prozess-Consulting oder Methodik-Input, leistet der ScrumMaster seinen Dienst als servant leader!

Sie haben weitere Fragen? Ich kann Sie bei einer Problemlösung unterstützen? Dann kontaktieren Sie mich bitte!