.st0{fill:#FFFFFF;}

Projekterfahrungen

Phasenorientierte Pseudo-Agilität

 Dezember 27, 2017

von  Sebastian

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.

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.

Sebastian

Ein paar Worte über den Autor
Agile Team Facilitator Sebastian Schneider
Agile Team Facilitator Sebastian Schneider
Sebastian Schneider CSP
Sebastian Schneider CSP-PO

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt. Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben. Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen. Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Seien auch Sie dabei: Der Newsletter zu Scrum aus Augsburg.

>