Was machst du als Scrum Master, wenn du neu in einem Team bist?
Ich stelle die Frage vielen Scrum Mastern – auch mir selbst. Es interessiert mich, zu erfahren, wie andere Scrum Master arbeiten, denken und ticken. Die drei häufigsten Antworten lauten: 1:1-Meetings mit jedem Mitglied im Team führen, dafür sorgen, dass alle Scrum Meetings stattfinden, und das Team bei der Zusammenarbeit beobachten.
Für die ersten 90 Tage im Team mögen diese Aktivitäten ausreichen.
Willst du allerdings darüber hinaus Erfolg als Scrum Master haben, dann genügt es nicht nur, den Scrum Prozess zu verbessern. Du solltest dich auch der Wertschöpfung, den Organisationsstrukturen und den Teamdynamiken widmen, um verborgene Hindernisse zu erkennen.
Für mich haben sich diese 7 Fragen bewährt, um Hindernisse aufzuspüren:
Frage #1: Was ist der Auftrag des Teams aus Team- und aus Managementsicht?
Lass mich dir ein Geheimnis anvertrauen:
Einfach eine Gruppe von Menschen in einen Raum zu werfen und zu sagen: „Ihr seid ein Team, leistet Großartiges“, wird nicht funktionieren. Aber wahrscheinlich kennst du das Geheimnis bereits.
Erfolgreiche Teams gleichen einem lebendigen Organismus. Sie bilden über die Zeit eine eigene Identität. Die Grundlage zur Bildung einer Identität kannst du schaffen, indem du deinem Team diese drei Fragen stellst:
- Warum gibt es uns?
- Was ist für uns wichtig?
- Was wollen wir gemeinsam erreichen?
Eine Identität ist allerdings nicht genug, um langfristig im Unternehmen Erfolg zu haben.
Denn Erfolg wird wahrscheinlich nicht vom Team gemessen, sondern vom Management.
Deshalb vergiss niemals zu fragen:
Was erwartet das Management von unserem Team?
Frage #2: Was definiert Wert für das Produkt?
Was zeichnet erfolgreiche Produktentwicklung am Ende immer aus?
Es ist eine Win-win-Situation für Nutzer, Kunden und Unternehmen. Nicht mehr, aber auch nicht weniger. Warum nicht weniger? Stell dir ein Produkt vor, dessen Nutzer nicht zufrieden sind. Stell dir ein Produkt vor, mit dem das Unternehmen langfristig keinen Umsatz erwirtschaftet. Nun Hand aufs Herz: Wie erfolgreich ist diese Entwicklung wirklich?
Diese Win-win-Situation bezeichnen wir in Scrum als „Wert“.
Willst du deinem Team als Scrum Master helfen, dann hilf ihm zu verstehen, wie diese Win-win-Situation konkret aussieht. Stell dir deshalb die Frage:
Was definiert Wert für unser Produkt?
Frage #3: Wie transparent sind Informationen für fundierte Entscheidungen?
In Scrum gibt es drei Artefakte.
Alle Scrum Master wissen, dass es sich um das Sprint-Backlog, Product-Backlog und Produkt-Inkrement handelt. Einige Scrum Master wissen auch, dass diese Artefakte jeden Zeithorizont des Teams abdecken. Was meine ich damit? Das Product-Backlog beschreibt die Zukunft, das Sprint-Backlog die Gegenwart und das fertige Inkrement beschreibt die Vergangenheit. Wenige Scrum Master wissen aber, dass der Erfolg von Scrum wesentlich von der Transparenz dieser Artefakte abhängt. Diese Artefakte beschreiben jeden Wert oder jede Arbeit und sind somit die Grundlage für Entscheidungen. Anders ausgedrückt:
Je weniger transparent diese Artefakte sind, desto schlechter können Entscheidungen getroffen werden.
Dies erkennst du daran, dass es ewig dauert, bis etwas entschieden wird. Langsame Entscheidungsfindung ist Gift für Agilität. Agilität bedeutet ja gerade, schnell auf Veränderungen zu reagieren, und dafür sind schnelle Entscheidungen die Grundlage. Deshalb gibt es in Scrum die Verantwortung des Product-Owners. Eine Person kann schneller entscheiden als ein Gremium.
Also: Willst du die Agilität des Unternehmens langfristig verbessern, stelle dir die Frage:
„Wie transparent sind Informationen, um wichtige Entscheidungen zu treffen?“
Frage #4: Wie agil ist das Team wirklich?
Wie lautet die eine Metrik, um Agilität zu messen?
Natürlich war das nur eine Fangfrage. Die eine Metrik gibt es nicht. Allerdings gibt es Metriken, die Agilität besser beschreiben als andere. Eine Metrik, auf die ich als Scrum Master nie verzichten würde, ist die Cycle-Time.
Die Zykluszeit ist die Zeit, die das Scrum Team benötigt, um einen Eintrag des Product-Backlogs durch den gesamten Entwicklungsprozess zu bringen. Wir messen hier also, wie lange zum Beispiel ein Feature oder ein Bugfix vom Start der Bearbeitung bis zur Fertigstellung braucht.
Es gibt auch eine Kennzahl dafür, was eine gute Zykluszeit ist und was nicht. Der Scrum Guide nennt explizit die Länge eines Sprints. Soll heißen: Wenn dein Team länger als 30 Tage braucht, um Product-Backlog-Einträge fertigzustellen, besteht Handlungsbedarf.
Ich würde sogar noch einen Schritt weiter gehen:
Die allgemeine Erwartung, wie lange ein Sprint dauern darf, ist 2 Wochen. Somit ist die Kennzahl, an der du dich orientieren solltest, 2 Wochen, und die Frage, die du dir stellen kannst, lautet:
„Ist unser Team agil genug, um in weniger als 2 Wochen neue Software zu liefern?“
Was uns zur nächsten Frage führt:
Frage #5: Was hindert das Team daran, schneller zu liefern und zu lernen?
Was hindert Teams daran, in weniger als 2 Wochen neue Software zu liefern?
Hier einige der gängigen Hindernisse, die ich in den letzten 10 Jahren immer wieder gefunden habe:
- Multitasking: Mitglieder im Team arbeiten an vielen Dingen gleichzeitig.
- Abhängigkeiten: zu viele Abhängigkeiten zwischen den Einträgen im Product-Backlog oder zu anderen Teams.
- Engpässe bei Fähigkeiten: Ständig fehlen Fähigkeiten im Team, um die Arbeit wirklich fertigzustellen.
- Technische Schulden: Bevor Neues entwickelt werden kann, müssen erst einmal Altlasten beseitigt werden.
- Kein Feedback: Keine Reviews mit Kunden und Stakeholdern, um wirkliches Feedback auf das Produkt zu erhalten.
- Kein Ziel: Kein gemeinsames Ziel im Sprint oder das Team ist einfach kein echtes Team.
Nutze meine Erkenntnisse, um passende Fragen für dich zu formulieren, denen du nachgehen kannst.
Zum Beispiel:
„Unser Team entwickelt Tools, Services und Prozesse für andere Teams. Wer sind die Stakeholder und wie bekommen wir frühzeitig Feedback auf unsere Arbeit?“
Frage #6: Wie professionell erfolgt Softwareentwicklung?
Es gibt heute zwei Arten, Software zu entwickeln:
Die eine zeichnet sich dadurch aus, dass das Team
- bei einer kleinen Änderung am Code die ganze Software neu kompilieren muss,
- die Software im Keller auf einem physischen Server hostet,
- Tests manuell durchführt und
- beim Deployment alle Schritte manuell macht.
Die andere Art zeichnet sich dadurch aus, dass das Team
- die Software als Sammlung kleiner, unabhängiger Dienste gestaltet, die jeweils eine spezifische Geschäftslogik abdecken,
- alles von der Code-Integration bis zur Bereitstellung automatisiert hat und auf Produktionsservern hostet,
- hoch spezifizierte Konfigurationsdateien verwendet, um die Infrastruktur automatisiert zu verwalten und somit jederzeit skalieren zu können.
Ich lehne mich jetzt mal weit aus dem Fenster und behaupte, dass die erste Art keine Zukunft mehr hat.
Die zweite Art ist das, was heutzutage als professionelle Softwareentwicklung bezeichnet wird. Welche Frage solltest du dir und deinem Team stellen, um zu erkennen, wie professionell ihr bereits Software entwickelt?
Aus meiner Erfahrung macht es nur bedingt Sinn, direkt nach speziellen Entwicklungspraktiken Ausschau zu halten. Die passenden Praktiken hängen vom Kontext ab. Deshalb stelle dir lieber Fragen zur Auswirkung der genutzten Praktiken.
Hierfür stelle ich mir diese Fragen:
- Wie oft stellt das Team neue Software-Versionen bereit?
- Wie viel Zeit vergeht vom Code-Commit bis zum erfolgreichen Deployment?
- Wie rasch reagiert das Team auf Störungen und wie lange dauert es, bis wieder der Normalbetrieb herrscht?
- Wie häufig müssen Deployments zurückgerollt werden oder führen zu schwerwiegenden Problemen in der Produktion?
Frage #7: Wie steht es um die psychologische Sicherheit im Team?
Wenn es um Retrospektiven geht, machen sich viele Scrum Master die falschen Gedanken.
Sie stellen sich die Fragen:
- Welches Format sollte ich für die Retrospektive nutzen, damit jeder begeistert mitmacht?
- Was mache ich, wenn ich wieder keinen Meetingraum für unsere Onsite-Retrospektive bekommen habe?
- Wie bringe ich mehr Abwechslung in die Retrospektive?
Versteh mich nicht falsch: Diese Fragen sind wichtig. Allerdings sollten wir eines nicht vergessen: Am Ende geht es bei Retrospektiven nicht um das Format, sondern um das Ergebnis. Und das Ergebnis hängt von einer Sache ab:
psychologischer Sicherheit.
Hierüber ist sich die Forschung mittlerweile einig. Zum Beispiel hat eine Umfrage unter 236 Mitgliedern von 43 Software-Teams ergeben, dass Teams mit hoher psychologischer Sicherheit signifikant häufiger reflektieren, Verbesserungen umsetzen und insgesamt besser performen. Soll heißen: Psychologische Sicherheit wirkte hier sowohl indirekt über die Reflexionsfähigkeit als auch direkt positiv auf die Teamleistung.
Willst du als Scrum Master dafür sorgen, dass sich die Reflexionsfähigkeit langfristig weiterentwickelt – also über die ersten 90 Tage hinaus – und somit auch langfristig die Teamleistung steigt, dann stell dir unbedingt diese Frage:
„Wie steht es um die psychologische Sicherheit im Team?“
Diese 7 Fragen haben mir in der Vergangenheit geholfen, nicht nur Hindernisse im Scrum Prozess zu entlarven, sondern auch in der Wertschöpfung, den Organisationsstrukturen und Teamdynamiken.
Suchst du nach konkreten Werkzeugen und Methoden, um diese Hindernisse auch zu beheben?
Dann empfehle ich dir das „Professional Scrum Master – Advanced“-Training.
Dort lernst du,
- wie du die Definition-of-Done nutzt, um Risiken in der Softwareentwicklung frühzeitig zu finden,
- Strategien, die Product-Ownern in jeder erdenklichen Misslage helfen werden,
- ein Vorgehen, wie du strukturiert mit jedem Stakeholder Gespräche über Veränderung führst,
- mit welchen Metriken du den Erfolg deines Teams quantifizieren kannst
- und noch viel mehr.
Neugierig, wie das Training abläuft? Dann wirf doch einen Blick hierauf:
Über 271 Scrum Master sind meiner Empfehlung bereits gefolgt, vielleicht lernen wir uns ja auch bald persönlich im Training kennen? Marc und ich freuen uns schon.
Bis dahin... Scrum on.