„Wir machen Scrum, aber …“
Dieses Phänomen ist natürlich nicht neu. Ich glaube, es war Gunther Verheyen, der ihm seinen Namen gab. Gemeint sind Teams, die Scrum – irgendwie – machen, aber kritische Regeln nicht befolgen. Und das Problem ist hierbei nicht, dass sie „die Regeln nicht befolgen“, wie dir vielleicht oftmals weisgemacht wird. Meist von Personen, die ich „liebevoll“ als die Scrum-Polizei betitle. Häufig sind es Projektleiter oder Prozessberater, die den Erfolg von Teams als garantiert ansehen, wenn das Team nur den Regeln folgt.
Nichts könnte ferner von der Wahrheit sein.
Das Problem, wenn wir Verkehrsregeln nicht beachten, ist ja nicht, dass wir die Regeln nicht beachten, sondern dass wir uns und andere in ernsthafte Gefahr bringen. So verhält es sich auch mit Scrum. Von diesen Auswirkungen will ich dir heute berichten.
Los geht es mit meinem Lieblings-„Scrum, aber …“:
„Scrum, aber …“ #1: Wir haben keinen Scrum Master.
Ich unterstütze seit einigen Jahren einen Kunden mit Scrum-Trainings.
Mehrmals im Jahr führe ich das beste Training durch, das die Scrum.org zu bieten hat und kaum jemand kennt. Die Rede ist vom „Applying Professional Scrum“-Training. Und seit Jahren höre ich von den Teilnehmern, dass sie Scrum machen, aber keinen Scrum Master im Team haben. Diesem „Scrum, aber …“ begegne ich aber auch bei etablierten Teams. Dort ist der Scrum Master die erste Person, die nicht mehr im Team gebraucht wird. (Zum Großteil sind daran Scrum Master selbst schuld, die ihre Aufgabe darin sehen, sich überflüssig zu machen.)
Aber was ist das ursprüngliche Problem, wenn Teams keinen Scrum Master haben?
Wenn das Herz von Scrum aussetzt, wer soll es dann reanimieren? Mit dem Herz meine ich die empirische Prozesssteuerung. Oder in einfacher Sprache: den Mut zu haben, jeden Sprint zu liefern, sich das Feedback der Kunden anzutun und es daraufhin besser zu machen.
Ein Sprint mag okay sein, aber wir sollten nicht vergessen: Menschen sind bequem. Und dann werden schnell aus einem Sprint mehrere Sprints – und, schwups, ist ein halbes Jahr ohne Kundenkontakt vergangen. Team und Kunden entfernen sich immer weiter voneinander.
Aber ist nicht das Versprechen von Agilität, die sich Unternehmen von Scrum erhoffen, enger Kundenkontakt, um Veränderungen als Wettbewerbsvorteil nutzen zu können?
Was uns direkt zum nächsten „Scrum, aber …“ bringt:
„Scrum, aber …“ #2: Wir machen keine Retrospektiven.
Dieses „Scrum, aber …“ ist eine direkte Folge von: „Wir machen Scrum, haben aber keinen Scrum Master.“
Ich kann mir keine Welt vorstellen, in der Teams einen Scrum Master haben und trotzdem keine Retrospektiven am Ende des Sprints machen. Du?
Das Problem, keine Retrospektiven zu machen, offenbart aus meiner Sicht ein viel grundlegenderes Problem.
Es gibt zwei Arten, an Probleme heranzugehen:
- Wir glauben, um erfolgreich zu sein, braucht es Stabilität und Routine. Diese erreichen wir, indem wir Regeln befolgen und auf Expertenanalysen vertrauen. Am Ende entscheidet unser Fachwissen darüber, wie gut wir ein Problem lösen. Für die Lösung eines kniffligen technischen Problems mag die Befragung von Experten und die Analyse von Protokollen ausreichen, um den Bug zu fixen.
- Wir glauben, dass Fachwissen wertvoll ist, – um erfolgreich zu sein, braucht es allerdings den Mut zum Lernen und zur ständigen Anpassung an neue Umstände. Diese Art des Vorgehens nutzen wir, wenn wir mit verschiedenen Funktionen experimentieren, um auf Grundlage von Nutzerfeedback mit A/B-Tests neue Produktideen zu validieren.
Scrum ist gemacht, um die zweite Art von Problemen zu lösen.
Und ich behaupte jetzt: Wir Menschen – zumindest ich – setzen alles daran, unsere tägliche Arbeit als Problem der ersten Art zu sehen. Routinen zu folgen, bewährtes Vorgehen anzuwenden und die Anhäufung von Wissen fühlen sich sicher an. Diese Komfortzone zu verlassen – dafür ist die Retrospektive gedacht. Sie hilft Teams, neue Realitäten zu erkennen, ihre Routinen zu hinterfragen und Neues zu wagen.
Und genau da liegt das Problem:
Wenn Teams auf Retrospektiven verzichten, verzichten sie auf das wichtigste Werkzeug, um aus der Komfortzone auszubrechen. Sie verzichten auf die Chance, regelmäßig innezuhalten, blinde Flecken sichtbar zu machen und gemeinsam besser zu werden.
Ohne Retrospektive bleibt alles, wie es ist – selbst wenn es nicht funktioniert.
Scrum wird dann zur Fassade. Und das ist fatal. Denn das Versprechen von Scrum ist nicht, dass es keine Probleme mehr gibt. Sondern dass Teams regelmäßig ihre Probleme erkennen und lösen können. Ken Schwaber beschreibt Scrum gerne als Schwiegermutter. Sie zeigt dir all deine Probleme auf, lösen musst du sie allerdings selbst.
Und diese Schwiegermutter fehlt Teams ohne Retrospektiven.
Was uns zum letzten „Scrum, aber …“ für heute bringt:
„Scrum, aber …“ #3: Wir haben einen Product-Owner, aber …
Im „Professional Scrum Master – Advanced“-Training geben wir den Scrum Mastern zwei Werkzeuge an die Hand.
Zum einen zeigen wir ihnen, wie sie mittels Verbesserung der Definition-of-Done ihrem Unternehmen helfen, das Risiko in der Entwicklung von Produkten zu reduzieren.
Den Inhalt auf den Punkt gebracht: Je besser die Definition-of-Done wirklich beschreibt: „Software wird vom Kunden genutzt“, desto weniger ungeahnte Probleme können noch auftreten.
Du findest es in diesem Bild noch einmal veranschaulicht:
Zum anderen zeigen wir ihnen ein Werkzeug, das das Spannungsfeld aufzeigt, in dem sich viele Product-Owner befinden. Was meine ich, wenn ich von einem Spannungsfeld spreche? Rufen wir uns hierzu die Beschreibung der „Product-Owner-Verantwortung“ aus dem Scrum Guide ins Gedächtnis:
„Der Product-Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.“
Das Spannungsfeld steckt in den Worten „Maximierung des Wertes des Produkts“, denn dazu sind zwei Dinge nötig:
- die Entscheidung zu treffen, dass eine neue Version des Produkts released wird,
- die Entscheidung zu treffen, was ins Product-Backlog kommt und was nicht.
Wenn diese zwei Dinge nicht vollumfänglich in den Händen des Product-Owners liegen, ist seine Verantwortung zur „Maximierung des Wertes des Produkts“ eingeschränkt.
Stell dir einen Product-Owner vor, der nur Kontrolle über den Release-Prozess hat, aber keine Kontrolle über das Product-Backlog. Ich würde ihn als „Delivery Manager“ bezeichnen. Und ein Product-Owner, der nur Kontrolle über den Inhalt des Product-Backlogs, aber keine Kontrolle über den Release-Prozess hat – keine Ahnung, wie wir so jemanden nennen sollen. Hast du eine Idee?
Warum erzähle ich dir das alles? Zusammen mit Marc gebe ich das Training jetzt seit vier Jahren. Und über die Jahre erkennen wir einen Trend: Die regelmäßige Auslieferung von funktionierender Software bereitet immer weniger Teams ein Problem. Ein Product-Owner, der eigenständig entscheidet, was ins Product-Backlog kommt und was nicht, ist jedoch immer noch selten.
Und hier verbirgt sich: „Wir machen Scrum, aber wir haben einen Product-Owner, der keine Entscheidungen treffen darf.“
Die Auswirkung davon, wenn Product-Owner eher Delivery-Manager oder Marionetten des Managements sind, ist, dass das dritte Versprechen jeder agilen Transformation für das Unternehmen nicht eingelöst werden kann.
Selbst wenn Veränderungsoptionen erkannt werden, können sie nicht schnell genutzt werden.
Natürlich sind das nicht alle „Scrum, aber …“.
Vielleicht kennst du auch noch welche – dann schreibe sie gerne in die Kommentare.