Fake Agile: Ist jedes Scrum Team agil?
Nein, leider ist nicht jedes Scrum Team auch tatsächlich agil.
Lass mich erklären: Ein Scrum Team definiert sich dadurch, nach dem Scrum Framework zu arbeiten: Es hat also Sprints, bestimmte Rollen und Rituale. Und da der Sinn vom Scrum Framework ja ist, Teams zu helfen agil zu arbeiten, sollte Scrum ja auch automatisch jedes Team agil machen, oder?
Leider schaffen es Organisationen in der Praxis immer wieder Scrum einzuführen und die Teams dadurch alles andere als agil zu machen. Man spricht dann häufig von „Zombie Scrum“.
Was ist „Fake Agile“?
„Fake Agile“ bezeichnet Teams, die zwar offiziell mit agilen Frameworks und Methoden arbeiten, ohne dabei tatsächliche Lernschleifen mit Kunden zu haben. Fake Agile bedeutet also, dass man entweder a) erst gar nicht iterativ Inkremente an Kunden liefet oder b) das direkte Kundenfeedback zum Inkrement nicht für die kurzfristige Priorisierung nutzt.
Was sind die Ursachen von Fake Agile?
Gründe für „Fake Agile“ gibt es viele. Die häufigsten Ursachen in der Praxis für Fake Agile sind meiner Erfahrung nach folgende:
Fake Agile Ursache #1: Kein Kundenfeedback
Wenn ein agiles Team kein direktes Feedback von Nutzer*innnen erhält, kann es nicht agil arbeiten. Häufig werden Kundenwünsche in der Praxis vom Management formuliert und über Product Owner an Teams durchgereicht – echte Feedbackschleifen mit Kunden verkümmern, oder existieren erst gar nicht.
Ein agiles Team braucht direkten Kundenkontakt!
Fake Agile Ursache #2: Fokus auf Velocity & Story Points
Puh, muss man zu Story Points in 2025 noch viel sagen? Ich denke wir haben alle genug Erfahrung sammeln dürfen, wie sehr ein Fokus auf Velocity und Story Points dem Kundennutzen im Wege steht.
Ein Beispiel: Was passiert, wenn eine Funktion nach der ersten Iterationen zwar formal fertig ist, aber den Kundennutzen noch nicht erzielt? Wenn uns der Kundennutzen wichtig ist, dann arbeiten wir nach, bisher der Kundennutzen tatsächlich erreicht wird. Am Ende dauert es vielleicht 3 Iterationen, aber immerhin ist der Kunden jetzt glücklich.
Aber halt, jetzt kommt auf einmal mein Manager um die Ecke und beschwert sich, dass mein Team im letzten Sprint weniger Story Points umgesetzt hätte. Für meine Velocity wäre es also besser gewesen, hätten wir die nicht werthaltige Funktion einfach stehen lassen und direkt an der nächsten Funktion gearbeitet, damit wir mehr Story Points schaffen.
Was ein Quatsch, oder? Wenn wir diesen Prozess noch ein paar Monate wiederholen, haben wir ein Produkt mit sehr vielen Funktionen, die sehr wenig Kundennutzen schaffen.
Da darf man sich nicht wundern, wenn sowohl Kunden als auch Entwicklungsteams unglücklich werden und das Weite suchen.
Allgemeiner formuliert geht es hier um ein mittlerweile bekanntes Gesetz: Goodhardt’s Law
„When a measure becomes a target, it ceases to be a good measure.“
Fake Agile Ursache #3: Die Dogma-Diktatur
Ingenieure lieben es, wenn es für alles feste Regeln gibt. Das macht Prozesse planbar.
Wie wäre es also, wenn wir unsere Arbeitsweisen auch komplett mit Regeln festlegen – wäre das nicht toll? Nein, wäre es nicht.
Schon alleine mit Scrum und seinen vielen Regeln und Vorgaben fühlt sich agiles Arbeiten für viele Teams schon an wie arbeiten nach einem starren Leitfaden. Das sollte nicht so sein. Also mach es nicht noch schlimmer, indem du agiles Arbeiten mit weiteren Regeln und Vorgaben ausstattest.
In den besten agilen Teams, die ich kenne, fühlt sich Arbeiten menschlich, lebendig, spontan und kollaborativ an. Und zugegeben, in den meisten agilen Teams tut es das nicht.
Agile Teams müssen zumindest genug Freiraum haben, um flexibel mit Kunden kollaborieren zu können. Wenn Regeln und Prozesse das verhindern, sollten die Regeln und Prozesse hinterfragt werden.
In diesem Post habe ich schon konkret darüber geschrieben, welche Schritte notwendig sind, um Scrum Teams vor Zombie Scrum zu schützen: Zombie Scrum beheben
Fake Agile ist real: Wie schützt man sich?
Nichts schützt dich vollumfänglich vor falscher Agilität. Aber es gibt trotzdem etwas, was dich bestmöglich davor schützt: Ein effektiver Prozess Rund um kontinuierliche Verbesserungen.
Das fängt natürlich mit guten Retrospektiven an, in denen Teammitglieder ihre Ansichten offen teilen können und selbstwirksam Maßnahmen zur Verbesserung ableiten und umsetzen.
Solange dieser Prozess funktioniert, ist das Potential für echte Agilität auch in deinem Team nicht verloren.
Wenn du deine agile Retrospektiven auf das nächste Level bringen willst, empfehle ich dir –natürlich – Echometer, unser Tool für Retrospektiven. Du kannst es hier kostenlos ausprobieren: Echometer ausprobieren
