Ist Agil gleich Chaos?

Agile Projekte gewinnen im Vergleich zu Wasserfallprojekten an Bedeutung. Agilität wird in der Softwareentwicklung gerne mit Veränderung, Flexibilität, kürzerem Time-to-Market, Eigenverantwortung etc. in Verbindung gebracht.  Das klingt positiv - und wenn es richtig gemacht wird, ist es das auch - selbst wenn Rückschläge vorprogrammiert sind. Es gibt viele gängige Definitionen dafür, was "Agilität" bedeutet und viele Unternehmen bzw. Agilisten haben ihren ganz eigenen Ansatz. Eines jedoch ist sicher: Agilität ist KEIN Chaos!

Was Agilität NICHT ist

Agilität bedeutet nicht, zu tun, was man will, wann man will und wie man will. Es bedeutet weder, dass selbstorganisierte Teams keine Führungspersonen brauchen, noch, dass gearbeitet wird ohne nachzudenken bzw. zu planen.

Agil zu arbeiten bedeutet auch nicht, auf jede erdenkliche Veränderung sofort zu reagieren, nur weil man könnte. Nach Scrum etwa wird "nur" nach jedem Sprint reagiert, und dieser dauert in der Regel 2-4 Wochen. Während des Sprints sollen Arbeitspakete und Vereinbarungen unverrückbar sein, nichts spontan geändert, hinzugefügt oder entfernt werden. Beim Lean- oder Kanban-basierten Ansatz ist zwar eine „Fastlane“ für veränderte Umstände vorgesehen, aber auch das Pensum für die „Fastlane“ ist begrenzt. 

Nun mag man sich fragen, warum ich das Selbstverständliche erkläre. Wenn mich meine Beratungserfahrung als agiler IT-Experte eines gelehrt hat ist es, dass Teams und Organisationen sehr oft Regeln und Abmachungen über Bord werfen und bei dem Versuch, agile Prinzipien anzuwenden, ins Chaos abgleiten.

Was ist das Problem?

Wenn ich auf Führungsebene diskutiere habe ich oft das Gefühl, dass die Wahrnehmung dessen, was Agilität ist, sehr weit von der Realität entfernt ist. Das Management hat Schlagworte im Kopf, vernachlässigt aber die erforderlichen Grundsätze. Den Teams werden permanent Fokuswechsel und neue Team-Zusammensetzungen zugemutet, oder wider besseren Wissens immer neue Stories in den Sprint-Backlog gepresst. Manche versuchen zwar den agilen Wandel zu fördern, sparen aber am Budget, sei es für agile Coaches, Scrum-Master, Schulungen, indem Rollen gekürzt oder Teammitgliedern Doppelfunktionen zugeordnet werden. 

Lassen Sie uns neben dem Management auch einen Blick auf die Teams werfen. Wer sich nicht an Dinge wie Timeboxing oder „Definition of Done“ hält oder ständig zu spät zum Stand-up kommt, gefährdet den Erfolg genauso. Ein Beispiel, das ich selbst als Scrum Master erlebt habe: Das Team entschied damals gemeinsam mit dem Management die Retrospektiven dauerhaft abzuschaffen. Man wollte die so gewonnene Zeit nutzen, um weitere Stories zu implementieren. Dabei war noch kein einziger Sprint wie geplant beendet worden! Anstatt dies in der Retro zu besprechen und Gegenmaßnahmen zu suchen, verpflichtete man sich zu noch mehr Arbeit. Die war natürlich nicht zu bewältigen, das resultierende Chaos unvermeidlich.

Wir wirkt sich das Chaos aus? 

Betrachten wir das Scrum-Framework können wir festhalten: Der teils strenge Rahmen verlangt viel Disziplin, Ehrlichkeit, Offenheit, Selbstkritik und Eigenverantwortung. Zumindest in den ersten Sprints sollten die Teams befähigt und angeleitet werden, sich wirklich an die Regeln, Rollen und Rituale zu halten. Nur so kann das Team sie kennenlernen und aus den Fehlern lernen. Das Schöne an der Agilität ist, dass die Teams die Regeln und Rituale an ihren Stil anpassen können, die ursprüngliche Essenz sollte aber erhalten bleiben. Wer Teams von Anfang an in ihrem Streben behindert, nimmt ihnen die Chance den "richtigen Weg" zu erlernen, was oft zu einem chaotischen Arbeitsstil führt.

Ist der Schaden erst entstanden, kann es herausfordernd sein, wieder auf Kurs zu kommen. Negative Stimmung und ständiger Druck des Managements fördern weder Teammotivation noch Erfolg. Rasch rücken die agilen Kritiker im Unternehmen auf den Plan. Sie wussten ja immer schon: "Agilität funktioniert nicht." In weiterer Folge überdenkt das Management seine Bereitschaft den agilen Wandel zu unterstützen, was wiederum die Mitarbeiter in drei Gruppen spaltet. Eine, die gerne den agilen Weg gehen möchte, eine, die nicht dazu bereit ist und eine, die es nicht einmal interessiert. Damit haben Sie das perfekte Rezept für Chaos, Missverständnisse, Blockaden und schlechte Laune.

Wer halbherzig an die Sache herangeht oder Prinzipien anwendet, deren Bedeutung nicht vollständig verstanden werden, hat es schwer, die Früchte der agilen Softwareentwicklung zu ernten und erreicht mitunter sogar den gegenteiligen Effekt. Der Software-Lebenszyklus wird noch undurchschaubarer und schwieriger zu messen. 

Sie können das lösen!

Zunächst müssen alle – Personen, Teams und Stakeholder – erkennen und eingestehen, wenn sie in die "Chaos-Falle" geraten sind. Versuchen Sie ehrlich zu beurteilen, ob Ihr agiler Prozess wie geplant abläuft. Sprechen Sie mit Kollegen, sammeln Sie unterschiedliche Standpunkte und nutzen Sie regelmäßige, geplante Retrospektiven, um Fragen aufzuzeigen und zu diskutieren. Jede Meinung ist dabei wertvoll! 
Scheuen Sie sich nicht ein paar Schritte zurückzugehen und versuchen Sie die Dinge noch einmal richtig zu machen - auch wenn das bedeutet den Backlog auszudünnen, neu zu sortieren oder bereits getroffene Entscheidungen zu überdenken. Holen Sie das Management an Bord, beziehen Sie es ein, etwa wenn agile Meetings stattfinden. Verschweigen Sie nicht, dass Sie, Ihr Team oder Ihre Organisation Fehler gemacht haben - dies ist Teil der agilen Lernkurve und nur durch das Eingeständnis der Fehler können Sie sich anpassen und verbessern.

Besonders zu Beginn agiler Transformationen erscheint es oft, als wäre man bereits im Chaos-Modus. Eine gesunde Dosis an Unsicherheit ist normal und sogar nötig, um die Kultur Ihres Unternehmens und Ihre Arbeitsweise zu verändern. Gibt es keine merklichen Anzeichen, dass sich der neue Arbeitsmodus stabilisiert, hilft ein erfahrener Agile Coach. Er kann mit seiner unabhängigen, neutralen Sicht zum Erkenntnisgewinn beitragen, um einen vorübergehende Chaos-Modus zu überwinden.