Phasenorientierte Pseudo-Agilität

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.

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.

Phasenorientierte Pseudo-Agilität

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.

Scrum Backlog Sprint

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.

Leave a Reply 0 comments

Leave a Reply:







Cookie-Einstellung

Bitte treffen Sie eine Auswahl. Weitere Informationen zu den Auswirkungen Ihrer Auswahl finden Sie unter Hilfe. Datenschutz Erklärung für die Webseite | Impressum dieser Webseite

Treffen Sie eine Auswahl um fortzufahren

Ihre Auswahl wurde gespeichert!

Weitere Informationen

Hilfe

Um fortfahren zu können, treffen Sie bitte Ihr Cookie-Auswahl. Nachfolgend erhalten Sie eine Erläuterung der verschiedenen Optionen und ihrer Bedeutung.

  • Alle Cookies zulassen:
    Erlauben Sie mir alle Cookies? Danke :-)
  • Nur First-Party-Cookies zulassen:
    Cookies von dieser Webseite und Cookies, die es mir erlauben Ihr Erlebnis auf der Seite zu optimieren.
  • Keine Cookies zulassen:
    Es werden keine Cookies gesetzt, es sei denn, es handelt sich um technisch notwendige Cookies.

Sie können Ihre Cookie-Einstellung jederzeit hier ändern: Datenschutz Erklärung für die Webseite. Impressum dieser Webseite

Zurück

>