dot.kunden - Wie kann der Scrum Master die Velocity erhöhen?
Die Erwartungshaltung gegenüber Scrum wie auch dem Scrum Master sind oftmals übersteigert. Nicht selten werden Erwartungen enttäuscht. Scrum ist bekanntlich keine "Wunderwaffe", so ist denn auch der Scrum Master selbst keine eierlegende Wollmilchsau. Dennoch möchte ich in diesem Beitrag einige Tipps und Tricks zusammenfassen, wie der Scrum Master die Velocity eines Entwicklungsteams erhöhen kann.
Die Variablen mit dem Causal Loop Diagramm analysieren
Was alles beeinflusst die Velocity? Um das zu analysieren, empfehle ich ein Causal Loop Diagramm oder ein Graph-Modell. Damit kann das gemeinsame Verständnis über die Komplexität dieser Fragestellung veranschaulicht werden. Die Schlüsselerkenntnis für mich ist, dass eine einzelne Massnahme nicht automatisch zu einer nachhaltig höheren Velocity führt, sondern eine für den lokalen Kontext einzigartige Kombination von Massnahmen eingesetzt werden muss.
Hier ein Beispiel einer Analyse eines Kunden.
Ein Beispiel: Rüstzeit reduzieren
Um die Velocity nachhaltig zu steigern, kann man die sogenannte "Rüstzeit" reduzieren. Der Begriff Rüstzeit stammt aus der Produktion und bedeutet gemäss Wikipedia:
Rüsten bezeichnet in der Technik die Tätigkeiten, das Betriebsmittel eines Arbeitssystems (Maschine, Fertigungsstelle, Einzelanlage oder Anlagenstrasse und so weiter) für einen bestimmten Arbeitsvorgang einzurichten, sie beispielsweise mit den notwendigen Werkzeugen (Gussform, Stanzwerkzeug usw.) zu bestücken, sowie die Aktivitäten, das Betriebsmittel wieder in den ungerüsteten Zustand zurückzuversetzen.
In der Softwareentwicklung kann man die Rüstzeit daran messen, wie lange ein Mitglied eines Entwicklungsteams benötigt, um sich in eine bereits bestehende, aber ihm nicht bekannte Funktionalität hineinzudenken, bis er "produktiv" arbeiten, d.h. die Funktion weiterentwickeln und einem Kollegen des Teams übergeben kann.
In vielen (veralteten) Unternehmen können bloss Spezialisten Funktionen bedienen und weiterentwickeln. In diesem Umfeld existiert z. B. kein collective code ownership. Die hohe Rüstzeit begünstigt einen "Heldenkult", dass bloss einzelne Exponenten einzelne Funktionen beherrschen können. Das Entwicklungsteam entspricht dann auch keinem Team, sondern höchstens einer lockeren Bürogemeinschaft, wo jeder für sich werkt.
Ein motiviertes und fähiges Team demgegenüber hat kaum Rüstzeit. Das Wissen ist verteilt, der Code ist sauber und verständlich, die Technologien und Architekturen angemessen gewählt und sinnvoll, die Testabdeckung ausreichend, die Dokumentation unterstützend. So idealisiere ich ein performantes Entwicklungsteam, das natürlich aus ehemals unterschiedlichen IT-Disziplinen bestückt ist, aber mittlerweile sich angenähert hat.
Wenn ein Team einen solchen Zustand hat, kann die Velocity bloss noch mit handwerklichem Können optimiert werden. Hier können neue Frameworks, Tools, aber auch neuartige Kommunikationsformen oder Automatisierungen hinsichtlich Analyse & Design (z. B. Modellierung), Implementation (z. B. mittels Generatoren), Testing, Requirements (z. B. Code == Dokumentation) und Deployment (z. B. Pipelines) Velocity-Gewinne versprechen. Doch das bedingt ein stabiles Team mit möglichst geringer Rüstzeit.
Wie kann eine möglichst geringe Rüstzeit erreicht werden?
"Veraltete" Teams empfinden eine geringe Rüstzeit entweder nicht als erstrebenswert aufgrund der Bequemlichkeit der individuellen Arbeitseinteilung oder als nicht umsetzbar aufgrund der bereits riesigen technischen Schulden der letzten Jahrzehnte.
Die individuelle Arbeitseinteilung ist gewiss verlockend; man ist von niemandem abhängig, muss mit niemandem kommunizieren, man kann sich die Arbeit selbst einteilen und organisieren. Warum also plötzlich teilen, wenn es doch alleine und irgendwie auch gut geht? Ebenso sind die technischen Schulden stets im Bewusstsein und verhindern jedwede Innovation. Man kann schliesslich auf die historischen und heroischen Leistungen verweisen und sich damit begnügen, es bereits immer irgendwie geschafft zu haben.
Wenn das Team keine kürzere Rüstzeit will, muss der Scrum Master das Team zunächst begeistern. Das kann er bloss mit intensiven Einzelgesprächen, Gruppenarbeiten und etlichen Retrospektiven bewältigen. Es ist sinnlos, mit einem Team zu arbeiten, das nicht will. Sobald diese Voraussetzung geschaffen ist, kann der Scrum Master starten.
Sofort umsetzen: Stabile Teams
Eine implizite Annahme, die ich nun auch gerne explizitisieren möchte. Aufgaben werden Teams zugeteilt und nicht Teams werden nach Aufgaben gebildet. Ein kleiner, aber bedeutender Unterschied. Egal, wie gross, wichtig oder kritisch ein Vorhaben (meistens implementiert als Projekt) ist, die Teams bleiben Teams und sind stabil.
Sofort umsetzen: Aufgaben-Rotation
Wie bereits in der Sanierungsvariante für veraltete Unternehmen angekündigt, muss das Team das gemeinsame Verständnis der gemeinsamen Komplexität erhöhen. Das kann sofort mit einer radikalen Aufgaben-Rotation umgesetzt werden. Jeder muss machen, was er nicht kann. Keine Aufgabe, kein Mitglied wird geschont. Die Massnahme muss für mindestens zwei Sprints hintereinander geplant werden. Die üblichen Bedenken wie Stabilität, Qualität oder Projektdruck werden notiert, aber nicht erörtert.
Sofort umsetzen: Grundlagen-Ausbildung
Alle notwendigen (IT-)Disziplinen, die für die Herstellung eines Produktinkrements notwendig sind, werden in einer Basis-Stufe fürs gesamte Team ausgebildet. Diese Kurse sollen mindestens zwei, maximal vier Tage dauern. So werden ein gemeinsames Verständnis und eine gewisse Professionalität ermöglicht; der gemeinsame "Startpunkt" für die gemeinsame Verbesserung des handwerklichen Könnens.
Sofort umsetzen: Laufzeit-Dokumentation
Alle Aufgaben, insbesondere angesichts der Aufgaben-Rotation, müssen dokumentiert werden. Wie man einen Server neu startet? Dokumentieren! Wie man ein Dokumenten-Mapping ergänzt? Dokumentieren. Welche Stakeholder beim Refinement involviert werden müssen? Dokumentieren. Wie man einen Hotfix installiert? Dokumentieren. Das Wissen muss explizit und während der "Laufzeit" aktualisiert werden. Für zukünftige Anfragen gilt dann im Team RTFM. Das verringert die Rüstzeit massivst.
Sofort umsetzen: Team-Grösse verkleinern
Mit geschäftspolitischen Kompromissen geschnittene Teams sind meistens zu gross. Sie umfassen neun bis elf Personen. Darin kann jeder sich verstecken - oder als Einzelkämpfer seinen Heldenstatus wahren. Effektive und effiziente Entwicklungsteam sind gemäss meiner Erfahrung maximal sechs Personen gross. Denn dann wissen wirklich alle über alles Bescheid und fungieren und fühlen sich als echtes Team statt als unverbindliche Gemeinschaft - und zwar ohne Kommunikationsüberflutung.
Einfluss auf die Rüstzeit
All diese Sofort-Massnahmen verkürzen die Rüstzeit. Kleinere, mit gleicher Basisausbildung befähigte Teams, die alle Aufgaben dokumentiert haben, können sich problemlos in die Aufgaben ihrer Team-Kollegen hineinversetzen und haben geringe Schwierigkeiten, sich in komplett neue Aufgaben einzuarbeiten. Diese Teams werden performen. Die Velocity wird sich kontinuierlich vergrössern.
Fazit
Der Scrum Master ist also nicht ganz machtlos. Er kann mit kleinen, aber wirkungsvollen Massnahmen durchaus die Velocity erhöhen. Der Scrum Master muss allerdings auch die Kompetenzen haben, die ihm zugewiesene Rolle innerhalb der Organisation ausüben zu dürfen. Ich beobachte leider oft, dass der Scrum Master "kastriert" ist, also beispielsweise nicht zusammen mit dem Team die Teamgrösse justieren kann, sondern stets von der Rolle des Managements abhängt. Der Scrum Master muss hier einen wichtigen Scrum-Wert "Mut" beweisen und bewusst seine zugewiesenen "Kompetenzen" überschreiten. Scrum verlangt, dass die Scrum-Rollen über sich selber hinauswachsen.
Wir befähigen gerne Scrum Master, mutiger in der Organisation zu wirken.
Eventuell interessant
Verwandte Blogs
Keine Kommentare
Teile deine Meinung