11.01.2018  Verfasst von Oliver Behr und Lorenzo Peroni in Agile Methoden  

Agile Methoden in ungewohnter Umgebung. Ausschreibungserstellung neu gedacht.

Entwickler setzen bei digitalen Produkten und Services auf agile Verfahren. Wie auch andere Unternehmensteile von Agilität profitieren können, erläutert Agile Coach Lorenzo Peroni am Beispiel Deutsche Bahn.

Agile Arbeitsmethoden haben sich bei der Entwicklung digitaler Produkte und Services durchgesetzt. Kaum noch ein Softwareentwicklungsteam verzichtet auf kurze Iterationen, Task-Boards und Retrospektiven. Doch nutzen neben der Softwareentwicklung auch andere Unternehmensteile agile Methoden und wie wird Agilität hier umgesetzt? Der Agile Coach Lorenzo Peroni begleitet ein Projekt bei der Deutschen Bahn, bei dem agile Methoden in der Erstellung einer großen Ausschreibung genutzt werden. Oliver Behr hat Ihn zu seinen Erkenntnissen befragt.

Oli: Hallo Lorenzo! Wir sprechen heute über Agilität und zwar in einem Umfeld, das man normalerweise nicht sofort mit agilen Arbeitsmethoden verbindet. Du bist Agile Coach und hast bereits zahlreiche agile Projekte geleitet. Kannst du uns zunächst verraten, welche agilen Projekte du normalerweise begleitetest und wie du Agilität verstehst?

Lorenzo: Agilität beruht auf einem Set von Werten, die im agilen Manifest definiert sind. Menschen und deren Interaktionen stehen dabei im Vordergrund. Agilität erfordert insbesondere, dass man Offenheit und Transparenz lebt: einerseits extern gegenüber Kollegen und Partnern, andererseits gegenüber sich selbst. Es ist eine Geisteshaltung gegenüber Neuem; man erlaubt sich, Fehler zu machen, um aus ihnen zu lernen. Darauf aufbauend, gibt es zahlreiche agile Arbeitsmethoden, deren Fokus auf dynamischer Zusammenarbeit und Kundenzufriedenheit liegt. Agile Projektabläufe zeichnen sich durch aufeinander aufbauende Iterationen aus, was ermöglicht, aktiv auf Umwelteinflüsse zu reagieren und laufende Prozesse stetig zu verbessern. Am Ende einer Iteration steht immer ein Produkt, welches man einem Endkunden ausliefern könnte. Agile Methoden sind seit den frühen Neunziger Jahren bekannt und haben sich in der Entwicklung digitaler Produkte und Dienstleistungen durchgesetzt. Ich habe bisher hauptsächlich bei Entwicklungsprojekten im Softwarebereich unterstützt und dabei erlebt, wie sich Methoden wie Scrum, Kanban, DevOps, Management 3.0 und Design Thinking, etablieren.

Oli: Dein aktuelles Projekt bei der Deutschen Bahn ist jedoch nicht mit der Erstellung eines digitalen Produkts oder Services befasst. Was ist die Zielsetzung eures Projektes?

Lorenzo: Die Deutsche Bahn schreibt die Entwicklung einer Standardsoftware für die Planung und Steuerung des gesamten Fernverkehrs in Deutschland aus. Wir arbeiten seit einem Dreivierteljahr daran, hunderte Seiten Anforderungen für diese Software zu erstellen – das ist erstmal überhaupt nicht agil. Denn das agile Manifest besagt auch, dass eine schrittweise Entwicklung funktionierender Produkte (Software) für den Endkunden wichtiger ist als eine ausführliche Dokumentation. Die Devise lautet eher, auf Basis von Kundenfeedback zu einem Produkt, sich den daraus resultierenden Anforderungen anzupassen. Das sehe ich auch immer noch so. In unseren Fall gilt aber, dass wir die Software erst bekommen, wenn ein Softwareanbieter durch eine Ausschreibung ausgewählt wurde. Wir entwickeln also zunächst keine Software, sondern formulieren deren Anforderungen. Doch auch hier machen die Grundwerte agiler Methoden Sinn.

Oli: Also agile Methoden in einem eher untypischen Umfeld. Wie würdest du den agilen Reifegrad des Teams und des Managements bewerten?

Lorenzo: Sehr gemischt. Die Projektleiter arbeiteten auf ihren vorherigen Projekten in der Softwareentwicklung mit agilen Methoden, die bereits für mehrere Teams skaliert waren. Viele Teammitglieder hatten jedoch noch wenig praktische Kenntnisse agiler Methoden. Auf dieser Basis haben wir entschieden, grundlegend mit dem Framework Scrum zu beginnen und uns an den gängigen Frameworks zur Skalierung zu orientieren. Wir haben immer wieder diskutiert, was für uns sinnvoll ist, und unsere Zusammenarbeit sukzessive angepasst und erweitert.

Oli: Und welche Rolle nimmst du in diesem Projekt ein?

Lorenzo: Ich bin der Agile Coach und wirke auf Managementebene mit, um die Zusammenarbeit methodisch zu verbessern. Weiterhin unterstütze ich insgesamt 25 Personen in drei Teams, die je einen Product Owner haben, jedoch außer mir keinen Scrum Master – was wir noch ändern werden.

Oli: Woher kam denn die Motivation, dieses Projekt agil durchzuführen?

Lorenzo: Da liefen mehrere Bestrebungen zusammen. Zum einen wollten die Fachteams unbedingt agil arbeiten, zum anderen hängt dies mit dem Volumen der Ausschreibung zusammen. Durch die Komplexität der Software mit millionenschweren Entwicklungskosten und einer sehr langen Projektlaufzeit steigt auch das Projektrisiko. Zusätzlich erhöht sich die Komplexität des Projekts durch die Vielzahl an abzulösender Verfahren und tiefgreifenden Changes. Agile Methoden sind dadurch charakterisiert Risiko zu verringern, indem sie komplexe, also nicht unmittelbar steuerbare Themen in komplizierte, aber beherrschbare Einzelschritte herunterbrechen. Durch regelmäßige Feedbackzyklen und aussagekräftige Zwischenergebnisse kann man das Risiko minimieren.

Oli: In eurem Projekt entwickelt ihr die Software also nicht direkt, sondern müsst sie zunächst beschreiben. Wie ließ sich dies nun mit agilen Methoden umsetzen?

Lorenzo: Ganz am Anfang haben wir im gesamten Team eine Wissensbasis aufgebaut und in den ersten Tagen agile Methoden, insbesondere Scrum geschult, um ein gemeinsames Vokabular zu haben. Auch wenn wir Ausschreibungsdokumente erstellen, achten wir darauf, dass diese iterativ aufeinander aufbauen. Dazu definierten wir zunächst die Prozesse, welche die Software unterstützen muss, darauf aufbauend die eigentlichen Nutzeranforderungen und dann wiederum Bewertungsmatrizen und fachliche Erläuterungen. Diese Zwischenergebnisse bauen aufeinander auf und sind für sich allein bereits aussagekräftig. Wir haben für unsere Zwischenergebnisse intensiv Feedback eingefordert, um agil auf Probleme zu reagieren. Durch eine Taktung unserer Projektstruktur in Drei-Wochen-Sprints, konnten wir regelmäßig kritisch hinterfragen, ob unsere Methoden weiterhin sinnvoll sind, und Verbesserungen ausprobieren. So haben wir sukzessive ein individuelles Vorgehen für uns gestaltet, bei welchem wir jederzeit die Möglichkeit haben, agile Methoden so einzusetzen, dass sie uns am besten helfen.

Oli: Das Framework SAFe gilt als Vorreiter, wenn es darum geht, agile Methoden auf größere Strukturen anzuwenden. Gibt es Parallelen zum Vorgehen in eurem Projekt?

Lorenzo: SAFe ist ein sehr interessanter, aber auch umstrittenerer Ansatz. Er beschreibt ein Zielbild, welches sehr kompliziert ist und alle Unternehmensebenen betrifft. Das ist nicht trivial zu implementieren und zu steuern. Man kann nicht von heute auf morgen sagen: „Wir machen jetzt SAFe.“ Wir haben uns vielmehr von SAFe-Grundsätzen und -Methoden inspirieren lassen und einzelne Ansätze implementiert. Grundlegend nutzen wir eine Mischung von Kanban und Scrum, je nach Team und Anwendungszweck. Darauf aufbauend haben wir einen Agile Release Train implementiert: Wir nutzen insbesondere das „Programminkrement“, also die Abfolge mehrerer Sprints, an denen mehrere Teams zusammen an parallelen Themen arbeiten. 

Oli: Was waren denn die größten Schwierigkeiten, denen du in dem Projekt begegnet bist?

Lorenzo: Es gab und gibt tatsächlich einige Schwierigkeiten. Dies betrifft vor allem die klassische Struktur eines Großkonzerns. Die Gesamtprojektleitung muss die Freiheit haben, ein agiles Vorgehen vorzuleben. Und das Team muss sich die Aufgaben zutrauen. Transparenz muss gegeben sein, damit klar wird, warum einzelne Methoden sinnvoll sind. Wenn das gegeben ist, kann man beginnen, agile Frameworks einzusetzen. Dies alles immer in dem Bewusstsein, dass es ein wenig dauern wird, bis Neuerungen voll ins Blut übergegangen sind.

Oli: Machen agile Methoden eigentlich Sinn in deinem Projekt?

Lorenzo: Definitiv. Einerseits sind die Mitarbeiter meines Erachtens deutlich intrinsisch motiviert, da sie das Gefühl haben, ihre Aufgaben selbst zu gestalten und dabei viel lernen zu können. Alle Ebenen können an den Zwischenergebnissen besser nachverfolgen, dass der Prozess uns sicher zum Ziel führt, und wir können Probleme sehr früh erkennen und reagieren. Das führte sogar dazu, dass wir ein weiteres, fast gleich großes Thema mit in unser Projekt integrieren konnten. Das Vertrauen wurde uns wiederholt ausgesprochen und wir haben das Gefühl, dass wir das meistern können. 

Oli: Wäre das Ergebnis in einem klassischen Wasserfallmodellanders gewesen?

Lorenzo: Das ist schwierig zu sagen, da jedes Projekt ein Experiment ist. In einem parallelen Universum wäre das Ergebnis vielleicht sogar ähnlich gut geworden, jedoch wären die Leute vielleicht total ausgebrannt. Unseren Teammitgliedern hat die Arbeit Spaß gemacht, und der individuelle Lernfortschritt war immens. Durch die agile Projektsteuerung haben wir nun total motivierte Mitarbeiter, die sich darauf freuen, in Vorbereitung der ausgeschriebenen Software bereits erste Prozessoptimierungen in Richtung Effizienz und Qualität durchzuführen. 

Oli: Wie siehst du die Zukunft solcher agilen Herangehensweisen für weitere Arten von Abteilungen und Projekten?

Lorenzo: Sehr vielversprechend! Man kann bei unserem Projekt sehr gut sehen, wie eine Zusammenarbeit in Zukunft aussehen kann. Natürlich ist Agile kein Allheilmittel. Man muss von Fall zu Fall bewerten, welche agilen Methoden am meisten Sinn ergeben. Am besten geht dies bei Produkten, die sich aus Schichten aufbauen lassen, welche einzeln bereits funktionsfähig sind. Man konzentriert sich dann auf die Bedürfnisse der Kunden und liefert regelmäßig werthaltige Inkremente. Es bedarf nur etwas Fantasie, die richtigen Anwendungsfälle zu identifizieren und etwas Mut, die Zusammenarbeit weiterzuentwickeln.

Oli: Vielen Dank für das Gespräch!

Im Interview:
Lorenzo Peroni
Management Consultant
agile(@)no-spam.cassini.de

Der Autor:
Oliver Behr
agile(@)no-spam.cassini.de