Business-IT
01.02.2019
Zwischen Mode und Notwendigkeit
1. Teil: „Der lange Weg zum agilen Unternehmen“

Der lange Weg zum agilen Unternehmen

Agiles UnternehmenAgiles UnternehmenAgiles Unternehmen
Jesus Sanz / shutterstock.com
Um den digitalen Wandel zu überleben, müssen Unternehmen ihre Firmenkultur verändern. Ein sinnvoller Ansatz ist die agile Arbeitsweise. Ein Allheilmittel ist das jedoch nicht.
  • Vorteile: Geht ein Unternehmen zu agilen Entscheidungsprozessen über, dann hat das positive Folgen auf eine Reihe von Ebenen - vom Mitarbeiter-Engagement bis zur Experimentierfreudigkeit.
    Quelle:
    Sopria Steria Cunsulting, "Potenzialanalyse agil entscheiden", 2018 (n = 302)
Fachwissen, Erfindungsreichtum, Ingenieurskunst und sorgfältige Planung sind die Voraussetzungen für wirtschaftlichen Erfolg, davon sind gerade in Deutschland viele Unternehmenslenker überzeugt.
Doch langsam machen sich auch unter ihnen Zweifel breit. Neue Geschäftsmodelle und Wettbewerber tauchen wie aus dem Nichts auf und fegen Traditionsunternehmen vom Markt. „Die Digitalisierung führt zu veränderten Kundenbedürfnissen und Markterfordernissen, die Komplexität nimmt zu“, bringt Svenja Hofert den grassierenden Wandel auf den Punkt. Sie bietet als Geschäftsführerin der Teamworks GTQ GmbH (Gesellschaft für Teamentwicklung und Qualifizierung) unter anderem Workshops zu agilem Führen an und hat schon mehrere Bücher zu diesem Thema geschrieben.

Kompliziert oder komplex?

Um die besonderen Herausforderungen komplexer Umgebungen zu verstehen, wie sie heute in Wirtschaft und Industrie vorherrschend sind, können Konzepte wie das „Cynefin Framework“ helfen, das der britische Berater und Wissenschaftler Dave Snowden entwickelt hat. Es unterscheidet prinzipiell zwischen einfachen, komplizierten, komplexen und chaotischen Zuständen und gibt für jeden Bereich Managementempfehlungen.
Einfache Szenarien zeichnen sich demnach durch klare Ursache-Wirkungs-Zusammenhänge aus. Sie lassen sich durch simple Rezepte lösen. „Für eine einfache Aufgabe brauche ich keine lange Planungsphase“, erklärt Daniel Dubbel, Senior-Berater für Arbeit 4.0, Agilität und Projektmanagement bei DB Systel. In Unternehmen stellen einfache Szenarien Mitarbeiter und Führungskräfte nicht vor große Herausforderungen. Abweichungen vom Sollzustand lassen sich leicht identifizieren, kategorisieren und mit den in der Vergangenheit gesammelten Erfahrungen lösen.
Auch bei komplizierten Problemen gibt es einen Zusammenhang zwischen Ursache und Wirkung, er ist jedoch nicht so offensichtlich und kann sich über viele Zwischenstufen erstrecken. Snowden nennt dies das „Reich der bekannten Unbekannten“. Herausforderungen lassen sich nicht einfach kategorisieren und nach Schema F abarbeiten, sie müssen diagnostiziert und analysiert werden. Auch kann es mehrere richtige Antworten und geeignete Wege zum Ziel geben.
Die Lösung komplizierter Probleme durch Ingenieure und andere Experten ist wiederum typisch für die industrielle Revolution, die im 18. Jahrhundert begann und sich über die zunehmende Elektrifizierung und Mechanisierung der Produktion bis hin zur Entwicklung der Mikroelektronik im 20. Jahrhundert fortsetzte. Dampfmaschinen, automatische Webstühle und Automobile sind einige der Beispiele für komplizierte Maschinen. Einfache und komplizierte Aufgaben werden nach Ansicht von Daniel Dubbel zukünftig überwiegend von Maschinen erledigt werden: „Roboter können beispielsweise Autos viel schneller und effizienter zusammenbauen als Menschen am Fließband.“
Während es bei komplizierten Fragestellungen mindestens eine richtige Antwort gibt, ist dies in komplexen Umgebungen anders. Dave Snowden nennt als Beispiel den Unterschied zwischen einem Ferrari und dem brasilianischen Regenwald: Das Auto lässt sich in seine Einzelteile zerlegen und mit der notwendigen Erfahrung wieder zu einer funktions­fähigen Einheit zusammensetzen. Der brasilianische Regenwald funktioniert dagegen nur als Ganzes.
Die Wechselwirkungen der einzelnen Bestandteile sind komplex, eine Vorhersage, welche Auswirkungen das Aussterben einer Art, die Abholzung eines Gebiets oder der Klimawandel auf das Gesamtsystem haben wird, ist nicht etwa nur schwer zu treffen – sie ist vielmehr schlichtweg unmöglich. „Je komplexer die Anforderungen, desto weniger funktionieren herkömmliche Planungstechniken und Managementkonzepte“, erklärt Svenja Hofert von Teamworks GTQ.
Umweltkatastrophen, Flugzeugabstürze und andere Krisen sind dagegen typische Fälle für chaotische Systeme. Während selbst in komplexen Umgebungen Ursache und Wirkung in einem geordneten Zusammenhang stehen, ist dies im Chaos nicht mehr der Fall. Hier geht es im Wesentlichen darum, Schaden zu begrenzen und Handlungsfähigkeit wiederherzustellen. Krisenmanagement erfordert entschlossenes Handeln, klare Anweisungen und direkte Kommunikation. Diskussionen oder das Hinterfragen von Entscheidungen ist erst in der Nachschau möglich und sinnvoll.
Scrum - ein agiles Vorgehensmodell
Das für agile Software-Projekte entwickelte Rahmenwerk
Scrum findet heute auch in vielen anderen Bereichen Anwendung. Es besteht im Wesentlichen aus diesen Bestandteilen:
Sprint: Projekte werden in kurze, aufeinander aufbauende Arbeitsabschnitte, sogenannte Sprints, eingeteilt, die jeweils zwischen einer und vier Wochen dauern. Zu Beginn jedes Sprints wird im Sprint Planning festgelegt, was im kommenden Arbeitsabschnitt wie zu erledigen ist. Am Ende des Abschnitts überprüft das Team im Sprint Review, ob die Ziele erreicht wurden. Ebenfalls am Ende jedes Sprints steht die Sprint-Retrospektive, in der das Team seine Arbeitsprozesse überprüft und gegebenenfalls Verbesserungen vereinbart. Während des Sprints treffen sich die Mitglieder täglich zu Arbeitsbeginn im Daily Scrum, um Informationen auszutauschen und sich einen Überblick über den Stand des Sprints zu verschaffen.
Product Owner: Der Product Owner ist für den Erfolg des Produkts verantwortlich. Er definiert die Produkteigenschaften, priorisiert sie und hält sie im Product Backlog fest, das beständig fortgeschrieben und nach jedem Sprint angepasst wird. Der Product Owner ist kein Teil des Entwicklerteams.
Scrum Master: Der Scrum Master sorgt dafür, dass die Scrum-Regeln eingehalten werden, und unterstützt bei Problemen oder Störungen in der Kommunikation und Zusammenarbeit.  Der Scrum Master ist mehr Coach als Führungskraft. Er gibt keine Anweisungen und hat auch keine disziplinarischen Kompetenzen. Auch der Scrum Master ist kein Mitglied des Entwicklungsteams.
Entwicklungsteam: Im eigentlichen Entwicklungsteam arbeiten drei bis neun Teammitglieder möglichst interdisziplinär zusammen. Es definiert gemeinsam die Ziele für die Sprints, verteilt die Arbeiten und organisiert sich selbst.
Definition of Done (DoD): In der DoD vereinbart das Scrum-Team, nach welchen Kriterien ein Arbeitsschritt als erfolgreich abgeschlossen definiert wird.
2. Teil: „Agile Antworten“

Agile Antworten

  • Keine Raketenwissenschaft: Agile Projekte lassen sich mit einfachen Mitteln organisieren, zum Beispiel mit einer Wand und Post-it-Zetteln.
    Quelle:
    EOS / Holger Koschek
Warum die Unterscheidung zwischen den Szenarien keine bloß theoretische Angelegenheit ist, sondern essenziell wichtig für Unternehmen und IT, macht ein Blick auf die Herausforderungen deutlich, die sich aktuell stellen. Die meisten sind nämlich komplexer Natur: Langfristige Planungen werden immer schwieriger, Ziele müssen ständig revidiert werden, und ob ein Produkt oder eine Dienstleistung erfolgreich ist, hängt immer stärker von den sich permanent ändernden Rahmenbedingungen ab.
In der Software-Branche ist diese Entwicklung schon seit vielen Jahren ein Thema. Denn die klassische Wasserfall­methode mit langen Planungsphasen, aufeinanderfolgenden Projektschritten und klaren Zieldefinitionen war einst für komplizierte Probleme entwickelt worden, in großen, komplexen Software-Projekten stößt sie jedoch an ihre Grenzen.
Je größer die Zahl der Komponenten und je umfangreicher die Abhängigkeiten von anderen Systemen, desto weniger lassen sich Prozessfortschritte und Ergebnisse im Detail planen. Hinzu kommt, dass sich die Marktbedingungen immer schneller ändern, sodass sich Projektziele nicht mehr Jahre im Voraus festlegen lassen.
Die Unzufriedenheit mit den herkömmlichen Planungsmethoden resultierte 2001 im schon legendären „Agilen Manifest“. Es fasst die wichtigsten Werte der agilen Software-Entwicklung zusammen: Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge, Funktionen wichtiger als Dokumentation, die Zusammenarbeit mit Kunden ist wichtiger als Verträge und die flexible Reaktion auf Veränderungen hat Vorrang vor dem strikten Befolgen eines Plans. Statt Meilensteine abzuarbeiten, wirken erreichte Ziele und die damit gemachten Erfahrungen auf die weitere Planung zurück, das Vorgehen ist iterativ und nicht mehr linear wie im Wasserfallmodell.
Frameworks wie Scrum folgen den Ideen des agilen Manifests und geben ihm einen Rahmen. Längst werden sie nicht mehr nur in der Software-Entwicklung, sondern auch in anderen Unternehmensbereichen eingesetzt, in denen es um komplexe Fragestellungen geht. „Für mich bedeutet Agilität im Unternehmenskontext, dass ich vorbereitet bin, vorausschauend arbeiten, in kurzen Zyklen Werte ausliefern und meine Ziele immer wieder nachjustieren kann“, beschreibt Daniel Dubbel von DB Systel seine Leitgedanken.
Ähnlich Svenja Hofert: Sie sieht als wesentliches Merkmal von Agilität den stetigen Wechsel zwischen Aktion und Reflexion: „Schnelligkeit allein ist nicht agil.“ Wer die reflexiven Phasen vernachlässige, drohe die Mitarbeiter zu überfordern und zu demotivieren und der gewünschte Effekt verkehre sich ins Gegenteil. „Das Thema Agil ist unheimlich schnell verbrannt, das habe ich oft erlebt.“
Frameworks für agile Projekte
Neben Scrum (siehe Kasten auf Seite 20) haben sich weitere Frameworks für das Arbeiten in agilen Umgebungen etabliert:
Kanban: Ursprünglich wurde Kanban in Japan entwickelt, um die Lagerhaltung von Vorprodukten und Verbrauchsmaterialien in der Produktion zu reduzieren, indem ein optimaler, kontinuierlicher und gleichmäßiger Fertigungsprozess sichergestellt wird. In der Software-Entwicklung wird das Prinzip in Form sogenannter Kanban-Boards umgesetzt, auf denen mit Hilfe von Karteikarten oder Haftnotizen der „Fluss“ eines Projekts visualisiert werden kann.
XP (Extreme Programming): Kurze Entwicklungszyklen, häufige Iterationen und stetige Kommunikation sind die Grundpfeiler von XP. Das Modell ist besonders dann gut geeignet, wenn sich die Anforderungen an die zu erstellende Software und der dafür notwendige Aufwand zu Beginn eines Projekts schwer abschätzen lassen.
SAFe (Scaled Agile Framework): Scrum wurde für kleine Teams entwickelt und ist daher für große Projekte nur bedingt geeignet. Das Scaled Agile Framework bietet eine Reihe von Rezepten und Workflow-Mustern, die typische Herausforderungen in großen Projekten wie lange Planungshorizonte, komplexe Verantwortungsstrukturen und die Koordinierung mehrerer Teams adressieren.
LeSS (Large-scale Scrum): LeSS versucht, Scrum-Prinzipien auf größere Entwicklungsumgebungen zu übertragen. Es bietet dafür zwei Ansätze: „First-Level LeSS“ ist für Projekte mit bis zu acht Teams konzipiert, „LeSS Huge“ kann darüber hinaus auch in Umgebungen mit mehreren Hundert beteiligten Entwicklern zum Einsatz kommen.
OKR (Objective Key Results): Das Managementsystem OKR will unter anderem Transparenz und Kommunikation fördern, Abstimmungsprozesse beschleunigen und die Selbstorganisation der Mitarbeiter in Teams ermöglichen. So sollen Unternehmen agiler werden und sich besser auf ihre Ziele fokussieren können. Dazu werden qualitative Ziele (Objectives) vereinbart, deren Erreichen anhand von „Key Results“ gemessen wird. Das bekannteste Unternehmen, das mit OKR arbeitet, ist Google.
3. Teil: „Der steinige Weg zur Agilität“

Der steinige Weg zur Agilität

  • Schritt für Schritt: Nach jedem Sprint bewertet das Scrum-Team, was gut und was schlecht gelaufen ist.
    Quelle:
    EOS / Holger Koschek
Für Unternehmen bedeutet Agilität einen radikalen Wandel ihrer Führungs-, Kommunikations- und Fehlerkultur. Statt Herrschaftswissen, Hierarchien und starre Regeln sind Transparenz, Eigenverantwortung und Anpassungsfähigkeit gefordert. Diese Veränderung dauert lange und lässt sich Daniel Dubbel zufolge auch nicht einfach verordnen: „Die agile Transformation findet bei jedem Mitarbeiter statt, egal auf welcher Hierarchieebene er sich befindet.“
Besondere Bedeutung komme dabei den Schnittstellen zu. „Das eigentlich Spannende ist die Interaktion zwischen den Menschen, wie sie in und zwischen den Abteilungen und Teams einer Organisation zusammenarbeiten.“ Das funktioniere dann gut, wenn das gesamte Unternehmen auf denselben Werten und Prinzipien basiere. „Dann ist es zweitrangig, ob ich Projekte agil oder im Wasserfallmodell organisiere.“
Svenja Hofert wiederum empfiehlt, klein anzufangen. „Man kann nicht von heute auf morgen alles umstellen, das funktioniert nicht.“ Auch sollte man von den Mitarbeitern keine Begeisterungsstürme erwarten, wenn man sie in die Freiheit des agilen Selbstdenkens entlässt. „Wer jahrelang Dienst nach Vorschrift gemacht hat, ist mit so viel Eigenverantwortung oft überfordert.“
Der Prozess sei zudem in jedem Fall anders und individuell. „Blaupausen gibt es nicht, auch wenn die Unternehmen das gerne hätten.“ Beteiligungskonzepte seien enorm wertvoll, um die agile Entwicklung voranzutreiben. „Wenn Mitarbeiter direkt vom Unternehmenserfolg profitieren, statt sich nur als Rädchen im Getriebe zu fühlen, sind sie viel eher bereit, Verantwortung zu übernehmen.“
Externe Unterstützung kann Starthilfe geben, rät der Unternehmensberater Klaus Tumuscheit, der unter anderem die professionelle Begleitung agiler Projekte anbietet: „Die Teammitglieder sollten mit der nötigen Prozesskompetenz dazu befähigt werden, agil im Projekt zusammenzuarbeiten. Ist das gelungen, kann sich der Berater wieder zurückziehen.“
Die Projektteilnehmer müssten zudem von ihren operativen Aufgaben zumindest teilweise entlastet werden: „Ich kann nicht 100 Prozent Tagesgeschäft machen und gleichzeitig in einem agilen Projekt arbeiten, das funktioniert nicht.“ Ansätze wie Digital Labs oder Corporate-Start-ups könnten zwar helfen, indem sie Mitarbeiter für eine gewisse Zeit aus ihrem gewohnten Kontext herausnehmen und ihnen die Freiräume geben. Wenn es jedoch zur Wiedereingliederung in die hierarchische Linienorganisation komme, sei der Kulturschock groß: „Plötzlich gibt es wieder einen Chef, der alles besser weiß.“
Tumuscheit rät daher, Hierarchien nicht mehr als Macht- und Kontrollinstrumente zu verstehen. „Führungskräfte müssen loslassen können, mehr Vertrauen zu ihren Mitarbeitern entwickeln und sie befähigen, selbstständig und agil zu arbeiten.“ Das erfordere Mut und werde nirgends gelehrt.
„Die Mitarbeiter wissen sehr gut selbst, was notwendig ist. Ich kenne Unternehmen, die nicht wegen ihrer hierarchischen Linienstruktur funktionieren, sondern weil die Menschen sich miteinander vernetzen und sich gegenseitig unterstützen.“
Tumuscheit glaubt, dass sich Veränderungen zwangsläufig mit dem Generationenwechsel ergeben werden: „Für viele junge Menschen ist es überhaupt nicht mehr erstrebenswert, in den typischen Kamin-Hierarchien aufzusteigen, sie wollen fair behandelt werden und Sinn in ihrer Arbeit erfahren.“
Tabelle:
● ja  ○ nein    1) acht Nutzer    2) Enterprise Edition    3) über Hosting- und Cloud-Provider    4) anbieterabhängig

4. Teil: „Mehr Schein als Sein“

Mehr Schein als Sein

Agilität ist in deutschen Unternehmen schwer in Mode. Laut der Studie „Potenzialanalyse agil entscheiden“ des Beratungsunternehmens Sopra Steria halten 80 Prozent der befragten Manager die Einführung agiler Strukturen und Methoden für sinnvoll, 70 Prozent bezeichnen ihr Unternehmen als zumindest durchschnittlich agil.
„Die meisten Unternehmen haben erkannt, dass sie schneller und beweglicher werden müssen, um sich den veränderten Marktbedingungen besser anpassen zu können.“, weiß Urs M. Krämer, CEO von Sopra Steria Consulting, „Agilität steht deshalb auf der Agenda deutscher Führungskräfte weit oben.“
Ein genauerer Blick auf die Umfrageergebnisse zeigt jedoch, dass es sich hier zu einem nicht unerheblichen Teil um Selbsttäuschung handelt. Nur 19 Prozent der Befragten pflegen einen partizipativen Führungsstil, nur 30 Prozent gaben an, am Abbau von Hierarchien zu arbeiten. Und obwohl viele ihr Unternehmen als „stark datengetrieben“ bezeichnen, verlassen sich Manager vor allem auf eines: ihr Bauchgefühl. Bei 90 Prozent der befragten Führungskräfte beruhen Entscheidungen stark (48 Prozent) oder sogar sehr stark (42 Prozent) auf Erfahrung und Intuition - keine gute Idee, meint Krämer: „In einer Welt, in der die Digitalisierung das Innovationstempo vorgibt, sinkt die Halbwertzeit unseres analogen Erfahrungswissens dramatisch.“
Auch Svenja Hofert beobachtet ein großes Beharrungsvermögen in den Führungsriegen: „Manager haben sehr große Schwierigkeiten, sich von den erlernten Strategien zu verabschieden, mit denen sie in der komplizierten Welt erfolgreich waren.“ Die Begeisterung für agile Tools und Methoden sei ein Ausdruck dieser Haltung: „Neue Methoden zu finden oder Werkzeuge anzuwenden, sind klassische Lösungsansätze aus der Industrie 3.0.“ Oft erfüllten Scrum und andere agile Frameworks nur eine Alibifunktion. „Die Unternehmen verstehen das Konzept nicht. Scrum ist keine Methode, sondern ein Rahmen, der hilft, sich anders zu organisieren“, erklärt Hofert.
Die Enttäuschung sei in der Folge deshalb oft groß: „Es heißt dann, Scrum funktioniere nicht, dabei wird schon das Rollenkonzept in 80 Prozent der Fälle nicht richtig angewendet“, kritisiert Svenja Hofert. Sie warnt außerdem davor, die veröffentlichten Erfolgsgeschichten von agilen Projekten für bare Münze zu nehmen. „Man muss hinter die Kulissen schauen, in der Realität sind die Hürden oft viel größer als es in den Case-Studys dargestellt wird.“

Fazit & Ausblick

Der Hype um Agilität lässt oft zwei einfache Tatsachen vergessen. Erstens ist der agile Ansatz kein Allheilmittel. „Es gibt Felder, in denen agiles Arbeiten weder zwingend notwendig noch sinnvoll ist“, gibt Daniel Dubbel zu bedenken. Zweitens sind nicht wenige der als hip und neu beworbenen Techniken und Methoden alte Bekannte. „Vieles, was seit Jahren in der Teamarbeit gang und gäbe ist, wird heute als agil verkauft“, berichtet Klaus Tumuscheit.
Zudem haben die meisten Unternehmen anscheinend kaum verstanden, worum es bei Agilität im Kern geht. Eingefahrene Muster, Befehlsstrukturen und Hierarchien werden nicht schon dadurch besser, dass man ihnen neue Etiketten verpasst. Wenn der Abteilungsleiter sich „Scrum Master“ nennt, die Meilensteine im Fünfjahresplan als „Sprints“ verkauft werden und das Entwicklungsteam unter der Doppelbelastung aus operativen Aufgaben und Projektarbeit stöhnt, ist das Scheitern eines „agilen Projekts“ programmiert. Zu hart sollte man mit den Unternehmen allerdings auch nicht ins Gericht gehen, denn der Weg zu echter Agilität ist steinig. Karriere zu machen, bedeutete über Jahrzehnte hinweg die Akkumulation von Macht und Herrschaftswissen. Die entstandenen Hierarchien aufzubrechen, ohne Chaos auszulösen und das Unternehmen zu gefährden, ist nur sehr langsam, in kleinen Schritten und mit vielen Kompromissen möglich.
Ob man dabei auf Scrum, SAFe oder Kanban setzt, ein Digital Lab ins Leben ruft oder ein Corporate-Start-up gründet, ist letztlich zweitrangig. Technologien und Methoden können unterstützen und Orientierung für die Entwicklung bieten. Die Veränderung selbst muss jedoch in den Köpfen der Menschen stattfinden.
Ähnlich sieht man das auch bei der Direktbank ING. Die allerdings wagt gleich den ganz großen Sprung: Die drittgrößte deutsche Privatkundenbank mit 4000 Mitabeitern und 288 Millionen Euro Umsatz vollzieht die Transformation auf den „Agile Way of Working“ während des laufenden Betriebs und sie gibt sich dafür nur anderthalb Jahre Zeit. Schon in diesem Sommer will sie mit der Ablösung der bis­herigen starren Hierarchien, Prozesse und Abteilungen von multiprofessionellen Teams durch sein. Agilität ist dabei nur das Mittel, nicht das Ziel. Das besteht schlicht darin, schneller zu wachsen als die Konkurrenz – und Talente anzulocken. Wa­rum der ING-Vorstand dieses Experiment wagt, obwohl die Bank relativ erfolgreich war und ist, zeigt anschaulich ein You­tube-Video unter www.youtube.com/watch?v=
NRzTyTPnK-M.
5. Teil: „Im Gespräch mit Thomas Lieder von EOS Technology Solutions“

Im Gespräch mit Thomas Lieder von EOS Technology Solutions

  • Thomas Lieder: Agile Coach uns Scrum Master bei EOS Technology Solutions
    Quelle:
    EOS / Holger Koschek
Der Finanzdienstleister EOS setzt nicht nur in der Software-Entwicklung auf agile Methoden. Thomas Lieder, Agile Coach und Scrum Master bei EOS Technology Solutions, erläutert die Beweggründe.
com! professional: Die Finanzbranche gilt als eher konservativ. Warum hat sich EOS dennoch entschieden, auf agile Methoden zu setzen?
Thomas Lieder: Die Marktentwicklung macht auch vor der Finanzbranche nicht Halt. Denken Sie nur an den völlig neuen Wettbewerb durch Fintechs. Wir sind gut in dem, was wir tun, aber wir müssen uns verändern, wenn wir auch in Zukunft ganz vorne mit dabei sein wollen.
com! professional: Ist es nicht auch einfach hip, sich als agiles Unternehmen zu präsentieren?
Lieder: Das mag sein. Agilität ohne echtes Ziel funktioniert aber nicht. Jedes Unternehmen muss sich fragen, warum es diesen Weg gehen will.
com! professional: Hat EOS denn eine Antwort auf diese Frage?
Lieder: Was das Projekt angeht, unsere Inkasso-Software FX neu zu entwickeln, auf jeden Fall. Wir haben ein klares Ziel: Die neue Software soll besser sein als unsere bestehende Lösung. Was das im Detail bedeutet und wie man zu einem guten Ergebnis kommt, ist aber nicht so einfach zu definieren.
com! professional: Warum ist Agilität hier der bessere Weg?
Lieder: Bei einer solchen Aufgabenstellung funktioniert der klassische Ansatz schlichtweg nicht. Sie können sich nicht fünf Jahre ins stille Kämmerchen zurückziehen und ein Produkt entwickeln, das hinterher womöglich keiner mehr brauchen kann, weil sich die Rahmenbedingungen längst verändert haben.
com! professional: Wie sind Ihre bisherigen Erfahrungen mit der agilen Software-Entwicklung?
Lieder: Unsere Erwartungen haben sich weitgehend erfüllt. Wir wollten möglichst schnell starten und erste Ergebnisse liefern können. Das ist gelungen. Unser Minimum Viable Product ist live und wir verdienen damit auch schon etwas Geld. Wir konnten bei der Änderung regulatorischer Vor­gaben zeigen, dass wir solche Anpassungen sehr schnell umsetzen können.
com! professional: Wie viel Freiheit lässt Ihnen dabei das Unternehmen?
Lieder: Ein klassischer Konzern, der eine nicht unwesentliche Summe in so ein Projekt in­vestiert, möchte natürlich gerne wissen, wie sich das Projekt entwickelt und wann welche Meilensteine erreicht sind. Das heißt, es gibt Zieltermine, die aber weit in der Zukunft liegen.
com! professional: Das entspricht aber nicht so ganz der reinen agilen Lehre, oder?
Lieder: Wir versuchen, uns die Flexibilität zu erhalten, Dinge auszuprobieren und auf Veränderungen reagieren zu können. Wir wollen aber auch der Organisation einen guten Eindruck davon geben können, wo wir gerade stehen und wo wir vielleicht auch Unterstützung brauchen. Das ist ein Geben und Nehmen, in dem beide Seiten voneinander lernen.
com! professional: Auf welche Frameworks setzen Sie?
Lieder: Wir nutzen einen relativ klassischen Scrum-Ansatz und arbeiten in fünf Teams, die autonom in ihrem Bereich entscheiden. Daneben haben wir teamübergreifende Abstimmungen etabliert, denn letztlich funktioniert das Projekt nur gemeinsam. Insgesamt versuchen wir das Projekt wie eine virtuelle AG mit einer Führungsmannschaft zu leiten.
com! professional: Welche Tools setzen Sie dafür ein?
Lieder: Für die übergreifende Steuerung der Teams nutzen wir Jira. Daneben gibt es konzernweite Tools, etwa das Personal­portal, die wir aus Projektsicht nicht zwingend einsetzen würden, aber als Teil der Gesamtorganisation verwenden müssen.
com! professional: Wie wichtig ist die Wahl der Werkzeuge?
Lieder: Der Erfolg oder Misserfolg eines agilen Projekts hängt nicht von den verwendeten Werkzeugen ab. Ich muss mir überlegen, wie ich mein Projekt organisieren und welche Ziele ich verfolgen will. Aus meiner Erfahrung gibt es nicht den einen perfekten Prozess. Wenn sich die Welt weiterdreht, ändern sich nicht nur die Anforderungen an das Projekt, sondern auch die Art und Weise, wie man zusammenarbeitet.
com! professional: Was sind die größten Herausforderungen?
Lieder: Zwei Bereiche machen typischerweise Schwierigkeiten. Zum einen entspricht die schnelle Taktung eines agilen Projekts nicht immer dem üblichen Unternehmenstempo. Häufig benötigen andere Abteilungen, auf deren Zuarbeit man angewiesen ist, längere Vorlaufzeiten als man sich das wünschen würde. Da muss man unter Umständen Abstriche bei Agilität und Schnelligkeit machen. Die andere typische Herausforderung ist das agile Mind-Set. Damit meine ich die Bereitschaft, beständig zu lernen, sich auf nicht perfekte Lösungen einzulassen und trotzdem immer zu versuchen, das Beste aus der Situation zu machen. Bei EOS ist der Kulturwandel schon im vollen Gange, aber natürlich braucht dieser Prozess Zeit.
com! professional: Sehen Sie Ihr Projekt auch als Botschafter für diese kulturelle Veränderung?
Lieder: Ich denke schon, dass unsere Erfahrungen über das Projekt hinaus wirken und Veränderungen anstoßen. Wir haben von Anfang an sehr offen kommuniziert, alle EOS-Standorte besucht und unser Vorhaben vorgestellt. Es ist sicher nicht unsere explizite Aufgabe, das Unternehmen zu transformieren, aber allein unsere Existenz vereinfacht es anderen Abteilungen, den agilen Weg zu gehen. Als ich im Oktober 2016 bei EOS anfing, war ich der einzige Agile Coach, heute gibt es schon sieben. Das zeigt, welche Strahlkraft das Projekt hat.
com! professional: Welchen Rat können Sie anderen Unternehmen geben, die agile Projekte planen?
Lieder: Viele Projekte beginnen aus den Abteilungen heraus als eine Art Graswurzelbewegung. Das kann bis zu einem gewissen Grad funktionieren. Ab einer bestimmten Größe braucht man aber die Rückendeckung des Managements, um die notwendigen Veränderungen anstoßen und durchsetzen zu können. Ein zweiter Punkt, den man nicht unterschätzen darf, sind Schnittstellen. Je größer das Projekt wird und je mehr Abhängigkeiten mit anderen Abteilungen oder technischen Systemen bestehen, desto stärker muss ich den Aufwand für Abstimmungsprozesse berücksichtigen. Das wird dann sehr schnell viel mehr als ein reines Software-Projekt. Und man muss darauf achten, wie man wahrgenommen wird. Die anderen Abteilungen sind ja sehr kompetent und erfolgreich. Sie haben ihre Prozesse im Griff. Das muss man anerkennen und auf Augenhöhe mit guten Argumenten erklären, warum eine Veränderung dennoch sinnvoll ist.

mehr zum Thema