Agilität zählt seit mehr als einem Jahrzehnt zu den zentralen Themen in der Softwareentwicklung. Dennoch stellen viele Unternehmen fest, dass die erhofften Ziele nicht erreicht werden und die versprochenen Effizienzsteigerungen ausbleiben. Im Interview sprechen wir mit Jörg Kunze und Wolfgang Vullhorst über häufige Symptome, die auf grundlegende Ursachen hinweisen, und darüber, wie diese überwunden werden können, damit das volle Potenzial einer agilen Vorgehensweise tatsächlich ausgeschöpft wird.
Indikatoren für Schein-Agilität: Bottlenecks und zentrale Entscheidungsengpässe
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!
Missverständnisse in der Agilität: Vom Wasserfall-Denken zur echten Autonomie
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.
Anzeichen für Schein-Agilität
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.
Agilität ohne Blaupause: Anpassung statt Dogma
Gibt es für Agilität eigentlich eine Blaupause?
Wolfgang: Nein, Agilität muss in jedem Unternehmen individuell adaptiert werden. Wer denkt, mit SAFe™ und SCRUM sind die Strukturen und Arbeitsweisen in Teams vorgegeben, der irrt sich. Es wird damit vielmehr ein Rahmen gesteckt, in dem man sich flexibel bewegen muss. In SCRUM sind beispielsweise neben den Dailys auch für Planning, Review, Retro im Sprint (2-3 Wochen) Regeltermine vorgesehen, die jeweils ein bis zwei Stunden dauern. Mit Teilzeitkräften ist das kaum umzusetzen. Das heißt, ich muss den Rahmen auf die Bedürfnisse der Menschen so anpassen, dass eine effiziente Zusammenarbeit ermöglicht wird, etwa indem ich Termine entzerre. Eigentlich sind Frameworks und Methodiken wie SAFe™ und SCRUM eher hinderlich für die Umsetzung einer passenden agilen Vorgehensweise – wenn diese dogmatisch eingeführt werden. Für die erfolgreiche Umsetzung ist eine flexible Denkweise erforderlich.
Jörg: Unternehmen bereitet auch die nicht sichtbare Planbarkeit Schwierigkeiten. Das liegt daran, dass sie sich von langen Planungsphasen verabschieden und hin zu einer iterativen Entwicklung von Software und Architektur bewegen müssen, die sich immer am Kundennutzen ausrichtet – denn Agilität lebt davon Prototypen, MVPs zu bauen, PoCs (Proof of Concept) zu machen, Anwender-Feedback einzuholen und darauf aufzusetzen. Eine vollständige Meilensteinplanung ist damit nicht vorgesehen – man orientiert sich maximal an einer Roadmap. Das erfordert es auch, dass man alle Stakeholder frühzeitig einbindet, damit es nicht an der notwendigen Unterstützung fehlt oder zu Anforderungen von der Seite kommt.
Herausforderungen bei der Agilitätsumsetzung: Technikfokus und fehlende Klarheit
Was sind typische Probleme bei der Umsetzung von Agilität?
Wolfgang: In vielen Projekten steht die Technik im Vordergrund, es sollten aber das Business bzw. die Prozesse maßgebend sein, weil sich nur so Werte für Kund*innen oder Nutzer*innen generieren lassen. Für Kund*innen ist es zunächst nicht interessant, was im Hintergrund passiert, also wie zum Beispiel ein Datenbankzugriff funktioniert, sondern eher wie eine Benutzeroberfläche und deren Ablauf aussieht. So kann ich auch klären, was die Kund*innen erwartet und in welche Richtung es geht. Ein anderes Problem ist, dass im betrieblichen Alltag oftmals nicht alle Stakeholder, die man braucht, mit an einem Tisch sitzen. Agiles, autonomes Agieren wird dadurch ausgebremst.
Jörg: Ein spannendes Thema ist auch das Reporting eines agilen Projekts. Sind die Stakeholder nicht mit dem agilen Konzept vertraut, dann kommt es immer wieder zu Unsicherheiten, an welcher Stelle im Projekt man sich gerade befindet. Grund für dieses Gefühl der Intransparenz beim Projektfortschritt ist, dass es keine fixen Meilensteine und Statusberichte gibt. Stattdessen hat man in agilen Projekten einen Endtermin und auf dem Weg dorthin sehr viele Sprints, bei denen Ergebnisse geliefert werden, so dass man zu einem bestimmten Zeitpunkt sagen kann, man hat diese und jene Funktionalitäten geschafft. Es ist also ein anderes Reporting, für das man erst das richtige Verständnis entwickeln muss.
Wolfgang: Wenn es Probleme in der Umsetzung von Agilität gibt, dann wächst schnell die Unzufriedenheit in agilen Teams. Man muss deshalb die richtigen Entscheidungsstrukturen aufbauen, damit Teams wirklich autonom arbeiten können, Ziele und Aufgaben konkret formulieren und das iterative Vorgehen in Feedback-Schleifen tagtäglich leben.
Jörg: Klare Zielsetzungen sind ein Muss – sie fördern auch die Zusammenarbeit zwischen agilen Teams, weil sie so beispielsweise im PI die Abhängigkeiten transparent machen können.
Wolfgang: Gute agile Teams wissen genau, in welchem Zeitraum sie was erreichen, also liefern können. Dafür benötigen sie wirklich agile Strukturen, die letztlich die Grundlage für Erfolgserlebnisse in agilen Teams und dem gesamten Projekt legen.
Jörg: Vorbereitung von Teams, Aufbau des Mindsets, Schaffen des richtigen Bewusstseins für Agilität auf der Managementebene – wir kennen aus unseren Change-Projekten alle diese Themen und wissen, wie man die Vorteile von Agilität auf die Straße bekommt.
Vielen Dank für eure Zeit, Jörg und Wolfgang!
Fazit
Abschließend lässt sich sagen, dass Agilität kein Methodenframework ist – sie erfordert ein tiefes Umdenken auf allen Ebenen eines Unternehmens. Wie Jörg Kunze und Wolfgang Vullhorst im Gespräch verdeutlichen, geht es darum, Agilität nicht nur als Arbeitsweise, sondern als fundamentalen Bestandteil der Unternehmenskultur zu etablieren. Der Schlüssel zum Erfolg liegt in der richtigen Balance zwischen Autonomie der Teams, einer klaren Zielorientierung und der frühzeitigen Einbindung der relevanten Stakeholder. Nur dann können Unternehmen die echten Vorteile der Agilität – schnellere Anpassungsfähigkeit, erhöhte Kundenzufriedenheit und langfristig nachhaltige Ergebnisse – realisieren. Wer diese Prinzipien beherzigt, wird Agilität nicht als leere Hülle erleben, sondern als kraftvollen Hebel für den unternehmerischen Erfolg.
Möchten auch Sie Agilität in Ihrem Unternehmen erfolgreich umsetzen? Kontaktieren Sie uns für maßgeschneiderte Beratung und begleiten Sie den Wandel mit echten Ergebnissen. Setzen Sie auf nachhaltige Agilität und stärken Sie Ihre Teams für die Herausforderungen der Zukunft.
Unsere Interviewpartner
Jörg Kunze ist Principal Consultant Digitalisierung mit dem Fokus auf Modernisierung. Das Gesamtbild im Auge behaltend liegt sein Fokus auf dem Anteil Mensch im Gesamtsystem – die Themen Organisation, Prozesse, methodisches Vorgehen, der notwendige Change als kritische Faktoren im Rahmen der Transformation und der Koexistenz.
In den Vorhaben begleitet er die Kunden in jedem Schritt der Umsetzung – durch eine hybride Berufserfahrung – sowohl im Businessbereich als auch in der IT, kann er in allen Domainen und Ebenen Dinge verändern und bewegen.
Wolfgang Vullhorst ist Business Consultant und Lead Architect im Bereich Modernization bei Fujitsu. Sein Fokus liegt auf der Modernisierung von Mainframe-Architekturen. Er sorgt dafür, dass das Vorhaben ganzheitlich betrachtet wird und den Faktor Mensch nicht außen vor lässt. Er begleitet Kunden von der Planung bis hin zur konkreten Umsetzung und nimmt dabei alle Beteiligten mit auf die Reise. Seine Themenschwerpunkte „Solution Architektur“ und „Agile Methoden“ ermöglichen es ihm, jederzeit die Details im Blick zu haben und auf Augenhöhe mit Experten zu diskutieren.
