Containerflotte statt Tanker

Das Kernsystem der EOS TS galt intern lange als nicht mehr transformierbar: Sowohl die zugrunde liegenden Technologien als auch die Build- und Betriebsprozesse galten als zu komplex und fragil, um technologische Verbesserungen risikoarm und zeitnah durchführen zu können. Fachliche Änderungen benötigten aufgrund dessen einen langen Vorlauf, um mittels Konzeptarbeit zukünftige Betriebsstabilität und Machbarkeit weiter sicherzustellen.

Tatsächlich arbeitet die EOS TS intern an einer Neuentwicklung, die das hier behandelte Kernsystem mittelfristig ablösen soll, aber auch entsprechende Wissensträger benötigt, die bei der Weiterentwicklung des Altsystems dann fehlen. Zusätzlich schätzten interne und externe personelle Neuzugänge mit entsprechender Erfahrung die Möglichkeiten zur Transformation des Altsystems optimistischer ein, sodass EOS TS zusammen mit der iteratec GmbH im Dezember 2017 ein Projekt aufsetzte, um das Altsystem iterativ auf eine zukunftsfähige Basis zu heben und die noch Jahre andauernde Restlaufzeit sicherer und preiswerter zu bestehen.

Wir hatten das Ziel, den komplexen Aufgaben zu begegnen und einerseits die Entwicklerteams in der Transformation von vornherein einzubinden und andererseits während der Transformation permanent deployment- und releasefähig zu bleiben. Deshalb haben wir uns als gemischtes Team von EOS TS und iteratec entschlossen, agil nach Scrum vorzugehen. Zweiwöchige Reviews, Schulungen zu den verwendeten Technologien sowie frühzeitige und kontinuierliche Produktivstellung von Teilergebnissen halfen dabei, Akzeptanz für die Umstellung zu erzeugen. Außerdem konnten so die betroffenen Kollegen sowie die Fachabteilung in die Transformation integriert werden.

Ausgangsituation

Das Kernsystem bestand aus einer umfangreichen Code-Basis in C++, in der eine Vielzahl von fachlichen Services implementiert ist. Daran eng gekoppelt existierten in unterschiedlichen Technologien entwickelte Batch-Jobs und Webservices, die zum Beispiel externe Systeme anbinden oder Services für Kunden bereitstellen. Durch eine enge Kopplung ohne klar spezifizierte und versionierte Schnittstellen musste das Gesamtsystem jeweils als Ganzes getestet und ausgeliefert werden. Die Build-Logik war in einer Mischung aus Shell-, Perl-, Ant-, Maven-, Gradle- und Make-Skripten implementiert, deren Verhalten darüber hinaus – wie auch das der Batch-Jobs – von vielen gesetzten Umgebungsvariablen abhing. Diese Komplexität führte dazu, dass selbst viele Entwickler nur mit von Experten zur Verfügung gestellten Zusatzskripten in der Lage waren, die Software lokal zu bauen.

Der bisherige Release-Prozess bestand aus vierteljährlichen Releases neuer Major-Versionen und bei Bedarf wöchentlichen Hotfix-Releases. Bevor eine neue Major-Version ausgerollt wurde, durchlief sie eine dreimonatige Testphase, in der Tester und Fachbereich umfangreiche manuelle Tests durchführten. Dieser Prozess führte dazu, dass die Entwickler dauerhaft vier gemeinsam genutzte Branches mit drei unterschiedlichen Major-Versionen pflegen mussten:

• den Entwicklungsbranch mit der Version, die im übernächsten Release-Zyklus livegehen sollte,
• den Release-Branch mit dem nächsten Major-Release,
• den Produktions-Branch und in der gleichen Version
• einen Hotfix-Branch, auf dem die wöchentlichen Hotfix-Releases getestet werden konnten.

Jeweils täglich wurden auf gemeinsam genutzten Servern Entwicklungs-, Release- und Hotfix-Branch von einem speziellen Plattformteam zur Verfügung gestellt. Diese Server wurden vom Betriebsteam manuell aufgesetzt und gewartet. Auch die Produktionsserver wurden in ähnlicher Weise, allerdings mit geringerer Frequenz, aktualisiert. Durch die gleichzeitig zu wartenden Branches und die Abhängigkeit zwischen Entwicklern, Testern, Plattformteam und Betriebsteam bedeutete jede Änderung nicht zu rechtfertigenden Overhead. Außerdem konnten neue Features nach Anforderung durch den Fachbereich erst nach frühestens neun Monaten vom Fachbereich genutzt werden (drei Monate Konzeption und Planung, drei Monate Entwicklung, drei Monate Test). Da das in einigen Fällen nicht ausreichend war, wurden auch auf Release- und Hotfix-Branches teilweise noch neue Features entwickelt, was zu einer Vervielfachung der Entwicklungs- und Testaufwände führte.

Die Betriebsumgebung für die einzelnen Versionen bestand jeweils aus mehreren Snowflake-Servern, die manuell in jedem Release-Zyklus von etwa zwei Wochen für die nächste Version aktualisiert und konfiguriert werden mussten. Die Betriebsumgebung war zudem stark veraltet, weil die Teams die Aufwände und Risiken gescheut haben, um die neuen Betriebssystemversionen zu testen und zu konfigurieren. Es war kaum oder nur mit einem nicht zu unterschätzendem Ausfallrisiko möglich, die vorhandene Umgebung anzupassen, da diese nicht ohne Weiteres wieder aufgesetzt werden konnte.

Vorbereitend wurden in einem vorangegangenen Projekt viele Testfälle automatisiert. Diese Testfälle wurden in einem eigenen Repository entwickelt und täglich auf einer eigenen Umgebung gegen den Release-Branch ausgeführt. Die Ergebnisse dieser Tests waren in Test-Reports einsehbar und mussten von den Entwicklern oder den Release-Managern manuell überwacht werden.

Personell war die Lage einerseits durch die allgemeine Marktsituation, aber insbesondere auch durch den Wechsel von vielen sehr erfahrenen und mit dem Gesamtsystem sehr vertrauten Kollegen zum Neusystem problematisch. Die Kollegen sollten einerseits ihre Erfahrung in das Neusystem einbringen und sich gleichzeitig mit den dort verwendeten Technologien vertraut machen. Mit dieser Strategie sollten die Teams das Altsystem bis zur endgültigen Ablösung in einen aufwandsreduzierten Maintenance- und Betriebsmodus überführen.

Ziel

Ziel des Projekts war es, die Prozesse so zu automatisieren und zu vereinfachen, dass auch unter den geschilderten Umständen effektiv entwickelt werden kann und jederzeit neue Versionen ausgerollt werden können.

Dazu mussten die Teams fähig sein, unabhängig voneinander mit den betroffenen Fachbereichen an neuen Features arbeiten und diese nach deren Fertigstellung und Test sofort ausrollen zu können. Die Auswirkung des Deployment-Prozesses auf die Arbeit des Fachbereichs musste dabei minimal sein. Darum war es darüber hinaus notwendig, Deployments unterbrechungsfrei durchführen zu können.

Um das zu erreichen, war es notwendig, vorher den Build-Prozess zu konsolidieren und deutlich zu vereinfachen, Abhängigkeiten zu reduzieren und sowohl das Setup der Betriebsumgebungen als auch vorher manuell ausgeführte Deployment-Schritte zu automatisieren.

Setup des Projekts

Mithilfe von Partner-Interviews, in denen sich die Kollegen von EOS TS und iteratec gegenseitig vorstellten und diskutierten, lernten wir uns auf persönlicher Ebene kennen und schufen im Dezember 2017 den Auftakt zu dem Projekt mit dem Namen F2Continuous.

Ein bestehendes Team aus Senior Softwareentwicklern, Softwarearchitekt und Product Owner von iteratec bildete zusammen mit Datenbankspezialisten und Senior Softwareentwicklern sowie Softwarearchitekten und einem Scrum Master von EOS TS ein gemeinsames Team inmitten des bisherigen Build- & Deployment-Teams.

Schnell kamen wir überein, dass wir nur mit einer agilen Methode das Projekt zum Erfolg führen können. Die bestehenden technologischen Abhängigkeiten und teilweise alten Technologien beinhalteten eine Komplexität, der wir uns nur Stück um Stück nähern und sie durchdringen konnten.

Um die Herausforderung zu begreifen, führten wir die ersten Interviews mit dem Fachbereich, Testern, Entwicklern sowie dem Build- & Deployment-Team. Dabei ergab sich das erste abstrakte Zielbild zur Schärfung des CI-/CD-Begriffs für den konkreten Projektkontext (siehe Abbildung 1).

Entscheidung für ein Vorgehensmodell

Aufgrund der technologischen Komplexität des Systems und der kaum greifbaren organisatorischen Herausforderungen (Releasemodell, Teamstruktur, Fachbereichs­beteiligung usw.) haben wir einen wasserfallartigen Ansatz von vornherein ausgeschlossen. Jegliche umfängliche Konzeption wäre unvollständig gewesen, da uns bereits zum Projektstart bewusst war, immer wieder auf neue Herausforderungen zu stoßen und nur schrittweise vorgehen zu können, um die Stabilität des laufenden Betriebs nicht zu gefährden. Mit einer vollumfänglichen Konzeptionsphase hätten wir das Projekt aufgrund der Summe von Risiken und Herausforderungen nie starten können. In kleinen Schritten waren diese aber greif- und handhabbar.

Somit wählten wir ein iteratives Vorgehen. Da das iteratec-Team bereits im Vorhinein in verschiedenen Projekten erfolgreich zusammen nach Scrum gearbeitet hat, entschlossen wir uns, auf dieser Basis und den Erfahrungen der EOS TS-Kollegen die Herausforderung anzunehmen.

Jede einzelne Tätigkeit haben wir konsequent nach folgenden Grundsätzen ausgerichtet:

• Schaffe eine (grobe) Zielvision und passe diese kontinuierlich an veränderte Gegebenheiten und neue Erkenntnisse an.
• Nähere dich Schritt für Schritt der Zielvision, dabei muss jeder Schritt für sich Mehrwert bieten.
• Hebe bewusst Synergien und priorisiere die Schritte nach oben, die die meisten Synergien erzeugen (Beispiele, die später noch erläutert werden: dynamische Datenbanken für lokale Entwicklung, Automatisierung der Infrastruktureinrichtung).
• Das komplette System muss automatisiert aufsetzbar sein.
• Eine Lösung muss nicht perfekt sein. Ist die Lösung so gut wie vorher, aber im Sinne der Zielvision, reicht das zunächst aus.

Lösungskonzept

Aus dem vormaligen Lösungsentwurf aus Abbildung 1 ist durch mehrere Iterationen das Schaubild zu Prozess & Architektur in Abbildung 2 entstanden. Die Grundidee ist, dynamisch Umgebungen bereitzustellen, in denen Features separat voneinander entwickelt und getestet werden können. Klassische Stages wie Entwicklung und Integration gibt es nicht mehr, einzig die Produktionsumgebung und eine variable Anzahl an Feature-Umgebungen, in denen Features unabhängig entwickelt, getestet und vom Fachbereich abgenommen werden können. Nach erfolgter Abnahme durch den Fachbereich und erfolgreicher Ausführung manueller und automatischer Tests wird das Feature in die Produktion überführt.

Die Feature-Umgebungen müssen automatisiert erzeugbar sein, da bis dato ein nicht unerheblicher Aufwand zur manuellen Einrichtung der klassischen Umgebungen notwendig war (ca. zwei Wochen). Bei einer dann deutlich erhöhten Anzahl an Umgebungen ist eine manuelle Einrichtung nicht mehr sinnvoll und skaliert nicht. Durch die Automatisierung der Umgebungsbereitstellung konnten wir Inselwissen bei der manuellen Einrichtung auflösen und die bis dato existierenden Snowflake-Server durch eine beliebig reproduzierbare Lösung ersetzen.

Zum vollumfänglichen Test des Systems muss jede Feature-Umgebung für sich ein komplettes Systemabbild beinhalten. Dazu gehören sämtliche Services und Batches sowie Frontends und eine separate Datenbank mit entsprechenden Testdaten.

Zur dynamischen Erzeugung von Feature-Umgebungen haben wir OpenShift als Container-Orchestrierungsplattform gewählt, wobei ein OpenShift-Projekt einer Feature-Umgebung entspricht. Dies setzt die vollständige Dockerisierung aller Services und Batches voraus. Dadurch sind auch die Services und Batches automatisiert aufsetzbar und die Entwickler können die Betriebsverantwortung des Systems wahrnehmen. Dieses Ziel hatte die EOS TS auch vor Projektstart bereits, allerdings ohne entsprechende Betriebsmöglichkeiten für die Entwickler.

Auch die Datenbanken werden parallel zu den Feature-Umgebungen dynamisch pro Feature erzeugt. Hierzu werden Oracle Pluggable Databases verwendet, um basierend auf einer Quelldatenbank, die die komplette Datenbankstruktur inklusive Testdaten enthält, eine Datenbank klonen zu können (siehe Abbildung 4).

Da auch die Batches (eine Sammlung an Perl- und Shell-Skripten sowie C++-Batches) automatisiert testbar sein müssen, weil sie entsprechende Businesslogik enthalten, musste auch die Steuerung der Batches automatisiert testbar sein. Bis dato war die Steuerung in Form von manuell gepflegten Cron-Jobs realisiert, die explizite Abhängigkeiten nur bedingt abgebildet haben. Da ein größerer Kreis die Batch-Steuerung in dieser Form weder pflegen, noch automatisiert ausliefern oder testen konnte, haben wir die Steuerung vollständig auf Camunda umgestellt. Dadurch wurden auch Abhängigkeiten direkt sicht- und modellierbar, was letztlich die Weiterentwicklung durch die verschiedenen Entwicklungsteams möglich machte.

Vorgehen

Um uns ein umfassendes Bild von der Ausgangssituation zu verschaffen, haben wir damit begonnen, alle betroffenen Teams nach der derzeitigen Situation und ihren Anforderungen zu befragen. Aus diesen Ergebnissen und den Zielvorgaben entwickelten wir dann eine grobe Roadmap und ein erstes Zielbild als Diskussionsgrund­lage, die im Laufe des Projekts immer konkreter wurden (siehe Abbildung 5 und 6).

Da wir bereits in einem vorherigen Projekt die Migration von SVN zu GIT durchgeführt haben, konnten wir jetzt direkt damit beginnen, den kompletten Build-Prozess in GitLab-CI zu überführen. Bis dato war dieser in händisch gepflegten Jenkins-Jobs abgebildet, die kaum noch wartbar waren. Ein erster Meilenstein war die vollständige Abbildung des Build-Prozesses in GitLab-CI. Damit konnten nun erstmals Feature-Branches bei jedem Commit automatisch gebaut werden. Das erlaubte dann auch im nächsten Schritt das Einführen von Merge-Requests und damit von tatsächlicher Continuous Integration (CI) für jeden Branch (siehe Abbildung 3).

Als zweiten Schritt haben wir frühzeitig als ersten Synergieeffekt die Bereitstellung der dynamischen Datenbanken in Angriff genommen. Hintergrund ist, dass die Entwickler bis dato nicht die Möglichkeit hatten, lokal gegen eine Datenbank zu testen/zu entwickeln. Daher haben wir einen Service zur Verfügung gestellt, um sich selbst persönliche Datenbanken erzeugen zu können. Derselbe Service wird auch für die Erzeugung der dynamischen Datenbanken pro Feature-Umgebung genutzt.

Die Datenbasis des Systems hängt sehr stark von Oracle ab und einiges an Business-Logik ist in PL/SQL umgesetzt. Eine Migration zu einer anderen Datenbank war daher keine Option. Die hochdynamische Erzeugung vieler Datenbanken mittels Oracle Pluggable Databases hat sich im Laufe des Projekts als nicht optimale Entscheidung herausgestellt. Pluggable Databases sind hervorragend geeignet, um verschiedene gleichartige Datenbanken gemeinsam verwalten zu können. Die Zugriffe erfolgen dann stets über eine zentrale Datenbank, die Container Database. Nach intensivem Austausch mit Experten von Oracle sind Pluggable Databases aber eher schlecht für unseren Anwendungsfall geeignet, da wir erstens unabhängige Datenbanken benötigen und zweitens die reine Anzahl an Zugriffen ein Problem darstellt. Besser wäre es, bei Bedarf Datenbanken in separaten Docker-Containern zu erzeugen gegebenenfalls in der Oracle Cloud. Derzeit wird der Bereitstellungsmechanismus entsprechend an-
gepasst.

Der nächste Schritt war die vollständige Automatisierung des Deployment-Prozesses auf Basis von OpenShift. Hierzu haben wir sämtliche Services (Java, C++, Perl …) beim Build in Docker Images verpackt und dann je nach Branch in ihre jeweilige Feature-Umgebung deployt. Die Schwierigkeiten lagen dabei unter anderem in der Konfiguration und dem Schnitt der Services. Die Konfiguration erfolgt in vielen Fällen über Umgebungsvariablen und Property-Dateien, die irgendwann in den letzten 18 Jahren auf den Snowflake-Servern eingerichtet wurden. Dabei war aber kaum klar, wer die Wissenshoheit darüber hat und ob die entsprechenden Personen überhaupt noch im Unternehmen sind. Auch mussten die Konfigurationen entsprechend an das neue Feature-Umgebungskonzept angepasst werden. Der Ressourcenverbrauch pro OpenShift Pod war herausfordernd, da das System aufgrund der Serverarchitektur auf eine vertikale und nicht auf eine horizontale Skalierung ausgelegt war.

Unter anderem getrieben durch das Projekt haben wir einen Service geschaffen, um OpenShift-Cluster auf Knopfdruck erzeugen und entfernen zu können. Der selbst auferlegte Grundsatz ist eine konsequente Automatisierung des kompletten Deployments. Das bedeutet, dass eine Plattform im Fehlerfall nicht repariert, sondern neu erzeugt und die Software komplett neu deployt wird.

Essenzieller Bestandteil des Vorgehens ist eine umfangreiche Testabdeckung durch automatisierte Tests. Da es keine klassischen Stages mehr gibt, muss die Qualität der Software auf den jeweiligen Feature-Umgebungen sichergestellt werden, bevor diese in die Produktion gehen.

Die Entwickler haben wir in regelmäßigen Reviews über den aktuellen Stand informiert und uns Feedback und Anregungen geholt. Für von uns neu eingeführte Technologien wie Camunda und OpenShift haben wir Schulungen durchgeführt und standen auch außerhalb dieser Termine jederzeit für Fragen zur Verfügung.

Kleine und große Hindernisse, überall

Herausfordernd war die Anpassung der bestehenden Prozesse an die Erfordernisse des F2Continuous-Projekts. Die agile Vorgehensweise bedingte, dass die beteiligten Entwicklungsteams, Betriebsteams und Tester sowie der betroffene Fachbereich an der Entwicklung der Vision beteiligt waren und sind. Ein schnelles Commitment auf ein gemeinsames Ziel ist dabei relativ einfach abzuholen, wenn es dann jedoch daran geht, kurzfristig Kapazitäten bereitzustellen, wurden Zusagen auf die Probe gestellt. Somit galt es, immer wieder von dem Zielbild zu überzeugen sowie in den zweiwöchigen Reviews auf die erreichten Ziele hinzuweisen. Dabei dienten die Reviews vor allem dazu, kritische Stimmen abzuholen und ihre Anmerkungen in unserem Backlog einfließen zu lassen.

Darüber hinaus waren die technologischen Anforderungen der gemeinsamen Vision für das beteiligte Infrastrukturteam sehr herausfordernd. Wo früher einzelne Server standen, mussten mit der Zeit automatisiert OpenShift-Cluster unterschiedlichster Node-Stärke und Anzahl bei Bedarf erzeugt und abgeräumt werden. Hierbei war insbesondere die automatisierte Bereitstellung herausfordernd. Durch Zusammenarbeit über Abteilungen hinweg, gelang es uns, vereint eine erste Basis dafür zu entwickeln und sukzessiv fortzuführen.

Bestehende Formen von Change-Request-Verfahren und Reporting-Strukturen, die für herkömmliche Projekte zweckdienlich waren, passten nicht zu dem agilen Vorgehen und dem Reporting mittels Review. Daher war es immer wieder notwendig, Abstimmungen außerhalb der regulären Scrum-Termine und -Artefakte durchzuführen. Das reguläre Berichtswesen scheiterte jedoch, die im Projektverlauf immer wieder auftretenden Hürden sinnvoll abzubilden, da jede Erkenntnis ohnehin automatisch Storys im Backlog nach sich zog und mittels Groomings oder Refinements-Lösungen erarbeitet wurden. Somit galt es, den Kollegen die Angst vor diesen Änderungen zu nehmen und sie aktiv mitwirken zu lassen. Release-Manager wurden so beispielsweise zu Feature-Managern. Diese Änderungen waren nicht ohne politisches Feingefühl durchführbar.

Heute nennen wir in der EOS TS so ein Vorgehen „ambitious goal“ – sich ein ambitioniertes Ziel zu setzen, das man glaubt, erreichen zu können. Und nicht alles durchzuplanen, sondern kreative Lösungen zu finden, um das Ziel zu erreichen. Und mit 70 Prozent Zielerreichung auch zufrieden zu sein.

Heutiger Stand

Wir befinden uns in der letzten Stufe der Umstellung vom alten Release-Takt zu Continuous-Delivery. Es gibt keine zentrale Entwicklungsumgebung mehr, das letzte oldschool geplante Release geht im September 2019 live und weitere Releases sind nicht geplant. Wir wissen aktuell nicht, ob es zukünftig noch ein Release dieser Art geben wird. Der Overhead, die Änderungen in den unterschiedlichen Stages zu verwalten, wird damit vollends abgebaut.

Stattdessen können wir täglich Änderungen in die Produktion ausliefern. Die Features sind mittlerweile kleiner geschnitten und gehen live, sobald sie fertig entwickelt und abgenommen sind. Das reduziert die Durchlaufzeit eines Features von neun Monaten – je nach Feature-Umfang – auf einige Tage oder Wochen.

Es hat sich im Nachhinein gezeigt, dass die Automatisierung der Infrastruktureinrichtung eine sehr gute Entscheidung war. Beispielsweise waren durch einen mittelschweren SAN-Ausfall alle VMs des Produktions-Clusters betroffen und befanden sich in einem sehr instabilen Zustand. Die Snowflake-Server hätten wir reparieren und weiterbetreiben müssen, stattdessen konnten wir die kaputten VMs löschen und das Cluster in kurzer Zeit komplett (automatisiert) neu aufbauen.

Das Ziel der Kostenreduktion wurde ebenfalls erreicht, und das Plattformteam kommt mit zwei Freelancern weniger aus.

Die hohe Flexibilität, neue Feature-Umgebungen in wenigen Minuten erzeugen zu können, stellt uns und die Betreiber externer Systeme vor neue Herausforderungen. „Wo ist denn jetzt die Hotfix-Umgebung oder die Entwicklung?“ beantworten wir mit „Die gibt es nicht mehr! Das Feature, das Du suchst, ist unter dieser URL erreichbar“. Damit die Betreiber der externen Systeme ihre Features (ohne Änderungen auf unserer Seite) testen können, werden wir eine jederzeit zur Produktion feature-identische Testumgebung zur Verfügung stellen und betreiben.

Der Know-how-Aufbau für die verwendeten Technologien Pluggable Databases, OpenShift, Kubernetes, Docker, Gray-log, Grafana, Telegraf, Camunda usw.
sowie die Zusammenhänge zwischen diesen läuft trotz zentral organisierter Schulungen und Trainings eher schleppend und bringt einige Kollegen deutlich aus ihrer Komfortzone. Um die Feature-Teams bei der Einarbeitung zu unterstützen, aber auch die Bedürfnisse der Teams besser zu verstehen, hospitieren aktuell Feature-Team-Kollegen beim Plattform-Team.

Einige Teile der Software sind so stark auf die vertikale Skalierung ausgelegt, dass wir diese bisher nur auf den Betrieb im Cluster umstellen konnten, das Potenzial der horizontalen Skalierung über mehrere Knoten aber noch nicht nutzen. Es werden beispielsweise für die parallele Datenverarbeitung alle Instanzen eines Batchs im selben Pod gestartet. Es gibt dementsprechend noch viele und zusätzliche Möglichkeiten, das monolithische Kernsystem weiter zu optimieren und fit für die Zukunft zu halten.

Fazit

Wie viele andere Projekte auch steht und fällt ein solches Vorhaben mit dem Team, das daran arbeitet. Es ist wichtig, ein in sich funktionierendes crossfunktionales Team zu haben, das sich auf Augenhöhe begegnet und auch auf persönlicher Ebene gut zusammenarbeitet. Warum? Die technologischen und organisatorischen Herausforderungen, die der Umbau eines großen Legacy-Kernsystems hin zu einer modernen Infrastruktur und einem zeitgemäßen Release-Modell mit sich bringt, führen unweigerlich zu Problemen verschiedenster Art. Dann ist es wichtig, dass das Team auf diese Herausforderungen flexibel reagieren kann und auch in schwierigen Situationen eng und motiviert zusammenarbeitet.

Hier hat es sich für uns bewährt, auf ein Team zu setzen, das bereits mehrere Jahre erfolgreich zusammengearbeitet hat, und dieses sukzessiv zu verstärken. Eine agile Vorgehensweise unterstreicht diese Arbeits­weise, da dadurch flexible Anpassungen möglich sind, aber auch die Stärken jedes Einzelnen im Vordergrund stehen. Zudem ist sie sehr hilfreich, um sich nicht heillos im Gesamtkonstrukt zu verlieren, sondern sich Stück für Stück der Vision einer besseren Software zu nähern.

Ein weiterer wichtiger Erfolgsfaktor für das F2Continous-Projekt war die Deckung der Geschäftsführung, des Fachbereichs, der EOS-DID und der EOS TS. Auch wenn der Status aus deren Perspektive nicht immer der beste war, stand das Projekt nie infrage und in kritischen Situationen wurden wir immer unterstützt. Deswegen gilt unser Dank den Geschäftsführern Jürgen Borgatz, Jörg Schweda und Tim Weickert, die den Mut aufgebracht haben, dem Team zu vertrauen.

Lessons Learned

Mach die Vorteile zielgruppengerecht transparent (z. B. durch mehrere Reviews).

Hole die Kollegen dort ab, wo sie stehen, und sorge dafür, dass sie nicht abgehängt werden.

• Bei Auslieferung neuer Funktionalitäten müssen alte Vorgehensweisen abgeschaltet werden, sonst werden die neuen nicht genutzt und das Feedback fehlt.
• Wenn zu wenig Fragen gestellt werden, ist das ein Warnsignal
  -> Erzwinge Fragen durch aktives Nutzen der Funktionen.
• Plane den Know-how-Aufbau rechtzeitig ein und schaffe Räume dafür (zentral Schulungen organisieren und Kollegen hinschicken; freie Zeiten nutzen).
• Definiere klare Kommunikationskanäle für bereichsübergreifende Themen (zentrale Ansprechpartner in anderen Abteilungen).
• Sorge für ausreichend technische und menschliche Ressourcen (Infrastruktur, Teamstärke).
• Hol dir (ggf. externe) Know-how-Träger ins Team.
• Schaffe Kapazitäten durch Repriorisierung -> wenn das Produktionssystem bedroht ist, haben plötzlich alle Zeit.
• Alle müssen bereit sein, ihre Komfortzone zu verlassen
  -> weitermachen wie bisher, gibt‘s nicht.
• Vertraue in die Leistung des Teams und motiviere es.
• Bei hoher Komplexität hilft agiles Vorgehen, um die Dinge beherrschbar zu machen und nicht in Details unterzugehen
• Retrospektiven und eine Kultur der offenen Kommunikation helfen dabei, auch in schwierigen Gewässern auf Kurs zu bleiben.
• Sei mutig, Dinge anders zu machen -> Hinterfrage Sätze wie „Das haben wir schon immer so gemacht.“