Aktuell überarbeite ich meine Webseite umfassend. Daher können einige Links ins Leere führen, Texte unvollständig sein und es kann an manchen Stellen noch zu Problemen kommen. Ich werde diesen Hinweis entfernen, sobald die Seite vollständig aktualisiert ist. Bis dahin bitte ich um etwas Geduld. Schaue auch unter den letzten Updates nach, wenn du etwas bestimmtes suchst.
Schon länger - und gerade in größeren Unternehmen - fällt mir eine phasenorientierte Pseudo-Agilität bei Scrum Implementierungen in Unternehmen und in Teams auf. Ich bezeichnet damit die Situation, das alte Denken von klassischen Phasen auf die neuen Iterationen oder Sprints zu übertragen. Dabei stellt sich oft heraus, dass diese Vorgehensweise im Grunde keine Verbesserungen im Bezug zum Ziel von Agilität bringt.
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.
Du hast keinerlei Vorteil, wenn du dein aktuelles, sequentielles Vorgehen in kürzeren Sprints durchführst. 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.
Was verstehen wir unter Agilität?
Agilität bezieht sich auf die Fähigkeit von Organisationen und Individuen, flexibel und schnell auf Veränderungen zu reagieren. In einem geschäftlichen Kontext bedeutet Agilität, dass Unternehmen in der Lage sind, ihre Strategien, Prozesse und Produkte kontinuierlich anzupassen, um den sich wandelnden Marktbedingungen und Kundenbedürfnissen gerecht zu werden. Dieser Ansatz fördert eine Kultur der Zusammenarbeit, Innovation und kontinuierlichen Verbesserung, was letztendlich zu einer höheren Effizienz und Wettbewerbsfähigkeit führt.
Geprägt wurde das überwiegend durch das agile Manifest aus dem Jahre 2001, welche Wertepaare und Prinzipien bereithält.
Eine Gegenüberstellung
Header | Wasserfall | Phasenorientierte Pseudo-Agilität | Agilität |
|---|---|---|---|
Beschreibung | Aufeinanderfolgende Phasen | Phasen in Iterationen | Iterationen mit Inkrementen |
Wo nutzbar? | Überall dort, wo Anforderung recht klar beschrieben und unverändert erreicht werden können. | Der erste Schritt zu mehr Agilität oder bei falscher Umsetzung von Agilität | Überall dort, wo Anforderungen sich schnell ändern und du flexibel entwickeln möchtest |
Typische Eigenschaften | schwergewichtig, phasenorientiert und meilensteinbasiert | iterativ mit Phasen | Leichtgewichtig, inkrementell und iterativ |
Mögliche Gefahren | Teure Änderungen, schwergewichtig | Kein wirklicher Gewinn aber verbessertes Reporting und schnelleres Feedback | Enter your text here... |
Cell | Cell | Cell | Cell |
Erkennen von Pseudoagilität
Unechte Agilität offenbart sich an unterschiedlichen Stellen. Nicht immer sind alle folgenden Punkte betroffen und die diese sind auch nicht abschließen.
Erkennen von Pseudoagilität
Natürlich kann die Einführung und Umsetzung von Agilität auch schrittweise und experimentell erfolgen (was ja selbst dem Naturell des agilen Manifests entspricht). Insofern können die folgenden Punkte natürlich auch eine Momentaufnahme sein, die sich über die Zeit ändert.
Detailliert Planungsreich
Zeremonien und Artefakte ohne Wirkung
Besonders deutlich zeigt sich die Pseudo-Agilität im Sprint Planning oder auch gerade im Bezug zum Sprint Ziel. Meist gibt es die Planung mit wenig bis keiner Einbindung der Entwickler und mehr im Sinne eine Projektleitermeetings und das Sprint Ziel ist selten klar abgrenzbar und wird in Frage gestellt. Auch in anderen Events in Scrum findest du typische Dysfunktionen.
Top-Down Entscheidungen
Entscheidungen sind selten selbstorganisiert von den Experten getroffen, sondern nach wie vor durch ein Management, was meistens in das Mikromanagement verfällt, wenn es eng wird.
Abhängigkeiten / Phasen
Du kannst natürlich mit Exploration, Konzeption und Implementierung als Phasen arbeiten. Das verbietet dir niemand. Wenn dein Ziel Agilität ist und du ein Framework wie Scrum nutzen möchtest, dann hilft dir das nur wenig weiter.
Das Denken in diesen Phasen und weder das Ändern wollen noch das Verständnis darüber zeigen dir immer phasenorientierte Pseudo-Agilität.
Häufige Diskussion über Reportings
Wenn du wirklich Agilität lebst und gerade inkrementell und iterativ entwickeln kannst, dann sind Metriken sehr einfach umzusetzen. Und du wirst wenig Diskussionen darüber führen. Je weniger du agile Prinzipien verstanden hast und diese lebst, desto mehr wirst du Diskussionen über das Reporting führen.
Kritikpunkte an Pseudoagilität
Täuschung
Verpasste Chancen
Demotivation
In den meisten Fällen sieht ein verkürzter Scrum Wasserfall aber wie folgt aus. Es werden häufig folgende Situationen angetroffen:
Abhängigkeiten
Du wirst schnell feststellen, dass sich jede Abhängigkeit, die du zwischen Bereichen in deinem Team oder deiner Organisation negativ auf dein reines agiles Vorgehen auswirkt. Nicht immer kannst du das komplett vermeiden. Lass uns einige Beispiele ansehen.
(System) Tests
Nicht immer ist dein Team gleich dein Produkt und du arbeitest mit mehreren Menschen und Teams zusammen. Wenn dann auch noch bestimmte rechtliche Anforderungen mit auf dem Plan sind, dann gibt es oft einen Systemtest, der alles, was erstellt wurde, im Zusammenspiel durchtestet.
Teams
Sind mehrere Teams beteiligt, dann ist immer die Frage, wie das Produkt "geschnitten" ist. Entweder kannst du durch Umorganisation Abhängigkeiten beseitigen oder aber du musst sie schlicht verwalten.
Was tun?
Wenn du dich jetzt wiedererkannt hast, ist meistens die Frage: Was machen wir denn jetzt? Hier findest du nun ein paar Impulse, die du dir ansehen kannst um Ideen zur Lösung zu bekommen.
Ist Agilität überhaupt das Ziel?
Habt ihr mit klaren Zielen gestartet, dann kannst du super dagegen messen. Oft ist das nicht der Fall. Dann lohnt sich nochmals zu prüfen, ob Agilität überhaupt das Ziel ist.
Wertstrom checken
Überprüfe deinen Wertstrom deines Produktes, um die echten Engpässe zu erkennen. Nutze ein Vorgehen wie STATIK um Verbesserungen herauszuarbeiten.
Fazit
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.