Nach einigen Jahren, die wir mit der Entwicklung eines neuen Produkts verbracht hatten, bei dem eine Verzögerung die nächste eingeholt hat wurde die Entwicklungsabteilung einer „agilen Transformation“ unterzogen. Es wurden aus Sparten eine gemeinsame Entwicklungsabteilung aufgebaut. Mit Gruppen (Chaptern) die die Gewerke Mechanik, Elektronik und Software abdecken und von jeweils einem Gruppenleiter (Senior Chapter Lead) geführt wurden. Innerhalb der Gruppe gab es Teamleiter (Chapter Lead) für spezielle Themenbereiche die wiederum zwischen 4 und 10 Mitarbeiter geführt haben. Die neue Struktur hat erfordert, dass neue Führungskräfte benötigt wurden, die die Mitarbeiter der Chapter führen sollten. Ich habe zu dieser Zeit die Führung des Firmware und Betriebssystem Chapters bekommen, das im Gewerk der Elektronik beheimatet war. Die Aufgabe war es die Firmware (Dieser Begriff ist sehr überladen und wurde in diesem Fall auf das BSP für Mikrocontroller angewendet) und Embedded Betriebssysteme zu betreuen. Dazu gehörten Windows CE und diverse Linux Systeme von Produkten die schon lange ohne Updates des Systems in Serie liefen. Die Chapter, als Sammelpunkt für Fachwissen über die jeweiligen Themengebiete bedienen die Projekte mit den Mitarbeitern, die benötigt werden um die Ziele der Projekte in den geplanten Zeiträumen erreichen zu können. In der Theorie zumindest.
Mein Team bestand aus vier Entwicklern, die aus unterschiedlichen Software Entwicklungsbereichen kamen. Zwei haben seit Jahren Embedded Linux Systeme entwickelt und gepflegt, ein anderer hat hauptsächlich mit Mikrocontrollern gearbeitet, aber viel Erfahrung in der Administration von Linux Systemen. Der vierte kam aus dem Bereich der Softwareentwicklung als Dienstleistung und hat für das Unternehmen bereits als Dienstleister diverse Software und Systeme entwickelt. Alle mit nicht abgeschlossenen Themen von vor der Umstrukturierung, Pflegethemen aus den letzten Jahr(zehnt)en Und ich mitten drin, der Elektroniker, der hier ein Team aufbauen will und noch eine Leiterplatte durch die EMV Messung und Funkzulassung bringen muss.
Drei der vier Teammitglieder kamen aus einer früheren Sparte, der vierte kam aus einer anderen Sparte. Es hat einige Monate gedauert, bis wir im allgemeinen Sprachgebrauch, wenn wir uns über Lösungen und anstehende Herausforderungen unterhalten haben, nicht mehr von „ihr“ und „die“ sondern von wir gesprochen haben. Regelmäßige Termine, bei denen gemeinsam über historische Entscheidungen und Lessons Learned gesprochen haben hat dazu geführt, dass die Sprechart ein Zusammenwachsen vermuten lies. Da die Aufgaben noch sehr geteilt sind, eines der Projekte ist nach wie vor nicht abgeschlossen und bindet einen der Entwickler Vollzeit. Alle anderen arbeiten bereits an einer vereinheitlichten Linux Distribution.
Ein Team von Grund auf aufzubauen ist wie ein Haus zu bauen. Dabei kommt es neben einem stabilen Fundament auch noch auf die stabilen Wände und ein solides Dach an. Das Fundament ist eine gemeinsame Vorstellung wie die technisch richtige Lösung aussehen könnte. Die Wände und das Dach schirmen das Team vom rauen Wetter außerhalb ab, sodass sie sich auf das Fundament konzentrieren können. Doch wie soll das Haus aussehen? Ein Blockhaus aus soliden Baumstämmen? Ein gemauertes Haus aus Ziegelsteinen oder doch lieber ein Zelt, das schnell umgestellt werden kann, wenn der Untergrund nicht die versprochene Stabilität liefert?
In einem neu zusammengestellten Team, vor allem nach einer organisatorischen Änderung, gibt es keine gemeinsamen Prozesse, es werden weiterhin Ergebnisse gefordert, aber welche? Wo beginnt man den Erschaffenden Teil, also die zweite Hälfte der Transformation? Wir haben ein Jahr lang nach bestem Wissen und Gewissen versucht eine Struktur in die Aufgaben und Arbeitspakete zu bringen. Gleichzeitig haben wechselnde Prioritäten zu enormer Unsicherheit geführt. Arbeiten dauerten länger als gedacht, dadurch sind nachfolgende Tätigkeiten später begonnen worden und die Welle an unerledigten Themen wuchs von Woche zu Woche. Das, in Kombination mit Unwissen über die korrekte Verwendung der Softwarewerkzeuge, führte zu einem sehr anstrengenden Jahr. Der Arbeitsvorrat war enorm, unübersichtlich und teilweise Furcht einflößend. Die Ressourcen waren knapp und würden absehbar auch nicht vergrößert. Hinzu kam der organisationspolitische Druck weiterhin umzustrukturieren und alle Code erzeugende Teams im Software-Chapter zusammen zuziehen. Nach monatelangen Diskussionen und Abstimmungen wie welche Aufgabe aufgeteilt wird, haben alle beteiligten eingesehen, dass Vier Personen für die im Chapter anfallenden Themen zu wenig sind. Daher wurde das Chapter aus der Elektronik in die Software umgezogen. Dort standen dann mehr Softwareentwicklungsressourcen in Form von zwei externen Entwicklungsdienstleistern zur Verfügung und wir konnten uns auf die Bearbeitung des Bergs konzentrieren. Neue Projekte, die unsere Unterstützung benötigen kamen ständig dazu und so war es keine Seltenheit, dass eine Person mehrere Hüte auf hatte (oder bis heute noch auf hat).
Ein weiteres Jahr verging und wir haben es geschafft bis zum Ende 2024 genügend Fortschritt zu erreichen, dass es absehbar wurde, dass die Zielerreichung möglich ist. In der Softwareorganisation haben wir begonnen zu investieren. Nicht in noch mehr Programmierer, sondern in Projektmanagement. Wir haben drei Scrum Master ins Unternehmen geholt, die die Projekte dabei unterstützen sollten aus dem, zu diesem Zeitpunk, reaktiven Projektmanagement in ein agil vorausschaues Projektmanagement zu kommen. Eines dieser Projekte war mein eigenes, die allgemein einsetzbare Linux Distribution, die sowohl auf die bereits im Feld befindlichen Systeme als auch auf die neuen Projekte abzielt.
Mit dem Kick-off Ende 2024 haben wir innerhalb von 12 Monaten mehrere Teams mit Hilfe agiler Methoden aus dem reaktivem Entwickeln in strukturiert vorgehende, agil und vorausschauend handelnde Teams verwandelt. Das wichtigste dabei war die klare Kommunikation innerhalb und zwischen den Teams. Das Anwenden vorgegebener agiler Werkzeuge hilft dabei die Rollen klar zu definieren und zu verteilen. Welche Aufgabe hat wer und was wird von den einzelnen im Detail erwartet. Außerdem haben wir Zeit darin investiert die Vision klar zu formulieren und uns alle auf die gemeinsame Vision zu einigen. So ging der Marathon also los. Der Berg an aufgelaufener Arbeit wurde regelmäßig in kleinen Häppchen untersucht, umgedreht und beleuchtet. Was muss wann gemacht werden, was machen wir nicht oder nicht jetzt? Alle diese Fragen wurden für alles was sich in diesem Haufen aufgestaut hat beantwortet. In den ersten Monaten habe ich mich gefühlt wie Sisyphus, jedes mal wenn es so aussah als hätte man etwas erreicht hat sich dahinter nur noch weitere Arbeit verbogen. Nach ungefähr 6 Monaten hat es jedoch deutlich abgenommen und wir haben im Team einen spürbaren und deutlich sichtbaren Fortschritt erreicht. In der Zeit wurden weitere Teams mit Scrum Mastern in die agile Arbeitsweise des Scrums eingeführt und betreut. Der Informationsfluss zwischen den Teams lief über geregelte Kanäle, in Tickets aufgezeichnet um Blockaden sichtbar zu machen und vor allem zivilisiert. In der Zeit ohne klare Kommunikationskanäle hatte jeder die Befürchtung sein Anliegen würde hinter andern zurückstecken müssen, weshalb die Kommunikation immer in Superlativen und mit möglichst vielen hochrangigen Führungskräften in CC geführt wurde.
Eine agile Transformation benötigt Zeit. Die Methoden sind dafür ausgelegt eine konstante hohe Leistung zu ermöglichen, ohne Energie in kurzzeitiger Überbelastung zu verbrennen. Wir haben 6 Monate benötigt, bevor das Gefühl eingetreten ist, dass es wirklich einfacher wird, mit dem Arbeitsvorrat umzugehen. Weitere 6 Monate haben gezeigt, dass andere agile Ansätze, wie das häufige Releasen von Software hilft nachfolgende Teams mit weniger Integrationsaufwand zu belasten. Das hält den Prozess schlank und schlanke Prozesse laufen leichter, was zu einer Mitkopplung führt und so das Arbeiten noch weiter vereinfacht. Die Vorarbeit dafür ist allerdings nicht zu vernachlässigen. Arbeit benötigt Ressourcen, da kommt man auch nicht mit agilen Prozessen drumherum. Agile Methoden lassen Planungsaufwände nicht auf magische Weise verschwinden, sie werden nur über den Projektverlauf verteilt statt zu Beginn auf einmal aufzutreten.
Nachfolgend sind Zusammenfassungen über was bei uns funktioniert hat.
Transparenz schaffen. Über aktive Themen, anstehende Themen, Themen die gerade nicht bearbeitet werden und identifizierte Blockaden und was dagegen unternommen wird; Oder auch nicht unternommen wird.
Klar festgelegte Kommunikationswege zur Kommunikation zwischen Teams. Dabei haben diese Kanäle den Vorteil eventuell weitere Stakeholder hinzuziehen zu können, da sie einen Überblick über die Kommunikation zwischen den Teams haben. Uns hat ein Scrum of Scrums geholfen die Kommunikation und zeitliche Taktung von Arbeitsaufgaben zu koordinieren. Dabei haben sich Vertreter der Scrum Teams regelmäßig getroffen um gemeinsam die nächsten Aufgabenpakete abzustimmen, sodass Abhängigkeiten erkannt und daraus resultierende Aufwände frühzeitig erkannt werden konnten.
Schnelles Releasen. Zu Beginn haben wir ein Release gemacht, wenn wir etwas abgeschlossen hatten. Da mein Team ein Produkt hat, das anderen Teams zuarbeitet kommen für uns Tests mit dem eigentlichen Kunden nicht in Frage. Für unser Produkt sind die Projektteams die Kunden und Kunden wissen nicht was sie wollen. Wenn sie es dann bekommen erkennen sie, dass sie eigentlich was anderes brauchen. Daher so schnell und häufig wie möglich releasen. Dabei ist auch zu achten, dass Funktionen nicht kippen, sondern bestehende Funktionalität erst dann entfernt wird, wenn die nachfolgende Funktionalität getestet und verwendbar ist. Das mach vereinzelt Zusatzaufwände, ist aber langfristig wertvoller, da die neue Funktionalität genutzt werden kann ohne dass es zu Funktionseinschränkung führt.
Ein Team entsteht nicht durch Organigramme, sondern durch Vertrauen und gemeinsame Ziele. Vertrauen muss erarbeitet werden durch gemeinsame Wertschätzung und gemeinsame Arbeit. Jeder im Team hat seine Aufgabe und technische Lösungen haben meistens keinen einzige richtige Lösung. Wenn die Kultur im Team geprägt wird vom Wertschätzen der einzelnen Beiträge, dann kann ein kleines Team großartiges schaffen.
