Scrum ist Agile Leadership - Teil 2

Das Agile Leadership Dreieck der 3 Scrum Rollen

Wie führt der ScrumMaster?

Geschrieben von Peter Beck am 18.03.2019

Im ersten Teil wurde an zwei Beispiel-Unternehmen gezeigt, wie Product Owner führen. Der Product Owner ist Teil eines agilen Führungs- bzw. Managementsystems, das für jede Organisation entwickelt werden muss. Scrum liefert einen Rahmen für dieses Führungssystem.

Dieser Teil führt die Geschichten der beiden Unternehmen fort, und zeigt auf wie der ScrumMaster führt.

Beispiel: Start-up

Kultur folgt Struktur 1

Das Start-up setzte von Anfang an auf Scrum als Führungssystem. Wesentlicher Treiber dafür war eine der ersten Mitarbeiterinnen des Unternehmens – eine heutige Miteigentümerin. Sie überzeugte den Gründer davon, auf eine agile Unternehmenskutur2 zu setzen und mit Scrum der Unternehmung eine Struktur zu geben, mit der es wachsen kann. Die Mitarbeiterin überzeugte den Gründer auch, dass er die Rolle Product Owner übernehmen sollte. Damit hatte sie die Führung als ScrumMasterin übernommen.

Mittlerweile ist das Unternehmen auf 50 Mitarbeiter gewachsen. Wachstum bedeutet vor allem auch Wachstum der Fähigkeiten der Teams. Diese stetig weiter zu entwickeln ist Aufgabe des ScrumMasters. Teams mussten zum Teil neu gebildet und mit neuen Mitarbeitern aufgebaut werden. Neue Praktiken müssen erlernt, und alte Handlungsweisen verlernt werden. Auch musste die ScrumMasterin schon Konsequenzen ziehen, wenn ein Mitarbeiter dauerhaft nicht in die Teams integriert werden konnte. Viele dieser Handlungen führte sie oft nicht selbst durch, sondern moderierte den Prozess. So wurden die Entscheidungen über Neueinstellungen letzten Endes von einer Gruppe aus Teammitgliedern, Product Owner und ScrumMaster getroffen.

Mit der gestiegenen Anzahl Teams wuchs auch die Anzahl der ScrumMaster. Zum betrachteten Zeitpunkt haben sich um die erste ScrumMasterin fünf weitere ScrumMaster gruppiert. Gemeinsam haben sie die Verantwortung übernommen, die gesamte Organisation zu optimieren. Jeder ScrumMaster betreut ein bis maximal drei Teams. Entscheidend ist aber, dass alle Teams zusammen besser werden in dem, was sie gemeinsam liefern.

Es gibt darüber hinaus verschiede Schwerpunkte, welchen sich die ScrumMaster widmen. Zum Beispiel die Moderation des Recruiting-Prozesses, Einführung und Anpassen von Methoden des Engineerings, kontinuierliches Coaching zur Product Strategie bis hin zu Skalierung der Entwicklung.

Die Produkt-Architektur ist ein Spiegelbild der Organisationsstruktur, welche das Produkt entwickelt 3

Eine der größte Herausforderungen ist die starke Abhängigkeit, und die damit notwendige Kommunikation, zwischen den Teams. Was bei bei 30 Mitarbeiters noch irgendwie machbar war, beginnt nun zu einem echten Problem zu werden. So werden immer mehr Insellösungen durch die Teams entwickelt die global nicht in das Produkt integriert sind und damit keinen Wert bieten.

Andererseits: Würden die Teams nicht auf Insellösungen setzen, müssten sie ständig auf Ergebnisse der andern Teams warten. Ein Dilemma, was immer schlimmer wird mit jedem weiteren neuen Mitarbeiter. Die einzige Lösung ist, die Produkt Architektur so zu schneiden, dass die Teams möglichst wenig gemeinsame Tätigkeiten haben. Da jedes Produkt einmalig ist, ist damit auch seine Organisationsstruktur einmalig.

Die ScrumMaster müssen daher sehr eng mit dem Produkt Owner und den Entwicklern zusammenarbeiten; und immer wieder mit ihnen Experimente durchführen, um neue Erkenntnisse zur Produkt-Architektur und dem Organisationsaufbau zu fördern. Eine Quelle der Inspiration zur globalen Optimierung finden sie in den Leitlinien und Experimenten von Large Scale Scrum (LeSS).

Beispiel: Mittelstand

Im ersten Teil der Serie wurde geschildert wie der Geschäftsführer, und damit einflussreichste Product Owner, das Unternehmens-Backlog aus dem Projekt Portfolio geschaffen und radikal priorisiert hatte. Dies hat er zusammen mit den Area Produkt Ownern erreicht; jeweils Personen aus dem Unternehmen mit hoher Erfahrung und viel Einfluss. Dieser Prozess war alles andere als leicht, und wurde durch die Moderation eines externen Beraters und Coaches erleichtert, der langjährige Erfahrung mit Scrum und agile Praktiken hatte.

Ein ScrumMaster ist ein Coach, der Verantwortung übernimmt 4

Jetzt, wo Fokus hergestellt wurde, wurde klar, dass es am Wichtigsten fehlte: Funktionierende Teams die Fertiges liefern. Zwar gab es an vielen Stellen Teams, die sich gefunden haben und zum Teil Scrum oder Kanban einsetzten oder eingesetzt hatten. Aber diese Teams scheiterten immer wieder mit ihren Verbesserungs-Anforderungen an der bestehenden Organisation. Dem Geschäftsführer wurde klar: es braucht eine langfristig geführte Optimierung der Organisation. Er machte daher dem externen Coach ein Angebot, dass dieser nicht ablehnen konnte: Neuer COO zu werden und genau dafür die Verantwortung zu übernehmen. Er wurde damit der einflussreichste ScrumMaster im Unternehmen.

Als ersten Schritt in seiner neuen Position als COO bildete der ScrumMaster eine cross-funktionale Gruppe aus allen Bereichen und Ebenen des Unternehmens. Zu ihnen gehörten Teammitglieder, ScrumMaster aus den vielen Scrum- & Kanban-Initiativen, aber auch Manager und der CEO. Gemeinsam erstellten sie eine Strategie für die Unternehmens-Transformation, bestehend aus Perfektionszielen und Maßnahmen. Wie alle anderen Großinvestitionen wurden diese in das Unternehmens-Backlog aufgenommen und durch den CEO priorisiert.

Alle Beteiligten war klar, dass nicht die ganze Organisation auf einen Schlag auf Scrum umgestellt werden konnte. Das Risiko, dass ein gut funktionierendes Geschäft durch die Umstellung Schaden nimmt, ist groß. Außerdem muss die Veränderung massiv geführt werden, bis sie endgültig verankert ist. Hier fehlte schlicht die Kapazität an Mitarbeitern mit dem notwendigen Know-How.

Es galt also schrittweise vorzugehen. Da Veränderung immer aus der Notwendigkeit kommt, beschlossen COO und CEO, zwei Projekte konsequent auf Scrum umzustellen, um diese als Leuchttürme für den Organisationswandel zu positionieren. Den anderen Bereichen wurde empfohlen, mit Kanban die momentane Arbeitsweise transparent zu machen, und durch regelmäßige Retrospektiven in kleinen Schritten Verbesserungen einzubringen. Sie erhielten das Angebote zur Unterstützung, zum Beispiel sich jederzeit einen ScrumMaster als Berater und Coach hinzuzuziehen zu können, oder selbst eine Führungskraft als ScrumMaster weiterzubilden.

Die zwei Leuchtturm-Projekte wiesen wesentliche Gemeinsamkeiten auf:

  1. Sie waren aus Unternehmenssicht von hohem strategischem Potential
  2. Es gab sehr viele Unbekannte, was sowohl die Umsetzung und den Markt betraf
  3. Die Entwicklung liess sich vom Rest der Organisation weitgehend entkoppeln

Die 2 Projekte unterschieden sich kaum von dem Beispiel Start-Up. Statt einem CEO des Start-ups gab es einen Area Product Owner. Und natürlich gab es ScrumMaster die gemeinsam mit dem COO das Arbeitssystem weiter optimieren. Die Führungsarbeit als ScrumMaster haben zum Teil mit Personalentwicklung erfahrene Manager übernommen. Zusätzlich wurden Interims-ScrumMaster und Coaches als Wissens-Inkubatoren von extern hinzugezogen.

Das Produkt des ersten Projektes stellte sich nach fünf Monaten als nicht erfolgreich am Markt heraus und die Entwicklung wurde beendet. Die Erfolgsaussichten des zweiten Produktes war dagegen vielversprechend und die Entwicklungsorganisation hatte nach einem Jahr die Größe von mehr als 30 Personen in 4 Teams erreicht. Es ist war nun klar, dass die Projektorganisation dauerhaft ein Entwicklungsbereich bleiben wird. Überhaupt wird der Begriff "Projekt" in diesem Bereich nicht mehr verwendet. In LeSS Huge wird ein solcher Bereich Requirement Area genannt.

Die Erfahrungen aus diesen beiden Projekten werden nun genutzt, um weitere Bereiche umzustellen. Besonders wertvoll ist dabei die Erfahrung aus dem frühzeitig abgebrochenen Projekt. Denn obwohl sich das Produkt als wenig erfolgreich herausgestellt hat, konnte man die Entscheidung zum Abbruch sehr früh treffen, und so ein fortschreitendes Fehlinvestment vermeiden. Darüber hinaus haben die Mitarbeiter sehr viele Erfahrungen über die Arbeit in einer agilen Organisation machen können, die man jetzt in den andern Bereichen nutzen kann.

Die Verantwortung für den Prozess der weiteren Transformation übernehmen die ScrumMaster. Der nächste große Veränderungsschritt in der Produkt-Entwicklung wird LeSS Huge sein. Viele Element sind schon vorhanden, zum Beisiel das zentrale Product Backlog für das gesamte Unternehmen. Stark service-orientierte, im komplizierten angesiedelte Unternehmensbereiche, wie z.B. Produktion, Betrieb oder Buchhaltung, wenden Kanban bzw. Lean-Management-Praktiken in einem Sprint-Rythmus an. Aber auch hier ist jeweils die Führung durch einen oder mehrere ScrumMaster erforderlich. Nur werden diese Führungsrollen dort oft nicht so genannt.

Fazit

Der ScrumMaster führt zu Entscheidungen mit dem Ziel, die Fähigkeit des Arbeitssystems zu verbessern.

Dies erreicht er durch:

  • Organisation global optimieren
  • Teams entwickeln

Agile Leadership ist primär das Handeln mit dem Ziel ein Führungssystem zu etablieren, welches eine Organisation agil macht und diese Fähigkeit erhält. Dies ist originär, was ein ScrumMaster als seine Verantwortung ansieht. Die beiden anderen Rollen in Scrum nutzen diesen Dienst des ScrumMasters, um ihren Führungsaufgaben gerecht zu werden.


Teil 3 der Serie wird aufzeigen, wie die aus agiler Unternehmenssicht wichtigste Rolle führt: Das Team.

Teil 1 - Wie führt der Product OwnerTeil 3 - Wie führt das Team


  1. Diese Aussage ist Teil von Larman's Laws of Organizational Behavior. Ein Model dazu findet sich hier: Wie wird ein Unternehmen agil? ↩︎

  2. Als Definition einer agilen Kultur (oder kurz Agile) gilt das Agile Manifesto. Eine Definition von Prinzipien für das gesamte Unternehmen bieten die Scaled Agile Lead Development Prinzipien (ScALeD)↩︎

  3. Dies ist eine sinngemäße Formulierung von Conway's Law↩︎

  4. Dies war ursprünglich von mir als Gegenprovokation auf die Aussage von Andreas Schliep gedacht: "A ScrumMaster is an Agile Coach Who Isn't There Yet."↩︎

Peter Beck

Über den Autor

Peter Beck

Peter hat es sich zur Aufgabe gemacht Unternehmen zu schaffen, die Wert für ihre Kunden und ihre Mitarbeiter liefern. Das war auch seine Motivation für die Gründung von DasScrumTeam. Peter ist leidenschaftlicher Scrum Trainer (Certified Scrum Trainer, CST) und Berater mit einem soliden Hintergrund im Engineering. Seit 2007 trainiert und coacht er eine große Bandbreite von Entwicklungsteams, Fachabteilungen, Projektleitern und Führungskräften in der Anwendung von Scrum, agilen Planungsmethoden und Softwareengineerings-Praktiken. Peter ist Diplom-Ingenieur für Elektro und Informationstechnik (TU).

  • Erfahrung mit Scrum seit 2004 als Teammitglied, ScrumMaster, Product Owner, Coach und Trainer.
  • Führen von international verteilten Scrum Teams als ScrumMaster
  • Mitgründer und Product Owner der DasScrumTeam AG
  • Besondere Interessen: Agile Unternehmen und Scrum beyond Software