Zombie Scrum

Wissen kompakt: Zombie Scrum bezeichnet die Anwendung von Scrum in Organisationen, ohne den Zweck und die Werte mit Leben und Herzblut zu füllen.

Zombie Scrum – Die seelenlose Anwendung von Scrum ohne Herz

Zombie Scrum ist ein Begriff, der verwendet wird, um eine dysfunktionale Implementierung von Scrum zu beschreiben, bei der die formalen Strukturen und Prozesse von Scrum beibehalten werden, aber der eigentliche Zweck und die Werte von Scrum nicht mehr erfüllt werden. Es sieht aus wie Scrum, ist aber nicht Scrum. Es fehlt der Herzschlag – wie bei einem Zombie.

Scrum basiert auf 5 Werten:

  • Commitment bzw. Selbstverpflichtung
  • Mut
  • Offenheit
  • Fokus
  • Respekt

Das Commitment des Teams, das vereinbarte Sprint-Ziel zu erreichen, die Verpflichtung zu Qualität, Lernen und gemeinsam das Beste zu geben, ist entscheidend für die Zusammenarbeit und den Aufbau einer agilen Kultur.

Mut ist wichtig für den Erfolg des Teams, denn es geht darum, Neues auszuprobieren, Fehler zuzugeben, wenn nötig um Hilfe zu bitten, zu manchen Anforderungen “Nein” zu sagen und den Status quo gegebenenfalls in Frage zu stellen.

Offenheit ist die Grundlage für eine Lernkultur, für Feedback und neue Ideen. Offenheit als Wert ermöglicht fundierte Entscheidungen, erhöht die Effizienz und schafft Vertrauen.

Fokus hilft dem Team, sich auf die wichtigen Dinge zu konzentrieren – bspw. durch Tools wie Timeboxing, Definition of Ready oder Definition of Done. Der Scrum Master versucht störende Einflüsse von den Entwicklern fernzuhalten und der Product Owner konzentriert sich auf das “Warum” und “Was”, aber nicht auf das “Wie”.

Respekt als Wert ist essenziell für die Zusammenarbeit zwischen den Beteiligten. Es gilt die Ideen, Ansichten und Leistungen von anderen zu respektieren. Respekt ist ein zentraler Baustein für eine erfolgreiche und produktive Entwicklung.

In Zombie Scrum werden einzelne Werte oder gar alle Werte nicht gelebt. Dies führt schnell zu einer Reihe von Problemen: Die Flexibilität und Anpassungsfähigkeit des Teams sinkt, die Transparenz innerhalb des Teams und in Richtung Kunden nimmt sukzessive ab, die Kultur der kontinuierlichen Verbesserung leidet. Die Unzufriedenheit im Team steigt, die Produktqualität sinkt und Fluktuation droht.

Einige Symptome von Zombie Scrum

Der Begriff Zombie Scrum geht auf Christiaan Verwijs, Johannes Schartau und Barry Overeem zurück, die in The Zombie Scrum Survival Guide¹ Symptome und mögliche Lösungsansätze benennen. Aus ihrer Sicht geht es in Scrum vor allem darum, das zu bauen, was Stakeholder brauchen, so schnell wie möglich überprüfbare Ergebnisse zu produzieren, sich kontinuierlich zu verbessern und sich als Team auf ein gemeinsames Ziel hin zu organisieren. Die Symptome von Zombie Scrum manifestieren sich in folgenden zentralen Merkmalen:

1. Es besteht keinen Wunsch nach Kontakt zur Außenwelt.

Teams isolieren sich. Sie konzentrieren sich nur auf ihre spezifische Aufgabe, ohne sich um den Gesamtkontext oder die Bedürfnisse der Stakeholder zu kümmern. Sie fühlen sich oft als Rädchen im Getriebe, unfähig und unwillig, etwas zu verändern oder wirklich Einfluss zu nehmen. In traditionellen Unternehmen arbeiten Teams oft in Silos und produzieren Produkte, die zwar funktionieren, aber möglicherweise nicht den tatsächlichen Kundenbedürfnissen entsprechen. Dies führt zu einer erheblichen Verschwendung von Ressourcen und Ergebnissen in Form von mittelmäßigen Produkten mit fragwürdigem Wert.

2. Es existieren keine funktionierenden Inkremente.

Zombie-Scrum-Teams folgen zwar den Scrum-Regeln, liefern das Produkt aber erst am Ende der Entwicklung oder nach vielen Sprints ab. Die Stakeholder haben selten die Möglichkeit, das vom Entwicklungsteam erstellte Produkt zu überprüfen. Darüber hinaus hat das Team eine sehr begrenzte Definition von “fertig” und zeigt wenig Motivation, diese zu erweitern

3. Das Team hat keine Motivation, seine Arbeitsweise zu verbessern.

Zombie-Scrum-Teams reagieren weder auf einen gescheiterten noch auf einen erfolgreichen Sprint. Anstatt zu fluchen oder sich zu freuen, zeigen sie eine gefühllose Resignation. Die Teammoral ist niedrig. Elemente aus dem Sprint Backlog werden ohne Rücksprache einfach in den nächsten Sprint verschoben. Warum auch nicht? Aus ihrer Sicht gibt es immer einen nächsten Sprint und die Sprintziele und Sprint-Inhalte sind sowieso willkürlich.

4. Das Team ist nicht autonom und übernimmt keine Verantwortung.

Zombie-Scrum-Teams sind unflexibel in der Zusammenarbeit mit denjenigen, die sie brauchen, um ein großartiges Produkt zu entwickeln. Sie sind weder frei in der Wahl ihrer Werkzeuge, noch können sie wichtige Entscheidungen über ihr eigenes Produkt treffen. Sie müssen für fast alles um Erlaubnis fragen, und ihre Anfragen werden oft abgelehnt. Dieser Mangel an Autonomie führt zu einem Mangel an Verantwortungsgefühl. Warum sollten sie sich um den Erfolg eines Produkts kümmern, wenn sie nicht wirklich an seiner Entwicklung beteiligt sind?

Unterschiede zwischen Scrumbut, Scrumand und Zombie Scrum

Der Verzicht auf einzelne Elemente in Scrum (Events, Verantwortlichkeiten oder Artefakte), und damit die Abweichung vom Standard wie dieser im Scrum Guide beschrieben ist, wird als Scrumbut bezeichnet. Der Begriff leitet sich ab von “We use Scrum, but …”, zu Deutsch “Wir verwenden Scrum, aber …”. Die grundlegenden Regeln und Prinzipien von Scrum werden verstanden, aber aufgrund von Ausnahmen oder Einschränkungen in der Organisation wird Scrum nicht vollständig umgesetzt. Beispiel: “Wir verwenden Scrum, aber wir haben keine festen Sprints”.

Ein Scrumand beschreibt eine Situation, in der zusätzliche Prozesse oder Frameworks zu Scrum hinzugefügt werden, die nicht unbedingt im Einklang mit den eigentlichen Elementen stehen. Der Ausdruck leitet sich von “We use Scrum and …” ab, also “Wir verwenden Scrum und …”, z.B. “Wir verwenden Scrum und treffen uns zusätzlich einmal pro Woche zum Weekly Meeting”.

Zombie-Scrum beschreibt eine Situation, in der die formalen Strukturen von Scrum beibehalten, die Werte und Prinzipien von Scrum aber nicht mehr eingehalten werden. Im Gegensatz zu den beiden anderen Ausprägungen handelt es sich also nicht um das Weglassen einzelner Elemente oder das Hinzufügen von Extras, sondern um eine Situation, in der die Beteiligten am liebsten der Realität entfliehen würden.

Tipps gegen Zombie Scrum

Tipps gegen Zombie Scrum beinhalten häufig Ratschläge wie

  • die Wiederherstellung von Agilität,
  • die Förderung von Eigenverantwortung und Selbstorganisation im Team,
  • die Integration von Kundenfeedback in den Entwicklungsprozess und
  • die Förderung einer Kultur der kontinuierlichen Verbesserung.

In der Praxis laufen viele dieser Ratschläge jedoch oft ins Leere, da Zombie Scrum häufig tiefer liegende Probleme in der Unternehmenskultur, den Managementpraktiken oder der Teamdynamik widerspiegelt, die sich nicht einfach durch oberflächliche Änderungen beheben lassen.²

Sorry, dass wir hier an dieser Stelle keine einfachen, universell gültigen Tipps präsentieren können.

Zombie Scrum - Die seelenlose Anwendung von Scrum ohne Herz

Was macht t2informatik?

Was macht t2informatik? Kleiner Tipp: Es hat etwas mit Softwareentwicklung zu tun!

Impuls zum Diskutieren:

Gibt es Frühwarnzeichen, die als Indikatoren für die Entstehung oder das Vorhandensein von Zombie Scrum dienen können?

Hinweise:

[1] Zombie Scrum Survival Guide
[2] Heiko Bartlog hat eine Blogserie zum Thema Agilität? Haben wir probiert! Funktioniert nicht! geschrieben. Wer sich für Stolpersteine und Lösungsansätze für agiles Arbeiten interessiert, ohne eine Universallösung zu erwarten, wird seine helle Freude haben!

Wie Scrum funktionieren sollte, steht in unserem Scrum Whitepaper.

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken. Und falls Sie sich für Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Hier finden Sie ergänzende Informationen aus unserem t2informatik Blog:

t2informatik Blog: Glauben Sie an Agilität?

Glauben Sie an Agilität?

t2informatik Blog: Das ist doch kein Scrum

Das ist doch kein Scrum