Scrum ist nicht das Problem

Eigentlich wollte ich für meine Serie, in der ich einen Recap von alten Folgen mache und auf Mastodon unter dem Hashtag #AgileThread poste, über die Folge "NBA04: Scrum: Warum es Zeit ist, ein anderes agiles Vorgehen zu erwägen" schreiben.

Beim Reinhören in die Folge und Lesen des Transkripts und auch aufgrund verschiedener Gespräche auf Mastodon (unter anderen in diesem Thread) will ich in diesem Artikel aber die Möglichkeit ergreifen, eine Sicht auf Scrum zu erläutern.

Warum Scrum gar nicht das Problem ist

In den Diskussionen rund um Scrum bin ich bisher immer an den Punkt gekommen, dass Scrum so beliebt ist, weil es gut verkauft wurde (von Zertifizierungsorganisationen) und nicht weil es hilft gute Software schnell zu liefern. Was, wenn das zwar stimmt, es aber nicht die Schuld von Scrum ist?

Scrum ist nicht das Problem - Ihr seid es

Zugegeben, das ist etwas provokant. Aber wenn wir gemeinsam zurück reisen und schauen, warum Scrum entstanden ist, sollte uns das helfen, die fundamentalen Ideen hinter Scrum zu verstehen und diese mit unsern heutigen Implementierungen zu vergleichen. Erwartet keinen vollständige historischen Abriss - dafür verweise ich auf die Wikipedia und eine Google-Suche.

Die Geschichte

In den 1990er Jahren war das Wasserfall Modell dominierend, wenn es darum ging, ein Software Projekt umzusetzen. Klar getrennte Phasen, die aneinander anschließen, definieren Anforderungen, konzipieren diese, setzen diese um, testen diese und releasen sie schlussendlich. Die Idee: Je besser wir definieren, was wir wollen oder brauchen, desto besser die Software, die entwickelt wird.

Das Problem daran: Unsere Welt dreht sich weiter. Auch mit immensem Planungsaufwand können wir nicht vollständig definieren, was wir (oder der Markt) wirklich brauchen. Dieser Umstand führte (und führt heute noch) dazu, dass am Ende des Wasserfalls zwar eine funktionierende Software entstehen kann, es aber eher unwahrscheinlich ist, dass es die Software ist, die wir brauchen.

Frustriert von dieser Erkenntnis fingen Ken Schwaber und Jeff Sutherland (und viele weitere) unabhängig voneinander an, neue Ansätze zu entwickeln, die später in Scrum münden sollten. Die fundamentale Idee: Früh Feedback bekommen um permanent festzustellen, ob der ursprüngliche Plan noch passt oder angepasst werden sollte.

Alle weiteren Regeln, Rollen und Rituale, die der Scrum Guide erwähnt, sollen dies unterstützen. Es geht darum, nicht nur einmal in einem halben Jahr Software zu releasen sondern so oft wie irgend möglich um Feedback zu bekommen. Das ist die fundamentale Idee.

Ihr seid das Problem

Zurück zur Gegenwart. Zurück zu der Diskussion auf Mastodon. Wenn denn die Idee von Scrum war und ist, dass Software oft geliefert werden muss um einen neuen Feedback Zyklus zu starten, warum machen dann Teams, die behaupten, sie nutzen Scrum, das nicht? Warum sehe ich solche Antworten (ja, das ist nur ein aktuelles Beispiel)?

We are talking about a business application, not a crappy web app. A full regression test is needed before each release and we lack testers.
I think making two or three major releases with a minor release for each is realistic. 

Seht ihr das Problem? Wenn ein kompletter Regression Test notwendig ist vor jedem Release, dann kann ich verstehen, dass man nicht alle zwei Wochen releasen kann. Aber dann müsst ihr auch nicht agil arbeiten. Es scheint ja der Fall zu sein, dass die Wettbewerber auf dem Markt in einer ähnlichen Situation sind. Es scheint der Fall zu sein, dass ihr damit leben könnt, dass ihr erst Feedback euer User nach mehreren Monaten Entwicklung bekommt. Das ist ok!

Aber: Es ist nicht agil und Scrum ist nicht dafür gedacht. 

Es ist unfair im gleichen Zuge über Scrum zu schimpfen. Ihr nutzt eine Fahrrad um von Hamburg nach München zu fahren weil ihr die frische Luft liebt und beschwert euch gleichzeitig, dass es sehr lange dauert und ihr nass werdet, wenn es regnet.

Das Fahrrad kann aber nichts dafür - ihr seid daran Schuld, ihr habt das Fahrrad ausgewählt.

Fazit

Ich bin der Meinung Jeff Sutherland hat mal in einem Workshop zu einem Kollegen sinngemäß folgendes gesagt: Wenn du die fundamentalen Konzepte, die Scrum dir bietet, nicht umsetzen kannst, ist das ok. Nenn es dann aber nicht Scrum.

Wenn ihr nicht agil arbeiten könnt, zum Beispiel weil gesetzliche Vorgaben oder andere Elemente aus eurem Umfeld es nicht zulassen, dann ist das ok. Aber dann müsst ihr damit leben, dass Scrum für etwas anderes gedacht war und könnt nicht Scrum blamen.