Scrum Master? Brauchen wir nicht…! (Teil 1/2)

Gepostet von

Wenn ich mit Managern über die Besetzung der Rollen einer Scrum-Zelle spreche, habe ich relativ leichtes Spiel, solange es um den Product Owner und das Team geht.

Warum aber gibt es bei der Rolle des Scrum Masters immer wieder Diskussionen um dessen Sinnhaftigkeit?

Wenn Sie in der Verantwortung sind, ist Ihnen klar, was „das mit dem Scrum Master“ eigentlich soll?

In der bisherigen Denkwelt von Unternehmen gibt es viele Manager. Project Manager, Quality Manager, Configuration Manager, Release Manager und viele andere mehr.

Ihnen gemein ist, dass sie jeweils ein klares Aufgabenprofil haben: Der Project Manager kümmert sich z.B. um die Strukturierung der Aufgaben und ihre Verteilung, der Quality Manager um die Qualität im Unternehmen oder im Projekt, der Configuration Manager kümmert sich um Versionierung und Konfigurationen, der Release Manager um die Freigabeplanung und –durchführung.

Sie alle planen Dinge, lassen sie durchführen, verfolgen deren Fortschritt, schätzen Risiken ein, treffen Entscheidungen.

Das Prinzip dahinter ist das der Arbeitsteiligkeit: Da die Sache (z.B. das Produkt, das mittels eines Projekts realisiert werden soll) zu groß und zu komplex ist, um von einem alleine bewältigt zu werden, muss eine Aufteilung stattfinden. Und klassischerweise findet die entlang der Disziplinen des Systems Engineerings, entlang von Organisationseinheiten oder anderen, naheliegenden Kriterien statt.

Hat man nun agile Teams, sieht die Welt geringfügig anders aus. Wir sprechen plötzlich von einem Produkt und von Produktinkrementen. Nicht von Projekten. Und von „cross-functional“, statt „arbeitsteilig“.

Seltsam.

Das Produkt als Ganzes zu betrachten. Eine Vision zu haben. Nicht den Anspruch zu haben, von vorneherein alles wissen und strukturieren zu wollen. Sich auf das Unbekannte einzulassen. Die Änderung als eine der wenigen Gewissheiten zu betrachten. Am Ende jedes Sprints zu liefern. Keine Projektstatusberichte abzuliefern, sondern ein Produktinkrement in definierter Qualität bereitzustellen. Mit völlig neuen Rollen zu arbeiten.

Ungewohnt.

Und weil das ungewohnt und unbekannt ist, passiert dann dieses: Man überträgt die bisherigen Kriterien und Prinzipien auf die Scrum-Zelle.

Man betrachtet eine Produktentwicklung als Projekt. Man arbeitet so weiter, wie bisher, nur in kleineren Zyklen. Man besetzt den Product Owner mit vormaligen Projektmanagern. Man belässt die Teams, wie sie sind.

Und wundert sich dann, dass das Agile nicht so richtig zum Fliegen kommt. Dass man plötzlich soviele Meetings hat. Deren Zweck nicht immer klar ist. Die Zeit fressen. Und man gar nicht mehr zum Arbeiten kommt.

Lassen Sie uns also einmal klären, was in einer Scrum-Zelle, die echt agil arbeitet, eigentlich passiert:

  • Es gibt einen Product Owner, der sich um die strategische (Roadmap) und taktische Planung (Sprintplanung) des Produkts kümmert. Der die Verantwortung dafür hat, dass seine Kunden und Stakeholder das bekommen, was sie benötigen. Der mit diesen Zielgruppen einen engen Dialog führt. Der mithin auch für die Produktqualität verantwortlich ist, ebenso wie für die Planung der Lieferzeitpunkte.
  • Es gibt ein Team, das die Wünsche des Product Owners herausfordert. Ihm damit hilft, die kritischen Aspekte zu entdecken und mit seinen Kunden und Stakeholdern zu klären. Das ihm mit den agilen Schätzungen eine Idee von der Größe seiner Wünsche gibt und ihm damit überhaupt erst eine zeitliche Planung ermöglicht. Das sich überlegt, welche dieser von ihm in eine Reihenfolge gebrachten Wünsche es im nächsten Sprint umsetzen und mithin versprechen kann. Das alles dafür tut, seine Versprechen zu halten und die versprochenen Produktinkremente zu liefern. Das von den Kunden und Stakeholdern für seine Lieferungen regelmäßig Feedback erhält, um sich und das Produkt kontinuierlich verbessern zu können.

Sieht man sich das alles genau an, stellt man fest, dass die Themen, die bislang über mehrere Managementrollen verteilt werden, sich hier wiederfinden. Nur eben im Kontext des Produkts und seiner Features, und exakt darauf fokussiert.

Es werden also, als ein Beispiel, nicht irgendwelche Qualitätsmaßnahmen geplant, die in einem generischen QM-Plan stehen und vielleicht für das Produkt im aktuellen Entwicklungsstand überhaupt nicht sinnvoll sind, sondern es werden genau diejenigen Qualitätskriterien durch den Product Owner definiert und durch das Team umgesetzt, die für den Kunden und die Stakeholder zum jeweiligen Zeitpunkt wichtig und notwendig sind.

Die Wertschöpfung ist durch Product Owner und Team abgedeckt, denn über die gelieferten Produktinkremente und die zu bestimmten Zeitpunkten durchgeführten Releases wächst das Produkt so lange, bis der Kunde und die Stakeholder genügend Wert und Nutzen geliefert bekommen haben.

Hm… war da nicht noch etwas…?

Ach ja, der Scrum Master. 
Wenn die Wertschöpfung durch PO und Team abgedeckt ist, wozu brauchen wir den jetzt nochmal genau?

(Fortsetzung im zweiten Teil in einigen Tagen…)

 

(Photo by Mathilda Khoo on Unsplash)

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s