Agile Prozesse

Grafik: Pixabay / Geralt - Lizenz

"Wir haben keinen Prozess, wir arbeiten agil", ist einer der grossen Klassiker, den man von vielen Teams hört wenn man sie fragt wie sie ihre Arbeitsabläufe organisieren. Häufig wird diese Aussage ergänzt durch eine zweite: "Wir arbeiten stattdessen nach Scrum." (oder Kanban oder XP). Eine schwierige Selbstwahrnehmung. Selbst wenn sie für einen Agilisten auf den ersten Blick naheliegend wirkt - tatsächlich zeugt sie von einigen Missverständnissen.

Um mit dem naheliegendsten anzufangen: natürlich gibt es einen Prozess. Sobald man eine Tätigkeit ausübt die auch nur in Ansätzen widerholbare oder vergleichbare Ergebnisse erzeugt wird es fast zwangsläufig sein bestimmte Schritte regelmässig zu wiederholen. In einem berechenbaren Umfeld kann das z.B. standardisierte Akkord-Arbeit sein, in einem unberechenbaren Umfeld ein schneller Wechsel von kleinteiliger Mehrwerterzeugung und schnellen Überprüfungs- und Anpassungsschritten.

Was beidem gemeinsam ist (und allen dazwischen liegenden Abstufungen auch) - es handelt sich dabei um einen Prozess im wahrsten Sinne des Wortes, also eine Aneinanderreihung definierter Ver- oder Bearbeitungsschritte mit dem Ziel ein Produkt oder eine Dienstkeistung zu erzeugen. Selbst die häufig postuliertes Alternative "ich überlege einfach bei jeder neuen Aufgabe was das sinnvollste Vorgehen sein könnte" ist bei näherer Betrachtung nichts anderes.

Was lediglich die Besonderheit im zuletzt genannten Beispiel (und bei Scrum, Kanban, XP, etc.) ausmacht ist, dass diese Prozesse relativ minimalistisch sind. Es gibt nur wenige harte Regeln wie die Lieferung in Sprints oder die  WIP-Limits, und es bleibt den Anwendern selbst überlassen wie deren Einhaltung sichergestellt wird. Das wirkt wie laissez-faire, ist aber im Grunde besonders rigoros - der Hintergrund dieser Freiheit ist, dass jedes Mittel zulässig sein soll um die harten Regeln einhalten zu können.

Dass darin kein Prozess gesehen wird liegt an einem zweiten Missverständnis: dem, dass Prozesse immer umfassend und detailliert sein müssen. Das gibt es zwar auch, dieser Typ, der starre Prozess, ist aber nur einer von mehreren. Er macht nur innerhalb von bestimmten Rahmenbedingungen Sinn, vor allem innerhalb des oben genannten hochgradig berechenbaren und in seinem Verhalten vorhersagbaren Umfelds.

Dort wo die Rahmenbedingungen unberechenbarer sind macht ein anderer Typ Sinn, der agile Prozess, der dann nochmal in zwei Untertypen zerfällt: der erste ist ebenfalls bereits weiter oben genannt, in ihm sind wenige Parameter hart vorgegeben, der Weg zu ihrer Erreichung aber nicht. Im anderen ist auch der Prozess selbst Gegenstand seines eigenen Verbesserungs- und Anpassungsfortschritts.¹ Beides wird durch einen möglichst geringen Detaillierungsgrad einfacher.

Um noch mit einem letzten grossen Missverständnis aufzuräumen: häufig wird zwar die Notwendigkeit schlanker Prozesse anerkannt, die Benennung als Agiler Prozess aber nicht, mit der Begründung, dass die Verfasser des Agilen Manifests sich doch gerade von Prozessen hätten freimachen wollen. In solchen Diskussionen empfiehlt sich immer ein Verweis auf die zweite Seite des Manifests. Auf ihr werden agile Prozesse mehrfach erwähnt.

¹Häufige Anwendungs-Varianten dieser zwei Typen sind Scrum und Kanban