Agilität im Embedded-Bereich: Unser Start und die ersten Hürden
In den letzten beiden Posts habe ich davon berichtet, dass mein Team im Zuge einer agilen Transformation neu gegründet wurde. Die Werte des Unternehmen haben Agilität als eine zentrale Eigenschaft erkannt, die für eine erfolgreiche Zukunft notwendig ist. Aber was genau bedeutet denn Agilität als Wert in einem Konzern? Heißt das, dass alle jetzt Kanban oder Scrum machen müssen? Mitnichten. Denn der Grundgedanke der Agilität ist es die Kundenwünsche im Laufe des Produktlebenszyklus erfüllen zu können. Dieser Satz ist natürlich wenig aussagekräftig, wenn man ihn auf einen ganzen Konzern anwendet. Agilität sieht in jedem Bereich unterschiedlich aus. Agile Softwareentwicklung sieht anders aus als agile Finanzplanung oder agiles Produktionsmanagement. Alle diese Fachbereiche müssen ihre eigene Implementierung von Agilität umsetzen. Und wenn man es genau betrachtet, haben sich im Laufe der letzten Jahre sowohl in der Embedded-Entwicklung als auch in vielen anderen Bereichen des Konzerns agile Strukturen etabliert, weil sie funktionieren. Vielleicht war es den Entscheidern nicht bewusst, dass sie agile Prozesse schaffen, wenn sie weg gehen von strikter Planerfüllung und Möglichkeiten schaffen, mit Veränderungen der Umwelt umzugehen.
Scrum framework with key artifacts, meetings, and processes [1].
Was genau macht ein Prozess Agile? Und warum muss es denn immer ein Prozess sein? Reicht es nicht seine Arbeitsweise agil zu gestalten? Die letzte Frage lässt sich so weit beantworten, dass ein Prozess, ob formal dokumentiert, oder in der Kultur des Unternehmens verankert lediglich eine im Voraus getroffene Entscheidung ist, wie mit wiederkehrenden Situationen umgegangen wird. Agil wird das ganze, wenn die Möglichkeit besteht im Laufe des Prozesses korrigierend einzugreifen und die Möglichkeit eines Korrektureingriffs allen Beteiligten bewusst und möglich ist. Nicht umsonst zeigt ein Schaubild aus der Literatur für Controlling ein ähnliches Schaubild wie das der Agile Alliance wenn es darum geht die Planung iterativ gegen die Umweltbedingungen anzupassen.
Controlling Prozess aus Basiswissen Allgemeine Betriebswirtschaftslehre [2]
Diese Ähnlichkeiten finden sich immer wieder in der Management-Literatur denn auch in diesem Fachgebiet wurde erkannt, dass wir mit dem klassischen: „Das hat schon mal funktioniert, das machen wir einfach nochmal“ nicht mehr die Innovationen liefern kann, die es benötigt um auf dem Markt relevant zu bleiben. Nach dieser etwas langatmigen Einleitung möchte ich aber jetzt auf unsere Situation vor ungefähr einem Jahr zurück kommen. Im Verlauf von 2024 haben wir versucht Agilität in einem Team zu etablieren, das noch keine oder nur unzureichende Erfahrung mit agilen Arbeitsweisen hatte. Da schließe ich mich nicht aus, theoretisch habe ich mich mit dem Konzept befasst und auch schlussendlich meine Masterarbeit darüber verfasst, doch praktische Erfahrung war noch nicht allzu viel vorhanden.
Das Jahr startete mit der Aufgabe für Bestandsgeräte das alte Linux-System zu updaten und für zukünftige Releases der Geräte fit zu machen. Das haben wir mit unserem strategischen Plan ein einheitliches System auf allen unserer Geräte zu etablieren kombiniert und begonnen ein zentrales Embedded-Linux Projekt auf Basis des Yocto Buildsystems aufzusetzen. Die Bestandsgeräte wurden einmalig mit einem Embedded Linux in Betrieb genommen, das dann nur noch im äußersten Notfall angepasst wurden. Das war mit den neuen Regularien für Produktsecurity nicht vereinbar. Im Fall eines Security Problems müssen wir in der Lage sein zeitnah ein Update ausrollen zu können. Das war zu dem Zeitpunk nicht möglich. Außerdem wurden die Systeme im Rahmen der Produktentwicklung von externen Dienstleistern entwickelt, die nicht mehr im Unternehmen sind und nur eine sporadische Dokumentation zurückgelassen haben. Wir mussten also im Grunde von Null auf ein System aufsetzen, das Anforderungen für eine Applikation erfüllen muss, die nicht dokumentiert waren. Ein perfekter Ausgangspunkt für agile Methoden. Iterative Annäherung an ein unbekanntes Ziel, schnelle Lieferung an den Kunden (hier das Produktteam) und automatisches Deployment um schnell auf entstehende Fehler reagieren zu können. Klingt in der Theorie klasse, doch ohne praktische Erfahrung im Umgang mit solchen Problemstellungen hat sich gezeigt, dass viel Energie und Zeit auf die Kommunikation mit den Produktteams aufgewandt werden muss, was nicht unbedingt die Stärke jedes Entwicklers ist. Hier brauchte es eine andere Lösung.
Ende 2024 haben wir es dann endlich geschafft, genügend Ressourcen frei zu bekommen um das Team mit einem formalen Training mit den agilen Methoden vertraut zu machen. Zusammen mit einem agile Coach für mich als Product Owner und einem Scrum Master für die Organisation der Scrum Events, sind wir in das Jahr 2025 gestartet. Mit einem Backlog aus wild gemischten Anforderungen unterschiedlichen Reifegrads, tollen neuen Ideen und „Das müssten wir auch noch machen“ Themen. Wenn wir noch einmal auf die oben gezeigte Grafik [1] schauen, sehen wir, dass das Backlog die zentrale Anlaufstelle ist, wenn es darum geht die nächsten strategischen Schritte zu planen. Ziel ist es mit jedem abgeschlossenen Thema den Wert des Produkts für den Kunden zu erhöhen. Das können direkte Mehrwerte sein, wie neue Funktionen oder Verbesserung bestehender Funktionalität. Es können aber auch indirekte Mehrwerte sein, wie die Reduktion von zukünftigen Pflegeaufwänden. Diese sind für den Kunden nicht direkt ersichtlich, hier ist die Kommunikation aus dem Team gefragt, um den Mehrwert aufzuzeigen.
Im Laufe des Frühjahres und Sommer habe ich es in Zusammenarbeit mit meinem Agile Coach geschafft das Backlog so aufzuräumen, dass Arbeitsumfänge einigermaßen bekannt waren, dass geplante Liefertermine eingetragen waren und die Umsetzung in einer Roadmap an unsere Kunden kommuniziert wurde. Dabei sind unsere Kunden lediglich andere Entwicklungsteams, die entweder unser Embedded-Linux System einsetzen um ein Produkt zu entwickeln, oder an einem anderen Softwareprodukt arbeiten, das mit unserem System kommuniziert. In dieser Zeit hat es mir sehr geholfen zusammen mit dem Agile Coach meine eigenen Vorstellungen, wie Agilität mit den im Team umgesetzten Arbeitsweisen zu Diskutieren. Sie hat mich auch geholfen die Veränderungsprozesse im Team nicht zu schnell zu forcieren. Veränderung braucht Zeit und je mehr wir am Anfang Zeit aufwenden um das Team die neue Arbeitsweise lernen zu lassen, desto schneller geht es im Großen und Ganzen. Nicht jeder meiner Teammitglieder hat die Theorie hinter den agilen Methoden studiert. Und schon gar nicht im Bezug auf die Integration in ein wirtschaftliches Unternehmen. Wir mussten also langsam laufen um schnell zu sein. Diese Erkenntnis kann ich hier nur unterstreichen. Die Ergebnisse, die wir aktuell liefern sind wesentlich schneller und besser organisiert und wir haben lediglich ein halbes Jahr benötigt um zu lernen was funktioniert und was besser zu machen ist.
Aber es ist natürlich nicht alles Gold was glänzt, im gleichen Zeitrahmen kamen neue Anforderungen für gravierende Umbauten, neue Werkzeuge, dessen Benutzung wir erst noch lernen mussten und Änderungen in der Projektpriorität des Unternehmens. Viele Veränderungen der Umwelt, bei denen wir zeigen konnten, wie gut die von uns gelernten agilen Methoden bereits funktionieren.
Relativ zeitgleich trafen eine Umpriorisierung zusammen mit Verzug in einem weiteren Projekt in dem einer meiner Mitarbeiter gebunden war. Daraus folgten mehrere Abstimmungsrunden mit den Projektleitern und den Budget-Verantwortlichen um abzustimmen was gemacht werden muss und was wir vorerst nicht machen werden. Durch ein relativ gut ausgearbeitetes Backlog konnten die unterschiedlichen Möglichkeiten mit Zeitleisten in Verbindung gebracht werden und so konnten wir eine zu dem Zeitpunkt sinnhafte Entscheidung treffen. Eine weitere Lektion über die es noch mindestens einen Beitrag geben wird. Dann haben wir begonnen mit der Umsetzung der Themen, die als am wichtigsten bewertet wurden und lieferten die erste Variante in unserem August Release. Die dort rudimentär umgesetzte Funktionalität haben wir dann im Oktober Release verbessert und sie für uns abgeschlossen. Der zweimonatige Release Takt ist etwas, das wir 2024 gestartet hatten mit der Intention auf schnellere Releases wechseln zu können. Doch das haben wir bis Ende 2025 aus verschiedenen Gründen nicht geschafft und somit musste die Funktionalität eben in so großen Schritten kommen. Unsere Funktionalität wurde von einer weiteren Software im Technologie Stack des Unternehmens eingesetzt, das bisher eine andere Schnittstelle genutzt hat. Für diese gab es auch noch Inkompatible Änderungen weshalb alles im Oktober mit einem „Big Bang“-Release geändert wurde. Erwartungsgemäß hat es nicht reibungslos geklappt und wir befanden uns in der Integrations-Hölle.
Es wurde neue Bugfix Releases erzeugt, unterschiedliche Teams mussten auf Integration warten, denn ohne abgeschlossenen Test sind die Release Artefakte nicht für die Verwendung freigegeben. Wir befanden uns zu dieser Zeit in konstanter Bug-Arbitrage. Wo genau liegt die Ursache für das gesehene Fehlverhalten? Wird da bereits dran gearbeitet? Können wir bereits in den darunterliegenden Softwareschichten einen Test etablieren, der validiert, dass die neuen Versionen den Fehler nicht mehr beinhalten? Was muss in den nächsten Release, was in den übernächsten, was beheben wir erst später? Alle diese Themen mussten zusätzlich zum Weiterentwickeln der geplanten Features bewältigt werden. Eine Mammutaufgabe, aber dennoch ein Mehrwert. Mit der alten Struktur hätten uns alle diese Fehler im Laufe der nächsten Wochen und Monate eingeholt, dann aber in den Produkten und nicht in der Vor-Produkt Entwicklungsumgebung. Wir haben hier mit klarer Transparenz verhindert, dass zahlreiche Fehler durch unser Testaufbau rutschen und erst in späteren Integrationen gemeldet werden. Am Ende haben wir jetzt ein stabileres System, funktionierende Kommunikationswege zwischen Projekten und eine breitere Testabdeckung unseres Produkts. Wäre das Chaos im Voraus vermeidbar gewesen? Sicherlich. Wir haben Features die bereits im Juni abgeschlossen waren erst im Oktober das erste mal integriert, zusammen mit zahlreichen andern Änderungen. Das entspricht nicht der Idee von vielen kleinen Integrationen, die in einem agilen Ablauf stattfinden. Unsere Testabdeckung ist auf Grund der Komplexität des Systems nicht ausreichend gewesen und ist es jetzt wohl auch noch nicht. Testabdeckung ist ein Thema das nie vollständig ist und mit dem Projekt wächst und reift.
Agilität ist kein Selbstzweck. Prozesse die theoretisch agil sind, treffen in der Realität auf Termine, Prioritäten und Änderungen der Geschäftsumwelt. Aber durch ihre Agilität können sie auf die Realität angepasst werden und liefern ein Rahmenwerk um mit vielen Situationen effizient umgehen zu können. Für die Entwicklung von Embedded Software, die neben den applikativen Anforderungen auch Anforderungen an Hardware, Systemschnittstellen und andere Software hat ist Agilität nicht immer nach Lehrbuch einsetzbar, aber auf jeden Fall machbar. Auch agile Prozesse müssen sich den ändernden Umweltbedingungen anpassen.
[1] Cinkusz, Konrad & Chudziak, Jaroslaw & Niewiadomska-Szynkiewicz, Ewa. (2025). Cognitive Agents Powered by Large Language Models for Agile Software Project Management. 10.48550/arXiv.2508.16678.
[2] Gerd-Inno Spindler. Basiswissen Allgemeine Betriebswirtschaftslehre. Springer Gabler.
https://doi.org/10.1007/978-3-658-31126-1