Als Scrum Master bin ich ständig auf der Suche nach Werkzeugen, die meine Arbeit effektiver machen.
Auf dieser Suche stieß ich kürzlich auf „Dysfunctional Mapping“ von Michael Lloyd. Hier sind drei Erkenntnisse, die mir der Besuch seines „Dysfunctional Mapping“-Workshops gebracht hat:
Erkenntnis 1: Unterscheide zwischen Beobachtungen, Gesprächen und Fragen
Im Jahr 2019 übernahm ich die Rolle des Scrum Masters in einem Team.
Wie ich vorgegangen bin, um das Team bei der Arbeit mit Scrum zu unterstützen, habe ich in der Fallstudie „Wie du als Scrum Master mit einem neuen Team beginnst“ dargelegt.
Ein „Werkzeug“, das ich dabei verwendete, war der Scrum Guide. Ich beobachtete das Team bei seiner täglichen Arbeit und notierte mögliche Abweichungen von den Regeln und Empfehlungen des Scrum Guides.
Hier einige Gedanken, die mir durch den Kopf gingen:
- Werden Scrum Events übersprungen?
- Findet das Product Backlog Refinement statt?
- Das Sprint Review ähnelt eher einer Demonstration von Features, doch es gibt kein Feedback von Kunden.
- Dem Team fehlen Fähigkeiten, um ein nutzbares Inkrement zu erstellen.
- Der Stakeholder Tom berichtete, dass er nie wisse, woran das Team eigentlich arbeite. Von der Geschäftsleitung habe er gehört, dass die Teammitglieder an der Entwicklung eines neuen Produkts arbeiten.
- Das Team spricht nie über die Definition of Done.
- Worüber beschweren sich Teammitglieder und Stakeholder?
Beim Lesen dieser Liste wird sofort deutlich, dass ich Fragen, Gespräche und Beobachtungen vermische. Was fehlt, ist eine Struktur.
Warum ist die fehlende Struktur ein Problem für die Arbeit des Scrum Masters?
Dies werde ich dir gleich erklären. Zunächst brauchen wir eine Struktur. Michael Lloyd hat mir hierfür im Workshop einen Ansatz gezeigt.
Er unterscheidet diese drei Kategorien:
- Fragen: Welche Fragen sollten wir auf Basis der Regeln und Empfehlungen des Scrum Guides stellen?
- Beobachtungen: Was beobachten wir in der täglichen Arbeit des Teams und der Zusammenarbeit mit den Stakeholdern?
- Gespräche: Über welche Probleme oder Herausforderungen berichten uns die Teammitglieder und die Stakeholder des Produkts?
Diese Unterscheidung hilft uns, einen ausgewogenen Blick auf die Situation zu bewahren. Sie setzt Abweichungen von den Regeln und Empfehlungen des Scrum Guides, Beobachtungen zur Zusammenarbeit und Erfahrungsberichte von Mitgliedern des Scrum Teams in Relation.
Dieses ausgewogene Verhältnis ist wichtig. Es bringt uns zurück zur Frage: Welche Probleme entstehen, wenn diese Struktur fehlt?
Um die Probleme zu erkennen, genügt es, die Extrema zu betrachten. Hier zwei Beispiele:
- Protokollieren wir nur Abweichungen von den Regeln und Empfehlungen des Scrum Guides, besteht die Gefahr, dass wir Scrum nur um seiner selbst willen anwenden. Als Scrum Master verkommen wir dann zur Scrum Polizei.
- Protokollieren wir nur Beobachtungen, besteht die Gefahr, dass wir die individuellen Bedürfnisse und Gründe hinter dem Verhalten der Menschen im Team nicht verstehen. Als Scrum Master verkommen wir dann zum Mechaniker. Wir wenden Scrum mechanisch an, ohne uns auf die Scrum Werte zu stützen.
- Protokollieren wir nur Probleme, die uns die Teammitglieder berichten, besteht die Gefahr, dass wir uns nur um die Befindlichkeiten Einzelner im Team kümmern. Als Scrum Master verkommen wir dann zum „Feel-good-Manager“ des Teams.
Wie du siehst, hilft uns die Einteilung in Fragen, Gespräche und Beobachtungen, ein ausgewogenes Verhältnis zu wahren und somit nicht in eine der Fehlhaltungen „Scrum Polizei“, „Mechaniker“ oder „Feel-good-Manager“ zu verfallen.
Erkenntnis 2: Unterscheidung zwischen Symptomen und Dysfunktionen
Eine meiner Lieblingsepisoden von Dr. House ist „Drei Beine“.
Die Episode spielt im Hörsaal des Princeton-Plainsboro Teaching Hospitals. In einem Vortrag vor Medizinstudenten präsentiert Dr. House drei Fälle.
Alle Patienten berichten über Schmerzen im Bein:
- Patient 1: Ein Bauer repariert seinen Zaun, als plötzlich ein stechender Schmerz durch sein Bein schießt und er die Kontrolle über sein Bein verliert.
- Patient 2: Er war beim Volleyballtraining und verletzte sich. Der Coach vermutet eine Zerrung im Oberschenkel.
- Patient 3: Er leidet an unerklärlich starken Schmerzen im Oberschenkel.
Im Verlauf der Episode führt House die Studenten (und die Zuschauer) durch den diagnostischen Prozess, wobei er die Wichtigkeit betont, über den Tellerrand zu blicken und nicht bei offensichtlichen Antworten stehen zu bleiben. Er zeigt, wie ähnliche Symptome zu völlig unterschiedlichen Diagnosen führen können.
In der Medizin unterscheiden wir zwischen Symptomen und Krankheiten.
Ein Symptom ist eine subjektive Beschwerde oder ein objektives Zeichen, das vom Patienten wahrgenommen wird. Beispiele sind Schmerzen, Übelkeit, Fieber oder Schwindel. Eine Krankheit ist eine medizinisch definierte Störung, die durch spezifische Ursachen charakterisiert ist und eine bekannte Reihe von Symptomen aufweist. Eine Krankheit ist somit eine Diagnose. Krankheiten haben oft eine definierte Behandlung, die ihre Ursache bekämpft und die Symptome lindert.
Worauf will ich hinaus? Die Unterscheidung zwischen Symptomen und Krankheiten hilft Ärzten, eine zielgerichtete Behandlung zu entwickeln. Also Behandlungsstrategien, die nicht nur die Symptome lindern, sondern auch die Krankheit an ihrer Wurzel bekämpfen.
Das gleiche Vorgehen nutzen wir auch beim „Dysfunctional Mapping“.
Das bedeutet: Wir unterscheiden zwischen Symptomen und Dysfunktionen.
Mit Symptomen meinen wir die negativen Ergebnisse oder die Frustrationen.
Hier einige Beispiele für Symptome:
- Arbeit dauert immer länger als geplant.
- Konflikte zwischen Teammitgliedern
- Unzufriedenheit bei Kunden
- Schlechte Produktqualität
Und mit Dysfunktionen bezeichnen wir die Scrum Praktiken, die nicht genutzt oder falsch angewendet werden.
Hier einige Beispiele für Dysfunktionen:
- Es wird kein Sprint-Ziel definiert.
- Es gibt mehrere Product Owner.
- Der Product Owner schätzt den Umfang der Einträge im Product Backlog.
- UX-Designer sind nicht Teil des Scrum Teams.
Diese Unterscheidung ermöglicht es Scrum Mastern, zielgerichtete Behandlungsstrategien zu entwickeln, die nicht nur die Symptome lindern, sondern auch die Dysfunktionen angehen.
Aber da ist noch mehr:
Erkenntnis 3: Dysfunktionen helfen, die Notwendigkeit von Verbesserungen zu erklären
Wie lassen sich Dysfunktionen beseitigen?
Unerfahrene Scrum Master verweisen oft auf den Scrum Guide und versuchen, mit solchen Aussagen zu überzeugen: Im Scrum Guide steht, …
- … dass Scrum Teams ein Ziel für den Sprint definieren müssen.
- … dass der Product Owner im Sprint Planning anwesend sein muss.
- … dass es nur einen Product Backlog geben darf.
Aus meiner Erfahrung überzeugt das jedoch niemanden. Diese Lektion musste ich selbst vor einigen Jahren lernen.
Zu Beginn des Sprint Plannings bat ich die Entwickler, dem Team mitzuteilen, wie viel sie in diesem Sprint unterstützen könnten. Ich war es gewohnt, dass, abgesehen von dem einen oder anderen Urlaubstag, die Entwickler dem Team hundertprozentig zur Verfügung stehen. Nicht so in dieser Situation. Kein Entwickler stand dem Team vollständig zur Verfügung. Die meisten arbeiteten gleichzeitig an drei Projekten und waren nur zu 30 % bis 50 % verfügbar.
Mein anschließendes Gespräch mit dem zuständigen Team- und Projektleiter verbesserte die Situation nicht. Ich konnte beide nicht davon überzeugen, dass der Scrum Wert „Fokus“ für das Scrum Team höchste Priorität hat und dass dieser im Moment nicht gelebt wird.
Was ist also die Lösung?
Laut Michael Lloyd liegt der Schlüssel in der Dysfunktion.
Wenn wir die Dysfunktion mit einem „Warum“ kombinieren, erhalten wir den wahren Zweck. Dieser Zweck zeigt uns den Wert, den wir durch die Behebung der Dysfunktion gewinnen. Betrachten wir, was mit dem Beispiel der Dysfunktion passiert, wenn wir es um das dahinterstehende Warum ergänzen:
- Warum sollte das Scrum Team ein Ziel für den Sprint definieren? Ein Ziel für den Sprint ermöglicht den Teammitgliedern, das Wesentliche im Auge zu behalten. Sollte sich das Team im Sprint nicht auf die dringlichen Probleme der Kunden konzentrieren und unnötige Tätigkeiten vermeiden?
- Warum sollte der Product Owner im Sprint Planning anwesend sein? Der Product Owner repräsentiert die Interessen des Kunden. Sollte sich die Planung des Sprints nicht an den Kundenwünschen orientieren?
- Warum darf es in Scrum nur einen Product Backlog geben? Ein einziger Product Backlog hilft dem Team, sich nicht auf mehrere Dinge gleichzeitig zu konzentrieren, sondern auf die wertvollste Arbeit.
Michael Lloyd hat recht. Anstatt zu argumentieren, dass der Scrum Wert „Fokus“ verletzt ist, hätte ich die Projektleiter vielleicht eher zum Umdenken bewegen können, indem ich ihnen das „Warum“ hinter dem Scrum Wert „Fokus“ aufgezeigt hätte.
Ich denke, „Dysfunctional Mapping“ ist ein hilfreiches Werkzeug in jedem Werkzeugkasten eines Scrum Masters. Selbst erfahrene Scrum Master können noch viele neue Erkenntnisse für ihre Arbeit gewinnen. Wenn du mehr darüber erfahren willst, dann findest du hier das Webinar von Michael Lloyd, welches er im „Hands-on“-Agile-Meet-up von Stefan Wolpers gehalten hat.