In der letzten Zeit fällt mir häufiger eine phasenorientierte Pseudo-Agilität bei Scrum Implementierungen auf. Ich bezeichnet damit die Situation, das alte Denken von klassischen Phasen auf die Iterationen oder Sprints zu portieren. Dabei stellt sich oft heraus, dass diese Vorgehensweise im Grunde keine Verbesserungen bringt. Schauen wir uns den Sachverhalt einmal anhand eines Szenarios genauer an.
Was bedeutet die phasenorientierte Pseudo-Agilität?
Um uns der phasenorientierten Pseudo-Agilität zu nähern, betrachten wir das folgenden Bild, dass ein typisches "Scrum Wasserfall" und ein "richtiges iteratives und inkrementelles Vorgehen" zeigt.
Sie haben keinerlei Vorteil, wenn Sie zum Beispiel ihr aktuelles, sequentielles Vorgehen nun in einen kürzeren Sprint durchführen. Stopp, werden die ersten nun sagen. Wir haben sehr wohl einen Vorteil, denn jetzt überprüfen wir häufiger unsere Arbeitsergebnisse und werden besser! Schauen wir uns diesen Sachverhalt weiter unten noch mal genau an.
Das Problem Scrum Wasserfall
In den meisten Fällen sieht ein verkürzter Scrum Wasserfall aber wie folgt aus. Es werden häufig folgende Situationen angetroffen:
- Innerhalb des Sprint wird kein lauffähiges Inkrement erzeugt. Und das unabhängig davon, ob der Sprint "erfolgreich" verlief oder nicht. Es wird ein gewisser Vorrat an Product Backlog Items abgearbeitet, die aber nicht die Eigenschaften von Product Backlog Items haben. Es sind praktisch bekannte Aufgaben, einfach in ein Product Backlog übernommen.
- Tritt während des Sprints ein Problem auf, zieht das alles in Mitleidenschaft. Wenn auf diesem Product Backlog Item weitere aufsetzen, dann wird eine ganze Kette verschoben oder kommt ins Straucheln.
- Sie sind nicht in der Lage innerhalb des Sprints eine Priorisierung vorzunehmen.
Fazit zur Pseudo-Agilität
Auch wenn es für viele Teams auf der Tagesordnung steht, diese Art der Sprints helfen nicht. Sie werden so nie helfen und agil werden Ihre Teams und die Organisationen nicht. Pseudo-Agilität ist ziemlich gefährlich. Natürlich müssen Sie Ihr Product Backlog Refinement verbessern. Auch das ist leichter gesagt, als getan. Die Gründe liegen darin, dass sehr wahrscheinlich mit dem Gedanken von Spezifikationen an Scrum heran gegangen wird. Spezifikationen sind nicht optimal für Scrum geschnitten - sie sind immer auf Vollständigkeit bedacht. Das verträgt sich nur bedingt und sollte dringend an der Grundursache angegangen werden.
