Agile Overprocessing

Bild: Piqsels - Lizenz

Es mag wie ein Oxymoron erscheinen, trotzdem ist es ein in der Realität immer wieder zu betrachtendes Phänomen - das Agile Overprocessing. Gemeint ist damit die Überladung eines eigentlich für agiles Arbeiten konziperten Prozesses durch unnötige oder unnötig komplizierte Elemente, so dass am Ende das Gegenteil von Agilität erreicht wird: ein Erstarren in Formalismen, mit einer mehrheitlichen Ablehnung des Vorgehens als Folge.

Wichtig zum Verständnis ist, dass es sich bei den unnötigen Elementen nicht um solche handelt die genuin un- oder anti-agil sind (das wäre ein Hybrid-Vorgehen, nochmal ein eigenes Thema) sondern um solche die in anderen Kontexten durchaus agilitätsfördernd sein können. Dort wo sie durch nicht gegebene Voraussetzungen wirkungslos sind oder wo es den Missstand den sie beheben könnten gar nicht gibt werden fehlen ihnen aber Sinn, Mehrwert und als Folge auch Akzeptanz.

Um das an Beispielen festzumachen: ein häufiger Fall von agile Overprocessing ist die Einführung von WIP-Limits in Kanban-Systemen in denen zu viele parallele Arbeit kaum oder gar nicht vorkommt. Wärend sie dort wo vorher zu viel Multitasking vorherrschte befreiend wirken können verkommen sie ohne eine solche Problemlage zu einem blossen Formalismus, der darüber hinaus den Lean Management-Ursprüngen von Kanban diametral zuwiderläuft.

Ein weiterer Fall ist das in vielen Scrum Teams übliche Verwenden des klassischen User Story-Formats ("Als ... möchte ich ... um ...") für wirklich alle Anforderungen an deren Umsetzung gearbeitet wird, selbst dann wenn die so entstehenden Funktionen gar nicht für den Endnutzer gedacht sind ("Als Bank-Kunde möchte ich die Erstellung synthetischer Testdaten automatisiert haben, damit defekte Staging-Umgebungen schneller wiederhergestellt werden können").

Der Klassiker unter den unnötig komplizierten agilen Prozesse dürften die SAFe-Implementierungen sein bei denen versucht wird möglichst viele Teile des Startseiten-Wimmelbildes zu implementieren, obwohl im jeweiligen Anwendungsfall auch die minimalistische Version völlig ausreichend gewesen wäre. Dass SAFe durch seine vielen optionalen Teile versehentliches Overprocessiong so einfach macht ist ein Hauptgrund für seinen verheerenden Ruf in der Agile Community.

Selbst bei Ansätzen die als kaum anfällig für übertriebene Regulierung gelten kann sie auftreten. Ein Beispiele dafür wären Extreme Programming-Teams die eine Anwesenheit eines Onsite Customers auch in Iterationen fordern in denen nur Spikes zum besseren Verständnis des Legacy Code stattfinden oder Modern Agile-Teams die trotz grosser Vertrautheit und guter Feedback-Kultur vor jedem einzelnen Meeting die psychologische Sicherheit abfragen.

Alle derartigen Fälle (von denen es noch viel mehr gibt als hier beschrieben) haben das Risiko zur Folge, dass ihre offensichtliche Sinnlosigkeit und Unnötigkeit in der Aussenwahrnehmung auf das gesamte Vorgehen übertragen werden, das aufgrunddessen vollständig abgelehnt wird. Verstärkt wird das häufig durch unerfahrene aber dogmatische Scrum Master oder Agile Coaches, die WIP-Limits, User Stories o.Ä. für verpflichtend erklären und so auch noch ihr eigenes Amts-Charisma untergraben.

Die Lösung ist wie so oft das in Frage stellen dessen was scheinbar nicht in Frage gestellt werden kann. Frei nach dem Sprichtwort "Ist das noch Scrum oder kann das weg?" (oder "Ist das noch Kanban ...", "Ist das noch XP ...", etc) lässt sich bei allem was keinen Mehrwert bietet die Frage stellen ob das jeweilige Framework es wirklich zwingend erfordert. Bei einem genauen Blick auf das Regelwerk ist die Antwort darauf in den allermeisten Fällen ein klares Nein.

Ein Sonderfall liegt vor wenn  ein Prozess-Element zwar im jeweiligen Kontext offensich unnötig ist, im verwendeten Framework aber zwingend vorgeschrieben. In den Fällen liegt kein agile Overprocessing im Sinn einer unnötigen Verkomplizierung vor sondern lediglich eine unpassende Methodenauswahl. Aber auch die lässt sich natürlich korrigieren.

Siehe auch: Deine Muda - Overprocessing