Viele Unternehmen haben sich für Scrum als Prozess entschieden, um ihre Wertschöpfung zu steuern.
Dabei gibt es nur ein Problem: Scrum ist eben kein Prozess.
Scrum ist lediglich ein Rahmen, innerhalb dessen Teams einen Wertschöpfungsprozess erstellen und kontinuierlich verbessern können. Die kontinuierliche Verbesserung fußt dabei auf den drei Säulen der empirischen Prozesssteuerung: Transparenz, Überprüfung und Anpassung. Vernachlässigen Teams eine dieser Säulen, dann kommt es zu Dysfunktionen. Diese Dysfunktionen sorgen dafür, dass die Verbesserung der Wertschöpfung ausbleibt.
Seit acht Jahren nutze ich Scrum nun schon intensiv und dabei konnte ich viele dieser Dysfunktionen erleben. In diesem Artikel findest du die sechs häufigsten Scrum-Dysfunktionen:
Scrum-Dysfunktion 1: Undone-Scrum
Unternehmen, die Vorteile von Agilität nutzen wollen, scheitern häufig an diesem grundlegenden Prinzip des Manifests für Softwareentwicklung:
Funktionierende Software ist das wichtigste Fortschrittsmaß.
In Scrum bedeutet „funktionierende Software“ jeden Sprint ein „Done“-Inkrement zu haben. Denn nur ein nutzbares Inkrement stellt die Transparenz des Ist-Zustandes her. Teams, die dazu nicht in der Lage sind, machen noch kein Scrum. Diese Dysfunktion bezeichnen wir als „Undone-Scrum“.
Ein häufiges Symptom für „Undone Scrum“ ist, dass das Scrum Team die Entwicklung übernimmt. Die Anforderungsanalyse und die Auslieferung finden in einem anderen Team statt.
Scrum-Dysfunktion 2: Zombie-Scrum
Besuchen die Mitglieder des Teams die Scrum-Meetings nur, um diese von der To-do-Liste streichen zu können, dann führen sie Scrum aus, als wären sie Zombies.
Typische Anzeichen für das zombiehafte Verhalten:
- Im Daily Stand-up besprechen die Entwickler, was jeder von ihnen gestern gemacht hat, aber sie erstellen keinen Plan für den heutigen Arbeitstag.
- Im Sprint Review präsentiert das Team den Stakeholdern die fertiggestellten Features ohne Feedback aufzunehmen.
- In der Retrospektive wird diskutiert, was in diesem Sprint schlecht lief, es werden aber keine Verbesserungsmaßnahmen für den nächsten Sprint beschlossen.
Es findet also eine Überprüfung der Arbeit statt, aber keine Anpassung. Diese Dysfunktion, bei der das pulsierende Herz der kontinuierlichen Verbesserung fehlt, nenne ich Zombie-Scrum.
Scrum-Dysfunktion 3: Einheitsscrum
Wie lang ist die Sprint-Länge deines Scrum Teams?
Die Chancen stehen gut, dass deine Antwort „zwei Wochen“ lautet. Bei einer Umfrage von CA Technologies gaben 59,1 % der Befragten an, dass ihr Sprint zwei Wochen dauert.
Die Vereinheitlichung der Sprint-Länge für jedes Scrum Team im Unternehmen ist nur ein Anzeichen für „Einheitsscrum“. Weitere Anzeichen sind diese:
- Jedes Scrum Team muss die Anforderungen in Form von User Storys beschreiben.
- Die Teams müssen eine fest vorgegebene Anzahl von Story Points pro Sprint erledigen.
- Jedes Scrum Team muss genau 4 Entwickler, 2 Tester, 1 Analysten, 1 Designer, 1 Product Owner und einen Scrum Master umfassen.
Wenn Unternehmen die Kontrolle und Vorhersagbarkeit eines Prozesses wichtiger ist als die Werterzeugung, führt es häufig dazu, dass sie Prozesse über alle Teams im Unternehmen standardisieren. Dadurch geht die regelmäßige Überprüfung verloren und es entsteht „Einheitsscrum“.
Scrum-Dysfunktion 4: „Best Practice“-Scrum
Es gibt keine Best Practices in Scrum!
Die Entwicklung und Lieferung von Softwareprodukten sind nicht immer vorhersagbar. Um erfolgreich zu sein, benötigt es Kreativität und den Willen, neue Dinge auszuprobieren. Dabei entdecken selbstorganisierende Teams Praktiken, die für sie am besten funktionieren. Diese aber eins zu eins auf andere Scrum Teams, Produkte oder Kontexte zu übertragen, funktioniert nicht. Selbsternannte Experten, die behaupten, Scrum Teams seien nur erfolgreich, wenn sie Best Practices wie User Storys, Story Points und Planning Poker verwenden, behindern die kontinuierliche Verbesserung. Aber darum geht es im Kern doch bei Scrum.
Wenn die Anpassung an die Ist-Situation fehlt, bezeichne ich diese Scrum-Dysfunktion als „Best Practice“-Scrum.
Scrum-Dysfunktion 5: „Das funktioniert hier nicht“-Scrum
Seit der Einführung von Scrum arbeitet das Team effizienter.
Das Scrum Team plant jetzt regelmäßiger seine Arbeiten, was weniger Verschwendung der Arbeitszeit zur Folge hat. Trotzdem ist das Team nicht in der Lage, regelmäßig am Ende des Sprints eine neue Version des Produkts zur Verfügung zu stellen. Die Ursache hierfür ist schnell gefunden, das Team muss häufig auf die Zuarbeit von anderen Teams oder Experten warten. Auf dieses Problem angesprochen, lautet die Antwort der Teammitglieder: „So arbeiten wir hier halt.“ Als Lösung dieses Problems sehen die Teammitglieder, dass sie nun keine Definition of Done mehr verwenden.
Das sind Anzeichen für ein Umfeld, in dem „Das funktioniert hier nicht“-Scrum praktiziert wird. Der Rahmen, den Scrum diesen Teams zur Verfügung stellt, hilft ihnen, ihre Arbeitsweise zu überprüfen. Allerdings fehlt die Anpassung ihrer Arbeitsweise.
Die bittere Wahrheit:
Entweder wir machen Scrum oder wir machen kein Scrum. Eine Änderung von Scrum löst die Probleme nicht.