Alle reden über Scrum. Viele sagen, sie machen Scrum, vielleicht auch du! Aber machst du es auch richtig? Darfst du dein Vorgehen überhaupt Scrum nennen? Scrum ist sehr streng:
„Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum“ (Scrum-Guide: https://www.scrumguides.org/)
Prüfe dich selbst. Ein Beispiel: Wie lange ist dein Daily? Immer genau 15 Minuten? Oder doch 20 Minuten? Oder häufig 25? Wenn es nicht genau 15 Minuten lang ist, ist es dann noch Scrum?
Es gibt vier mögliche Antworten:
Der Scrum-Guide schreibt vor, dass das Daily genau 15 Minuten dauert. Dein Team muss in der Retrospektive Maßnahmen finden, um die Dauer streng einzuhalten. Wenn das Team auf die Idee kommt, dass ein längeres oder kürzeres Daily besser wäre, hält dein Scrum-Master eine zornige Predigt.
Wir kennen solche Scrum-Master, und wir halten nichts von ihnen. Niemand kennt die perfekte Dauer des Daily, für alle Teams und alle Situationen. Es gibt schlicht keine empirische Untersuchung über den Zusammenhang „Dauer des Daily“ und Projekterfolg. Eine solche Untersuchung scheitert schon alleine daran, dass niemand den Projekterfolg messen kann. Doch das ist eine andere Geschichte.
Dein Team einigt sich auf 30 Minuten für das Daily und schämt sich, dass es noch nicht reif ist für richtiges Scrum. Du bekennst dich dazu: Dein Vorgehen ist höchstens Scrum-But…
Das finden wir komplett übertrieben. Scrum gibt dir einen Rahmen. Scrum motiviert das Team. Scrum sieht gut aus im Management. All das entfällt, wenn du es nicht mehr Scrum nennst. Gib nicht so schnell auf!
Das Team einigt sich auf 30 Minuten und nennt es weiterhin Scrum. Wenn die Sprache auf die Dauer des Daily kommt, wirst du verlegen. Glücklicherweise fragt selten jemand nach und du redest auch nicht groß darüber.
Das ist schon mal der richtige Weg, finden wir. Aber immer noch etwas defensiv…
Wenn 30 Minuten besser sind, dann macht dein Team ein 30-Minuten-Daily. Genau das ist doch die Idee von Scrum! Wozu machen wir Retrospektiven? Um herauszufinden, was für dieses Projekt und dieses Team am besten funktioniert.
Aber im Scrum-Guide steht doch… Der Scrum-Guide ist ein guter Start für ein Team, aber es ist keine göttliche Quelle ewiger Wahrheit. Kannst du dich noch an die Zeiten des Sprint-Commitments erinnern? Wer damals versucht hat, sich auf das Ergebnis des Sprints felsenfest und feierlich festzulegen, hat gemerkt: Das ist nicht motivierend, sondern unrealistisch und führt zu Qualitätsproblemen. Diese Erkenntnis hat auch den Scrum-Guide erreicht, und er wurde angepasst. Und es wird weitere Anpassungen geben, da sind wir uns sicher.
Selbst wenn man annimmt, dass die Vorgaben des Scrum-Guide für viele Konstellationen das Bestmögliche sind, so ist es doch vollkommen unwahrscheinlich, dass sie in allen Aspekten für alle Konstellationen optimal sind. Oder sind solche Konstellationen von vornherein ungeeignet für Scrum? Das hieße, dass die Umgebung immer erstmal so zu schaffen ist, dass Scrum optimal ist. Aber dann würde Scrum zum Selbstzweck mutieren und wäre nicht mehr hilfreich.
Andererseits wehren sich die Erfinder von Scrum zu Recht dagegen, dass jeder alles „Scrum“ nennt, und noch mehr dagegen, dass diese Projekte angeblich wegen „Scrum“ nicht funktionieren. Nur: Wenn keiner wirklich Scrum macht, wie will man dann behaupten, Scrum sei richtig und hilfreich?
Wir sind überzeugt, Scrum darf und soll man anpassen. Aber welche Teile und welche besser nicht?
Für uns ist Scrum ein Vorgehens-Framework mit zwei Aspekten: Ausgangspunkt und agile Anpassung. Ein Team kann mit Scrum nach Lehrbuch anfangen und hat, zusammen mit den agilen Praktiken, einen leidlich, nein sogar gut funktionierenden Werkzeugkasten. Zusätzlich leitet Scrum dazu an, zu beobachten und sich anzupassen. Damit kann das Team sich dem optimalen Vorgehen annähern, hier und jetzt, Schritt für Schritt und immer wieder.
Eine dogmatische Auslegung der Regeln verhindert diese Anpassung. Scrum ist dazu da, Freiheit zu schaffen: Bewegungsfreiheit, damit das Team sein Optimum finden kann. In der Retrospektive hat man alle Freiheitsgrade. Außer, die Freiheit abzuschaffen.
Wie nennst du es nun, wenn ein Team mit 30 Minuten besser fährt als mit 15? Oder das lieber zwei Owner für ein Produkt hat als einen? Oder bei dem einer im Team fast nur testet?
Wenn das Team solche Lösungen gefunden hat, nenne es: Scrum und agil.
Wie können Sie agile Methoden in Ihrer Organisation umsetzen, damit sie einen echten Mehrwert liefern? Erfahren Sie, wie wir Sie unterstützen können: