Agile tailored fits best

Die IT-Branche hat schon lange einen Konsens gebildet: Prozesse sollen agiler werden. Agilität ist heute ein zentraler Begriff in der digitalen Unternehmenswelt. Auf die Frage, wie es möglichst schnell in agile Prozesse geht, gibt es keine allgemeingültige Antwort und vor allem individuelle Ansätze erzielen gewünschte Fortschritte – ganz nach dem Motto „agile tailored fits best“.

Individuelle Ansätze sind oft der Schlüssel zum Erfolg, denn die Transformation von langjährigen Unternehmensstrukturen und etablierten Prozessen in Richtung Agilität ist komplex. Viel zu oft wird Agilität als starre Methode angesehen. Unsere Erfahrung zeigt jedoch, dass agile Modelle an die jeweiligen Unternehmensstrukturen und Abhängigkeiten angepasst werden können.

Während majestätische Wasserfälle in der Natur faszinieren, erscheint der Wasserfallprozess in der IT-Branche eher träge und trocken. Agile Teams erreichen häufig schneller und präziser die auf den Roadmaps definierten Project Goals und sind dabei erheblich flexibler. Umfangreiche Scope of work Definitionen vor Projektbeginn und häufig gehörten Sätze wie „so hatte ich es mir aber nicht vorgestellt“ gehören in der agilen Welt der Vergangenheit an. Ich möchte an dieser Stelle nicht unerwähnt lassen, dass auch Wasserfallmodelle ihre Daseinsberechtigung haben und agile Frameworks nicht immer per default besser performen müssen.

Agile Frameworks bieten Möglichkeiten zur Etablierung erfolgreicher Prozesse. Um erfolgreich von einem klassischen Ansatz auf ein agiles Modell zu transformieren, müssen etablierte Prozesse und Strukturen betrachtet und angepasst werden. Der Wechsel auf ein agiles Vorgehen ist nicht nebenher implementiert und vor allem die Entwicklung in Richtung agilem Mindset stellt eine große Herausforderung dar.

Bei der Umsetzung gelangt man häufig an den Punkt, dass Abhängigkeiten nicht kurzfristig oder in einzelnen Fällen auch gar nicht zu lösen scheinen. Dies kann sowohl an fehlenden Befugnissen der treibenden Instanzen zur agilen Transformation bestimmter Abhängigkeit im Unternehmen, mangelnder Zeit, oder auch an branchenspezifischen Gegebenheiten liegen. Unserer Erfahrung lehrt uns: „Kopf nicht in den Sand stecken“ und das Ziel verfolgen, vermeintliche Blocker langfristig aufzubrechen. Die Implementierung agiler Arbeitsmethodik ist nie abgeschlossen und es wird stetig Möglichkeiten zu Optimierungen und Anpassungen geben. Wichtig ist, dass die Prozessoptimierungen nicht stagnieren, das Ziel der Prozessoptimierung stets im Fokus bleibt und Fortschritte dauerhaft erzielt, reflektiert und auch eingefordert und gefördert werden. Welche Abhängigkeiten als „Blocker“ zwischenzeitlich akzeptabel sind, ist nicht pauschal, sondern individuell zu definieren. In einem Projekt haben beispielsweise Sicherheitsvorgaben aus der unternehmensinternen IT-Security längerfristig einige Optimierungspunkte in der Planung von Sprintzyklen blockiert. Bei einem anderen Projekt haben Unternehmensrichtlinien zu externen Beauftragungen Teile der agilen Arbeitsweise im Projekt blockiert.

Die Ausgestaltung von Prozessen unterliegt häufig der Organisationsstruktur oder wird durch sie beeinflusst. Daher sollte das übergeordnete Ziel langfristig darauf ausgerichtet sein, nicht nur innerhalb einzelner Projekte, sondern auch auf unternehmensebene Agilität zu fördern und das agile Mindset kontinuierlich zu entwickeln, um optimale Ergebnisse aus der agilen Entwicklung zu erzielen.

In den zuvor genannten Fällen haben wir festgestellt, dass es zielführend sein kann, agile Modelle kurz- oder mittelfristig an die spezifischen Gegebenheiten „zuzuschneiden“. Oftmals ist der Mehrwert durch die Entwicklung in Richtung Agilität schnell ersichtlich und kann genutzt werden, um bestehende Blocker durch messbare Verbesserungen und positive Entwicklungen und Ergebnisse infrage zu stellen. „Quick Wins“ können um die Blocker herum definiert werden, um möglichst schnell Fortschritte zu erzielen, ohne die Umstellung auf agile Modelle kurz-, mittel- oder gar langfristig stoppen zu müssen. In vielen Fällen verlieren vermeintliche Blocker an Bedeutung, sobald sie umgangen und Fortschritte transparent gemacht wurden. Bei jeder agilen Transformation wird eine Lernkurve zu beobachten sein, diese gilt es aktiv im Auge zu behalten und zu reflektieren.

Ein weiterer Aspekt des „Agile Tailoring“ ist das „Zuschneiden“ von agilen Modellen, basierend auf Erfahrungswerten aus der bereits implementierten agilen Methodik. Dabei sollten die Modelle im Prozesskern möglichst unverändert bleiben, an vielen Stellen bieten sie auch Spielraum für individuelle Gestaltung. Dieses Vorgehen sollte nicht dem Gedanken der vordefinierten Frameworks widersprechen. Ziel ist es, durch das Zuschneiden, den größtmöglichen Nutzen aus dem Framework für die vorliegenden Gegebenheiten zu ziehen. Durch die Anpassung agiler Frameworks besteht das Risiko, den Mehrwert dieser Frameworks zu reduzieren. Daher sollten Anpassungen stets sorgfältig evaluiert, bewusst entschieden und kontinuierlich bewertet sowie reflektiert werden. Wenn spezifische Bestandteile, beispielsweise aus dem Scrum-Framework, einzeln verwendet oder gezielt entnommen werden, kann nicht mehr von der Anwendung von “Scrum” gesprochen werden. Dennoch lässt sich dadurch eine Entwicklung in Richtung agilem Arbeiten oder auch Optimierungen für spezifische Gegebenheiten realisieren. Dabei zieht jedes Projekt und jedes Projektteam eine ganz individuelle Grenze zwischen „das steht im Framework und muss so sein“ und „diesen Teil können wir für unsere Prozesse anpassen oder gar optimieren“.

In agilen Modellen wie Scrum gibt es feste Vorgaben, aber auch Empfehlungen, die an die individuellen Bedürfnisse angepasst werden können. Ein Beispiel für eine Definition zur Teamgröße aus dem Scrum Guide zeigt, dass gewisse Spielräume bereits in den Modellen enthalten sind: „…typically 10 or fewer people.“  (Quelle: https://scrumguides.org/scrum-guide.html). In einem unserer Projekte arbeiteten wir mit 15 Teammitgliedern und entschieden uns nach sorgfältiger Prüfung, unter Berücksichtigung der Geschwindigkeit und einer Kosten-Nutzen-Abwägung, bewusst gegen eine Aufteilung in zwei Teams. Diese Entscheidung kann im Sinne der Agilität, während der laufenden Prozesse, jederzeit neu bewertet werden und in Zukunft zu einem abweichenden Ergebnis führen.

Die Vielfallt der agilen Frameworks und darin definierten Prozesse zeigt uns, dass es keine allgemeingültige agile Best-Practice-Lösung für alle Unternehmen und Projekte gibt. Unserer Überzeugung nach ist es essenziell langfristig unternehmens- und teilweise projektspezifisch agile Ansätze zu prüfen und zu entwickeln. Definierte Prozesse und Methoden sollten auf verschiedene Projekte in einem Unternehmen adaptierbar sein, um nicht für jedes Projekt individuelle Prozesse zu definieren. Dennoch kann es nötig sein auf Projektebene Abweichungen zum „Standardprozess“ zu diskutieren und zu bewerten, um für jedes Projekt das bestmögliche Vorgehen zu etablieren.

Neben einem fest im Team definierten Scrum Master kann ein übergreifender und unabhängiger Agile Coach kurz- bis langfristig bei der Transformation in die Agilität sehr hilfreich sein. Er kann beim Aufsetzen, Reviewen oder Überwachen entsprechender Prozesse und Entwicklung eines agilen Mindset in enger Zusammenarbeit mit dem Management, beteiligten Stakeholdern und den Projekt- und Produktverantwortlichen unterstützen.