Der agil-industrielle Komplex (II)
Wir müssen noch einmal zu einer der unschöneren Gruppen hauptberuflicher Agilisten kommen, dem agil-industriellen Komplex. Zur Erinnerung: er umfasst Zertifizierungsorganisationen, die von Trainings-Anbietern finanziert werden, welche von Unternehmensberatungen für wirkungslose Pseudo-Transformationen instrumentalisiert werden, die wiederum von Unternehmen beauftragt werden, deren interne Prozesse eher auf schnelle Scheinerfolge als auf nachhaltige Veränderungen ausgelegt sind.
Die problematischen Auswirkungen dieser Kommerzialisierungs-Maschinerie dürften mittlerweile in allen Bereichen des agilen Arbeitens spürbar sein, hier soll es aber um eine besonders folgenschwere gehen: die Aufblähung der ursprünglisch schlanken agilen Frameworks zu umfangreichen, schwergewichtigen Regelwerken, die von ihren (oft unfreiwilligen) Anwendern eher als Belastung und weniger als Hilfe empfunden werden - und schon gar nicht als Erleichterung.
Die Hauptursache dieser Entwicklung sind einmal mehr die Zertifizierungen, die die Haupt-Einkommensquelle und den Haupt-Ergebnistyp des agil-industriellen Komplexes bilden. Der für sie zu entrichtende drei- bis vierstellige Preis muss gerechtfertigt werden, was bedeutet, dass in allen von ihnen relevantes Wissen vermittelt werden muss. Relevant wird das durch seinen offiziellen Status, und um den zu erreichen, muss das Wissensgebiet (halb-)offizieller Teil eines Frameworks werden.
Wie diese Aufblähung aussieht, kann sich von Fall zu Fall unterscheiden, der offensichtlichste Weg ist aber, möglichst viel in den offiziellen Umfang eines zu vermarktenden Vorgehensmodells aufzunehmen. Das bekannteste Beispiel dafür ist SAFe, dessen Dokumentation mittlerweile eine deutlich dreistellige Seitenzahl umfassen dürfte, auch Disciplined Agile entwickelt sich seiner Übernahme durch PMI erkennbar in diese Richtung.
Einen anderen Weg sind Scrum Alliance, Scrum.org und Kanban University gegangen, deren eigentliche Regelwerke (Scrum Guide und Kanban Guide) sind mit ca 10 Seiten noch immer sehr komprimiert. Was bei ihnen aber dazukommt ist eine grosse Menge an "offiziellem" Zusatz-Material für die sinngemässe Auslegung, Anwendung oder Einbettung in andere Kontexte (z.B. Scrum + OKRs oder Kanban + Legal), wodurch der Gesamtumfang auch hier erheblich angewachsen ist.
Eine dritte Variante Kommerz-getriebener Aufblähung kann man schliesslich bei Frameworks beobachten, die keiner Organisation zugeordnet sind, sondern gewissermassen Open Source. Hier erfinden Beratungen und Schulungsanbieter ständig neue Elemente, kopieren sie voneinander und erklären sie zur notwendigen "best Practice". Der bekannteste derartige Fall sind zur Zeit die OKRs, deren Kommerz-Variante stark mit Meetings, Rollen und Regeln überfrachtet ist.
Eine spezielle und in allen Varianten vorhandene Art der Aufblähung besteht schliesslich in Form von prozessunterstützender komerzieller Software, die im Rahmen vieler "agiler Transitionen" den Anwendern der agilen Frameworks zwingend vorgeschrieben wird (Beispiele sind Jira für Scrum oder Workboard für OKRs). Da in diesen Kontexten das Vorgehen und die Software untrennbar miteinander verknüpft sind, wird das Wissen um die Software-Funktion de facto Teil des Methodenwissens.
Wie oben erwähnt, für die Anwender ist eine derartige Aufblähung in der Regel eine Belastung. Zum einen dadurch, dass alleine die Aneignung und das in Erinnerung halten eines derartig umfangreichen Wissensumfangs mit Aufwand und Anstrengung verbunden ist, zum anderen dadurch, dass der aufbauend darauf gestaltete Arbeitsalltag von zahlreichen Pflicht-Meetings, komplizierten Regeln und restiktiven Workflows der jeweiligen Anwendungen geprägt ist.
Häufige Reaktionen auf diese Belastung sind Frustration, Dienst nach Vorschrift, der heimliche Aufbau von "Schattenprozessen", mit denen sich die ungeliebten offiziellen Methoden umgehen lassen (deren unnötige Aufblähung den meisten gar nicht bewusst ist) oder ganz einfach der Verlust von Freude an der Arbeit und der Identifikation mit dem eigenen Unternehmen. Konsequenzen deren sich jeder bewusst sein sollte, der sich mit dem agil-industriellen Komplex einlässt.
Um mit einer positiven Note zu enden: es gibt einen Ausweg aus dieser Situation, und der besteht ganz schlicht daraus, zuerst aufzuzeigen, wie die jeweiligen agilen Frameworks eigentlich gedacht sind, und was alles nicht notwendig ist um sie so wie gedacht einzusetzen. Dieser überschüssige Teil, der z.B. im Fall von Kanban oder OKRs alle (!) neu eingeführten Rollen, Meetings und Software-Tools umfassen kann, kann einfach weggelassen werden - und nur dadurch wird bereits vieles einfacher und schneller.
Natürlich braucht es auch dazu in der Regel die Unterstützung von Experten, was eine wichtige Frage aufwirft: wie lässt sich sicherstellen, dass nicht auch die dem agil-industriellen Komplex angehören? Die einfache Antwort: man sollte nur diejenigen in die nähere Auswahl nehmen, deren Lösungen werder Zertifizierungen, noch prozessunterstützende Software, noch umfangreiche Regelwerke oder zahlreiche neue Rollen enthalten. Less is more.
