Wege zur Agilität – Agile Transformation

Als vor bald 20 Jahren eine Gruppe organisations-skeptischer Software-Entwickler zum Skifahren in den Bergen des US Bundesstaates Utah zusammenkam, hatten sie selbst am allerwenigsten erwartet, ein Statement von solcher Tragweite abzugeben, nämlich das „Manifesto for agile Software Development“, welches die Art und Weise, wie Organisationen Software entwickeln seither nachhaltig verändert hat. Dass es seinen Einfluss zunehmend auch im gesamten Unternehmen geltend macht, liegt an den durchschlagenden Erfolgen, welches es in dieser abstrakten und schwer greifbaren Disziplin bewiesen hat – zu Recht?

Der agile Ansatz

Das agile Manifest basiert auf vier grundlegenden Leitsätzen:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
  
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Diese klingt erst einmal einleuchtend, und wenn man das Wort Software durch Organisation oder Prozesse ersetzt, tönt es nicht einmal mehr so nach IT. Lassen sich also die agile Prinzipien auf die gesamte Organisation übertragen, und wie?

Die Herausforderung

Die Herausforderung besteht darin, die Agilität der Organisation als Ganzes zu gewährleisten. Während im herkömmlichen Veränderungsprozess fixe Strukturen und Prozesse aus einer Phase der Stabilität heraus gelockert, einem Änderungsprozess unterzogen und danach wieder (in Form komplexer Prozesse, schwergewichtiger Tools sowie umfangreicher Schulungen samt entsprechender Dokumentationen) eingefroren werden (unfreeze – transform – freeze), geht die agile Transformation von einem Übergang zu einem System konstanten Wandels aus (unfreeze – transform – transform).

Die operative Umsetzung

Allzu oft werden bestehende Prozesse neu abgebildet, noch so ausgefallene Wünsche der diversen Anspruchsgruppen berücksichtigt, Metriken und Kontrollmechanismen eingeführt, um dann zuletzt mit einer Neuauflage der alten Konzepte dazustehen, mit den selben ineffizienten (und manchmal widersprüchlichen) Abläufen, Brüchen in der Zuständigkeit und letztendlich mangelnder Akzeptanz und Unterstützung in der Organisation.

Hier gilt es, die Abläufe so weit zu vereinfachen beziehungsweise in ihren Abhängigkeiten zu entflechten, dass sie in eine sequentielle Abfolge einzelner Schritte gegliedert werden können. Dies wird im allgemein als Pipeline bezeichnet. Diese soll sich so weit als möglich den bestehenden Rollen, Zuständigkeiten, Aufgaben und Arbeitsergebnissen orientieren. Die Organisation der Arbeitsschritte als Stufen in einer Pipeline wird im agilen Software-Engineering als Kanban Methode bezeichnet und darf nicht mit Kanban aus der PPS verwechselt werden. Kanban ist eine agile Diszplin ähnlich Scrum, und beruht auf den drei grundlegenden Prinzipien Transparenz, Inspektion und Adaption, welche hier näher erläutert werden sollen.

Transparenz

Die visuelle Darstellung der Pipeline auf einem so genannten Kanban – Board ist von herausragender Bedeutung. Dabei spielt es keine Rolle, ob dies durch Aufkleben von Post-Its auf einem Whiteboard oder Verwendung speziell dafür konzipierter Sofwtare geschieht. Wesentlich ist die damit erzielte Sichtbarkeit der Pipeline, die Transparenz.

Die Taktung der Pipeline erfolgt nach den Pull – Prinzip, das heisst es werden klare Kriterien festgelegt, wann in einer Stufe eine Aufgabe aus der vorhergehenden übernommen wird. Das heisst im Idealfall, erst nachdem eine Aufgabe erledigt ist und damit bereit für die nächste Stufe, wird eine neue aus der vorherigen geholt. Dies ermöglicht eine Begrenzung der Anzahl gleichzeitig in Arbeit befindlicher Aufgaben innerhalb einer Stufe, was wiederum die Transparenz des Prozesses erhöht. Dies bedingt allerdings auch, dass sämtliche Voraussetzungen zur Bearbeitung der Aufgabe innerhalb der Stufe gegeben sein müssen, von personellen Fähigkeiten über technische Ressourcen bis hin zu Entscheidungskompetenzen.

Inspektion

Durch die Konzeption kann die Pipeline mittels einfacher Metriken auf Ihre Effizienz überwacht werden, beispielsweise

• Anzahl bereitgestellter Aufgaben (Backlog)
• Anzahl Aufgaben in einer Stufe (Work In Progress)
• Verweildauer von Aufgaben in einer Stufe
• Anzahl an die vorherige Stufe zurückgewiesener Aufgaben

Adaption

Abweichungen der Metriken vom Idealzustand deuten auf Probleme in der Definition von Rollen, Aufgaben, Lieferobjekten innerhalb des Prozesses und werden im Rahmen einer operativen Revision mit den beteiligten identifiziert und entsprechende Anpassungen vorgenommen. Auf diese Art und Weise wird der Prozess (potentiell) einem konstanten Wandel unterzogen und damit eben agil.

Fallen und Stolpersteine

In den letzten Jahren ist eine Vielfalt an neuen Angeboten zur Unterstützung agiler Prozesse auf den Markt gelangt, viele davon als Cloud – Lösungen. Die meiste davon sind umfassend und flexibel konfigurierbar und lassen sich vielfältig anpassen. Dabei gilt es zu vermeiden, einfach die hergebrachten Verfahrensweisen auf die neuen Plattformen zu übertragen. Dies führt schnurstracks zum einem System, bei welchem man nicht weiss, ob auch der Realität entspricht was drinsteht, weil sich alle Beteiligten irgendwie um die Fleissaufgabe herum drücken. Damit geht das agile Potential gleich wieder verloren.  Weniger ist hier mehr – wesentlich ist, dass die gewonnene Agilität zu effizienteren Prozessen und verbesserter Kommunikation zwischen den Teams führt, indem sichtbar gemacht wird wo die Schwachstellen liegen.

Beat Glattfelder

Beat Glattfelder, Informatik - Ing. ETH, blickt auf 25 Jahre Erfahrung in der Gestaltung durchgängiger digitaler Prozesse zurück. In den letzten 10 Jahren befasste er sich primär mit Techniken und Methoden agiler IT Organisationen, mit zunehmendem Fokus auf Lean Management und Agilität im Gesamtunternehmen sowie deren Relevanz für eine erfolgreiche Digitalisierungs – Strategie.