Baue erfolgreiche Systeme und entwickle dein Team – Das ist das Wichtigste, was ein Scrum Master tun sollte.

Einleitung

Die Rolle des Scrum-Masters ist in der Theorie sehr von Prozess-Themen geprägt. Der Scrum-Master soll sich um die Effizienz des Teams kümmern. Das Team und den Scrum-Prozess effizient halten und dem Team und der Organisation dabei helfen den Scrum-Prozess und das agile Mindset besser zu verstehen. In der Theorie wird der Scrum-Master also zum Wächter über den Prozess. Gleichzeitig soll er auch das Team Coachen und dem Team dabei helfen Hindernisse zu beseitigen. All das ist in der Theorie zwar richtig, aber könnte in der Praxis nicht schlechter sein. Das ist vermutlich auch der Grund, warum Scrum-Master in der praxis oft frustriert werden und Scrum-Teams zu Feature-Factroies verkommen. Der Grund für diese Frustration liegt darin, dass der Fokus des Scrum-Masters falsch gelegt wurde und die Theorie in die irre leitet. Der Scrum-Prozess und das agile Mindset sind wichtig, aber kommen erst an zweiter stelle. Zunächst muss ein erfolgreiches System und Team aufgebaut werden.

Begriff Systeme:
Im Folgenden werden mit dem Begriff System alle Personen, Tools, Prozesse und Interaktionen gemeint die eine Organisation oder Organisationseinheit benötigt um einen Job zu erledigen.
Beispiele hierfür ist ein System zur Entwicklung eines Produkts in einem Unternehmen, welches alle Mitarbeiter vom Vertrieb, Marketing, Entwicklung, Support, Operations, bis hin zur Administration mit all ihren Entwicklungstool, Softwaretools und Prozessen bzw. Kommunikationsprozessen umfasst und ein gemeinsames System formen.

Verlierer-Systeme und Teams

Verlierer-Systeme kennzeichnen sich dadurch, dass das Team nicht unabhängig arbeiten kann. Es keine Ende-zu-Ende Verantwortung hat und aktiv von der Organisation des Unternehmens eingeschränkt, und gehindert wird selbstorganisiert und autonom zu arbeiten. Informationen, die das Team eigentlich benötigt, um effizient Wertschöpfung zu betreiben, gehen am Team vorbei oder werden durch Personen vorher abgefangen, gefiltert und verändert und verzögert an das Team weitergegeben. Das Team hat oft nicht die Möglichkeit sich selbst um die Auslieferung der Software/des Produkts zu kümmern, hat keinen Kontakt zum User und auch keine Zugriffsrechte auf benötigte Systeme.

Das Team kann und will auch nicht an automatisierten Systemen wie Test-Automatisierung, Release-Automatisierung und DevOps Themen arbeiten. Dadurch müssen sehr viele Tätigkeiten die eigentlich automatisiert durchgeführt werden können, manuell gemacht werden. Ein wichtiger Faktor Verlier-Systeme zu erkennen ist also auch der Grad der manuellen Tätigkeiten und die fehlende Automatisierung.

Ein weiterer wichtiger Punkt von Verlierer-Systemen ist, dass innerhalb des Systems ebenfalls sehr hohe Abhängigkeiten vorherrschen und sich sehr oft Bottlenecks bilden. Das System blockiert sich also sehr oft selbst. Weiters werden oft lokale Optima erzeugt aus denen globale Nachteile für das System entstehen.

Eigenschaften von Verlierer-Systemen und Teams

• hohe Abhängigkeiten von Systemen und Personen außerhalb des Systems
• viele Engpässe
• lokale Optima
• globale Nachteile
• wenig Automatisierung
• viel manuelle Arbeit
• wenig Autonomie
• keine/geringe Zugriffsrechte
• kein Kontakt zu den Nutzern
• vorgelagerte Filter in der Kommunikation
• keine End-to-End-Verantwortung
• keine/kaum Selbstorganisation
• keine/kaum Werkzeuge zur Optimierung von Arbeit und Kommunikation
• keine/kaum definierte Prozesse
• keine Reflexionen und retrospektive Besprechungen über den Prozess und die tägliche Arbeit/das System

Gewinner-Systeme und Teams

Bei Gewinner-Systemen greifen die einzelnen Systemteile wie Zahnräder ineinander. Das System ist ausbalanciert und autark. Das Team kann in Gewinner-Systemen selbstorganisiert arbeiten und hat alle Informationen und Berechtigungen, die es benötigt und eine Ende-zu-Ende Verantwortung wahrzunehmen und den Job zu erledigen.

Dabei legt das Team Wert darauf möglichst viele Tätigkeiten zu automatisieren und möglichst wenig manuell arbeiten zu müssen. Bottlenecks erkennt das Team bzw. das System selbst und beseitigt den Engpass selbstgesteuert.

Die Kommunikation innerhalb des Systems verläuft direkt und effizient. Es werden keine Filter aufgebaut und alle Informationen werden direkt von demjenigen eingeholt der diese im Job dann auch zur Umsetzung benötigt. Dadurch werden globale Vorteile für das System als Ganzes ermöglicht, und lokale Optima vermieden. Das Umsetzungsteam und die Entscheider im System haben direkten Zugang zu den Usern und können direkt beobachten welche Bedürfnisse die User haben. Gewinner-Systeme setzen auf Automatisierung von Tests, Build- und Release-Automatisierung. Alle Kompetenzen, die das System benötigt, um das Produkt zu bauen, zu releasen und zu warten sind im System enthalten. Es gibt keine Abhängigkeiten zu anderen Teams oder Systemen.

Das Team hat in diesen Systemen zahlreiche Prozesse voll- und teil-automatisierte eingeführt und lebt diese im täglichen Job. Zusätzlich dazu reflektiert das Team regelmäßig ihren Arbeitsalltag und optimiert diese Prozesse. Es werden zahlreiche Tools eingesetzt die den Arbeitsablauf und die Kommunikation vereinfachen und optimieren.

Eigenschaften von Gewinner-Systemen und Teams

• geringe/keine Abhängigkeiten zu Systemen und Personen außerhalb des Systems
• wenige/keine Engpässe
• keine lokalen Optima
• Konzentration auf globale Vorteile
• hoher Grad an Automatisierung
• wenig manuelle Arbeit
• viel Autonomie
• Zugriffsrechte auf benötigte Tools und Systeme
• direkter Kontakt mit den Anwendern
• direkte Kommunikation (keine vorgelagerten Filter in der Kommunikation)
• Ende-zu-Ende-Verantwortung
• hohes Maß an Selbstorganisation
• Werkzeuge zur Optimierung von Arbeit und Kommunikation
• definierte Prozesse
• Regelmäßig stattfindende Reflexions- und Retrospektivbesprechungen über den Prozess und die tägliche Arbeit/das System

Wie kann man erfolgreiche Teams und Systeme aufbauen?

Um ein erfolgreiches System und ein erfolgreiches Team aufzubauen, muss der Scrum-Master zunächst am Mindset des Teams arbeiten. Im Team muss sich ein agiles Mindset etablieren. Um dies verwirklichen kann die Retrospektive verwendet werden. Zusätzlich dazu kann Wissen über agile Methoden und Prozesse sowie agile Produktentwicklung in explizit organisierten zusätzlichen Workshops und Meetings aufgebaut werden. Retrospektiven sollten dazu genutzt werden über sich selbst, das Team und das System zu reflektieren und verbesserungspotenziale bzw. Abhängigkeiten und Bottlenecks zu identifizieren. Werden beispielsweise Bottlenecks oder Abhängigkeiten gefunden, so sollte das Team und der Scrum-Master daran arbeiten diese Schwachstellen im System zu verbessern. Weiters sollten in den Retrospektiven auch Tools und Prozesse berücksichtigt und evaluiert werden. Es kann durchaus sinnvoll sein, Tools einzuführen, um einen höheren grad der Automatisierung zu erreichen.

Ein Beispiel:

Bisher hat das Team Informationen zum User von der Supportabteilung per E-Mail bekommen.

Die Probleme:

Das System ist so aufgebaut, dass der Support nicht teil des agilen Produktteams ist. Das bedeutet der Supportmitarbeiter schirmt den User vom Team ab. Es findet keine direkte Kommunikation zwischen Usern und Team statt. Außerdem wird durch den Support ein Kommunikationsfilter etabliert. Die Informationen werden verkürzt oder verändert in schriftlicher Form an das Team weitergegeben. Die E-Mails kommen mit einer gewissen Zeitverzögerung beim Team an. Da das Team aber in ihren Systemen arbeitet (z.B. in Jira oder MS-Azure-DevOps) checkt es seine E-Mails nur ein bis zweimal Täglich und asynchron. Da die E-Mail an Mailverteiler gesendet werden fühlt sich kein Teammitglied verantwortlich oder Themen werden mehrfach asynchron parallel bearbeitet.

Die Lösung:

Es gibt zahlreiche Lösungen zu diesen Problemen. Im Idealfall schafft es das Team einen Transformationsprozess einzuleiten. Zunächst kann beispielsweise der Support dazu gebracht werden, statt E-Mails zu schreiben richtige Jira-Tickets anzulegen. Das hat den Vorteil, dass das Team diese Tickets im „eigenen“-System hat und somit schneller bemerkt. Gleichzeitig kann das Ticket verfolgt und jemanden Zugewiesen werden. Parallele Bearbeitung wird somit vermieden. Im nächsten Schritt sollte das Team versuchen den Supportmitarbeiter näher ans Team zu holen. Es wäre wünschenswert, wenn der Support mit dem Team direkt telefoniert und Rückfragen schneller klärt. Supportmitarbeiter können mehr und mehr in das Team, die teameigenen Prozesse und Tools und die Entwicklung des Produkts integriert werden. Im letzten Schritt der Transformation kann dann der Support und die Operations durch eine Reorganisation auch wirklich vollkommen ins Team integriert werden und ein DevOps-Prozess gelebt werden, bei dem sich das Team um ein Produkt und die Kunden kümmert.

Einige Probleme innerhalb eines Systems entstehen also auch aufgrund der Aufbau- und Ablauforganisation des Unternehmens. In diesem Fall ist es notwendig die Organisation des Unternehmens zu ändern. Diese Änderungen können meist nicht innerhalb des Teams durchgeführt werden, sondern benötigen Kompetenzen des Managements.

Fazit:

Der Job eines Scrum-Masters ist es also einerseits das Team und das Mindset des Teams aufzubauen und gleichzeitig an der Aufbau und Ablauforganisation des Unternehmens zu arbeiten also am System.