Die Illusion von Agilität: Wenn die Struktur nicht wirklich agil ist

Ihr seid seit vielen Jahren in Change-Projekten unterwegs. Was ist für Euch ein erstes Indiz dafür, dass eine agile Struktur nur scheinbar agil ist?

Wolfgang: Bottlenecks bei Entscheidern sind ein Anzeichen dafür, dass Agilität nicht wirklich gelebt wird. Solution Architects mit randvollem Terminkalender lassen mich deshalb sofort aufhorchen. Diese Überlastung rührt unter anderem daher, dass das Management an Entscheidungsterminen teilnimmt. Dort sind sie aber eigentlich nicht an der richtigen Stelle.

Jörg: Die Idee von Agilität ist es, dass Entscheidungen dort getroffen werden, wo sich die meisten Informationen befinden, und das ist in der Regel auf der Arbeitsebene. Das Management sollte sich daher darauf konzentrieren, Themen in kleinere Pakete aufzubrechen, die auf Arbeitsebene entschieden werden können. Ist dieser Rahmen gesteckt, dann sind Teams in der Lage agil – also autonom – zu arbeiten. Wichtig sind auch die entsprechenden Zielableitungen!

Trefft Ihr oft auf solch ein fehlendes oder falsches Verständnis von Agilität?

Jörg: Doch, ja. Oft werden Teams in der Erwartung losgeschickt, dass sich beispielsweise eine Softwareentwicklung schneller und günstiger durchführen lässt. Die Vermengung von Wasserfall und Agilität ist auch ein Hinweis. Es wird dann oft von Agilität gesprochen, aber Wasserfall gelebt. Man merkt es daran, wenn in den ersten Sprints nur Konzepte diskutiert werden und es keine greifbaren Ergebnisse – also konkrete Funktionalität und Komponenten – für den Auftraggeber gibt. In solchen Fällen holen wir das Management zunächst ab und klären, was Agilität eigentlich bedeutet: eine autonome Arbeitsform mit direkter, schneller Einbindung des Adressaten, der sofort Rückmeldung geben kann. Ergebnisse entstehen dadurch nicht unbedingt schneller, dafür aber mit einem nachhaltigen Wert.

Wolfgang: Agilität heißt, Adressaten – sei es User*innen oder Kund*innen – mit auf die Reise zu nehmen, im unmittelbaren Dialog Kundennutzen zu erzeugen und durch kontinuierliches Feedback seinen Weg, den man geht, anzupassen. Agilität kennt keine langfristigen Planungen, sehr wohl aber konkrete Zieldefinitionen, aus denen man Handlungen ableitet – mehr dazu auch in dem Artikel: 10 häufige Fehler bei der Applikationsmodernisierung und ihre Vermeidung. Das Konzept hilft, das Verständnis untereinander zu verbessern, um bessere Ergebnisse für den Anwender, zum Beispiel Produkte, herzustellen. Agilität erfordert daher ein Umdenken auf allen Ebenen; das Wichtigste hierbei: Das Management muss die Arbeitsebene befähigen, Entscheidungen im Sinne des Unternehmens fällen zu können. Dazu gehören auch die richtigen Leitplanken.

Welche Anzeichen deuten noch darauf hin, dass eine agile Struktur nur vermeintlich agil ist?

Jörg: Mangelnder Fokus auf den Kundennutzen und fehlende Lieferfähigkeit sind zwei Auswirkungen des eben angesprochenen fehlenden Verständnisses von Agilität. Eine Grundidee von Agilität ist es, sich für jeden einzelnen Sprint die Frage zu beantworten: Was will ich (greifbares) erreichen, was bringt es den Kund*innen? Konkret also: Was will ich in einer System Demo oder, wenn man in SAFe™ (Scaled Agile Framework) ist, nach einem PI (Planning Interval), vorstellen? Da ist man dann auch gleich bei der Lieferfähigkeit, denn bei Agilität geht es auch darum, immer wieder greifbare Ergebnisse zu erzielen, die den Kundennutzen darstellen. Ständig Konzepte entwickeln ist deshalb nicht zielführend. Man muss natürlich ein konzeptübergreifendes Bild erarbeiten, sich aber dann darauf konzentrieren, konkrete Ergebnisse zu entwickeln, um Feedback zu erhalten und gemeinsam die nächsten Schritte gehen zu können.

Wolfgang: Die Lieferfähigkeit wird auch durch Anforderungen von der Seite beeinträchtigt. Ursache dafür ist oftmals, dass Stakeholder zu spät eingebunden werden, so dass sich Management- und Arbeitsebene in unterschiedlichen Phasen befinden. Ein Beispiel: Die Arbeitsebene will für die IT-Security bereits die technische Umsetzung entwickeln, während die Stakeholder erst anfangen, sich mit dem Thema zu beschäftigten. Ein MVP (Minimum Viable Product) hilft, Asynchronitäten im Entwicklungsprozess zu vermeiden. Man sollte mit einem relativ kleinen MVP anfangen, erste Oberflächen entwickeln, die man mit den Kund*innen abstimmt, und einzelne Themen wie IT-Security zum richtigen Zeitpunkt bearbeiten und lösen. Das motiviert alle Beteiligten und macht es einfacher sicherzustellen, dass hinter jeder Aktivität ein Kundennutzen steckt.