Scrum-Guide – Ja oder nein?

So, Freund:innen. #scrumguide, ne?

Ich habe seit der Veröffentlichung des neuen Guides zwei Arten von Posts in Blogs und Sozialen Medien gesehen.

Die einen, die den Erklärbär machen und erläutern, was sich alles geändert hat. Da waren auch viele Schnellschüsse dabei, aber was soll's das ist halt Marketing – Experten kreieren entweder, machen Inhalte anderer für die eigene Zielgruppe zugänglicher oder interpretieren sie für diese Zielgruppe. Alles fine, wenn auch nervig. Man sollte halt darauf achten, dass das Ergebnis auch wirklich hilfreich und nicht nur schnell da ist.

Die zweite Gruppe waren die Überheblichen "Ich mach agile so, wie ich das kenne, dafür brauche ich ja keine Bibel aka Scrum Guide, der mir sagt, wie's zu laufen hat. Da bin ich ja eh schon weit entfernt von, so agile bin ich!!!11"

Ist auch fine, Jürgen/Anette/Kevin/Wieauchimmerduheissenmagst. Wenn du dein Produkt schnell, marktrelevant entwickeln, positionieren, vermarkten und verkaufen kannst, ist alles super. Du MUSST dafür natürlich kein Scrum verwenden. Erzähl mir gerne mal davon, wie Ihr das hinbekommt. Und wenn du Lust hast, trete ich da auch gerne mal gegen. 

Die Realität ist allerdings die, dass Scrum einfach auch richtig gute Ideen beinhaltet. Klar sind hier und da ein paar Fehler gemacht worden in der Definition – ich leide täglich darunter! Aber für ein bestimmtes Problemumfeld ist es schlau, sich Scrum anzusehen und zu versuchen, zu verstehen, warum es funktionieren kann/soll. Und auch, welche Nachteile und Besonderheiten man sich damit einkauft. Und dann kann man das für sich einfach mal ausprobieren, gerne auch recht eng an den Regeln, die das Framework mitbringt. Übrigens: Genau dieses "Modell nehmen, verstehen, anwenden und Resultate inspizieren" ist ein Teil der sechsten Praktik Kanbans!

Und auch all die Menschen, die schon seit krassen 140 Sprints (true story!!) Scrum anwenden, können sich dieses Framework angucken und die eigenen Regeln an der "Musterlösung" spiegeln und darüber nachdenken, welche Dinge im eigenen Kontext eigentlich warum passieren. Dafür sind Definitionen gut!

Ich habe mittlerweile wenig Verständnis für ScrumMaster, die die wenigen Seiten der Definition ihres Frameworks nicht kennen – und häufig auch nicht verstehen. Ein gutes Beispiel sind die Sprint Reviews. Ich möchte in 80-90% der Reviews, die ich mir so ansehe, Vollkontakt zwischen meiner Tischplatte und meiner Stirn herstellen. Langweilig, uninspirierend, zwanghaft, unkooperativ. 

Warum? "Das Sprint Review ist doch ne Demo und wir sollen da Kundenfeedback sammeln."

Äh. Nein. Das stand so noch nie in der Definition des Frameworks, das du da vertrittst. Ist dir vielleicht mal in nem Training erzählt worden, macht es aber auch nicht richtiger.

Das Sprint-Review ist ein kooperatives Ereignis, in dem eine Richtungsentscheidung durch die involvierten Menschen getroffen wird. Wenn Ihr also keine Richtungsentscheidungen trefft, solltet Ihr also entweder a) kein Review machen, weil ihr keine Entscheidung treffen wollt/könnt/sollt oder b) einfach mal aufhören, die Zeit zu verschwenden, und stattdessen die relevanten Personen einladen, damit der Zustand der Welt, des Produktes, des Teams inspiziert werden kann und daraus folgend gemeinsam entschieden wird , wie die Richtung im nächsten Sprint aussehen soll.

Die Zustände ändern sich gar nicht so schnell? DANN MACH DOCH EINFACH MAL 4-WOCHEN-SPRINTS! Du musst übrigens trotzdem zwischendrin Rückmeldung zum Produkt sammeln!

Zu a) übrigens noch: Wenn Ihr zwischendrin keine Richtungsentscheidungen fällen müsst, habt Ihr halt kein markt-agiles Projekt/Produkt. Sondern eher nen flexiblen Ablaufplan. Ist für vieles auch völlig okay. Aber da gelten ein paar andere Regeln, die man dann klar haben muss.

Brauchen wir den Scrum-Guide

So. Also. Brauchen wir den Scrum-Guide? Nunja. Schon. Zumindest, damit wir die Ideen dieses Frameworks mal verstehen können. Nur vom Hörensagen sind sie einfach schwer zu diskutieren (*hüstel* Praktik vier der Kanban-Methode: Mache Prozessregeln explizit *hüstel*). Wenn wir eine gemeinsame Basis haben, von der wir ausgehen, können wir Veränderungen und Anpassungen sinnvoll angehen, mit dem Resultat im Blick. 

Außerdem hilft der Guide hin und wieder in Situationen, in denen der eigene Ethos vielleicht nicht ausreicht, um zu überzeugen. ;)