Warum ich mich für den MBA neben dem Job entschieden habe

22. Dezember 2025 by Platinenmacher Leave a comment

Warum ich einen MBA gemacht habe und was es mit gebracht hat.

Viele haben mich gefragt: „Warum ein MBA, du bist doch Ingenieur?“ Die Antwort ist einfach: Ich wollte verstehen, wie Unternehmen funktionieren – über Technik hinaus. Ich habe in den vorherigen Post davon geschrieben, dass ich die Sprache verstehen will, die in Unternehmen außerhalb der Entwicklungsabteilungen gesprochen wird. Und da war für mich der logische Startpunkt das Studium der Wirtschaftswissenschaften. Da ich allerdings bereits einen Hochschulabschluss besitzen konnte ich mit einem höheren Abschluss gezielt in die Richtung gehen, die mich interessiert hat. Weg vom allgemeinen BWL hin zu Geschäftsführung. Ich habe nicht vor in diesen Bereich zu wechseln. Das eigentliche Führen des Geschäfts darf gerne jemand anderes machen. Aber ich möchte wissen wie die Ticken und warum Entscheidungen getroffen werden, die aus der Sicht eines Ingenieurs nicht nachvollziehbar sind. Einfach um die richtige Sprache zu sprechen, wenn es darum geht die richtige Entscheidung zu treffen.

Als Teamleiter habe ich bereits im ersten Jahr gemerkt, dass Entscheidungen nicht nur von Technologie abhängen, sondern von Strategie, Finanzen und Menschen. Alles das sind zusätzliche Felder, die im Ingenieurswesen nicht so ausführlich gelehrt werden. Dort geht es viel mehr um die beste Lösung für das aktuell vorliegende Problem. Produktkosten zu hoch, kein Problem, dann machen wir ein Projekt zur Kostenreduktion. Die Konkurrenz hat ein neues Produkt und wir haben Ideen, es noch besser zu machen? Kein Problem. Projekt zu Produktneuentwicklung. Aber ist das überhaupt der richtige Weg? In Anbetracht der anderen Projekte, die gleichzeitig laufen sind die Ressourcen vielleicht an anderer Stelle besser aufgehoben. Aber das sind strategische Entscheidung, die macht das Management. Und ich möchte in der Lage sein hier die Richtige Sprache zu sprechen und das große Bild zu sehen, zu verstehen und beeinflussen zu können.

Die Suche nach einem berufsbegleitenden Master Studiengang mit Inhalten, die interessant sind. Hat mehrere Wochen und einige Beratungstermine gekostet, aber schlussendlich habe ich mich für das General Management Studium an der Hochschule Fresenius entschieden. Der Umfang und die Themen, die im Modulplan aufgezeigt wurde haben mich am meisten angesprochen.

Die Anmeldung zum Studium war schnell erledigt. Anmeldeformular für die 18 Monate Full-Power Variante unterschrieben, Bachelor Urkunde suchen und eine beglaubigte Kopie anfertigen lassen, Passbild und Personalausweis Kopie angehängt und fertig. Ein paar Tage später ging es dann los mit dem Zugang zum Online-Portal. Dort warteten 15 Module auf mich und ich habe mich zu denen angemeldet, die für das erste Semester empfohlen waren. Dann ging sie Los die Schlacht mit den eBooks. Jedes Modul hatte mindestens ein Fachbuch, das im Laufe des Moduls herangezogen wurde. Also lesen, lesen, lesen und noch mehr lesen.

Doch wie kann man sich das alles behalten, vor allem wenn es in den Abendstunden und am Wochenende passiert und unter der Woche Tagsüber ganz andere Themen im Mittelpunkt standen? Die erste Technik, die ich für mich ausprobiert habe war das sortieren der Information anhand eines digitalen Zettelkastens. Das habe ich mit dem Tool LogSeq aufgesetzt, aber es gibt viele andere Anbieter, die die gleiche Funktionalität haben. Nachdem ich das erste Buch (Methodenhandbuch der Betriebswirtschaftslehre, Amazon Affiliate Link, kauft es euch nicht!) in mehrere hundert Zettel zerlegt habe, aber danach hauptsächlich über das Zettelkasten Verfahren Bescheid wusste und nichts zu Methoden der Betriebswirtschaftslehre, habe ich meine Strategie geändert. Ich habe mir während ich gelesen habe jeden Absatz in eigenen Worten, handschriftlich, zusammengefasst. Dabei habe ich absichtlich darauf verzichtet, den Text zu tippen, denn handschriftlich kann ich wesentlich langsamer schreiben als ich denke. Das führte dazu, dass ich auch mehr über die Themen nachgedacht habe, während ich sie aufgeschrieben habe. Es war nicht komplett analog, ich habe mir ein Remarable2 gekauft, das ist wie ein Schreibblock, nur eben mit Digitalisierung um Hintergrund, sodass ich meine Notizen dann auch auf dem Monitor anschauen konnte. Nachdem ich das zweite Buch mit dieser Methode gelesen hatte und im Anschluss auch wusste, was der Inhalt ist, habe ich mich mit der Technik an die Klausurvorbereitung gemacht. Ich habe alle meine Zusammenfassungen durchgelesen und weiter, ebenfalls handschriftlich, zusammengefasst. Somit hatte ich am Ende um die 10 Blätter handschriftliche Zusammenfassung pro Buch und bin in die erste Klausur gestartet.

Die Klausur kann entweder alle zwei Monate Vorort, oder zu einem beliebigen Zeitpunkt online geschrieben werden. Das Anmeldefenster der Vorortstermine habe ich leider verpasst und wollte keine zwei Monate warten. Der Plan sah ja vor in 18 Monaten damit durch zu sein. Also dann eben die digitale Klausur. Anforderungen: Windows, Chrome und eine Webcam. Webcam hatte ich, das andere musste ich mir organisieren. Der Firmenlaptop hat es nicht erlaubt Chrome zu installieren, war also auch keine Alternative. Von Microsoft gab es für Studenten eine kostenlose Windows 11 Lizenz. Also habe ich mir eine VM aufgesetzt, darin Windows installiert und so meine Testklausur geschrieben. Technik funktioniert.

Bevor man mit der Klausur starten kann, muss man einmal seinen Personalausweis und den Studentenausweis in die Kamera halten, dann den Raum und die Umgebung aufzeichnen in der man die Klausur schreiben möchte und ab geht es. Ich musste erst mal meinen Schreibtisch von all dem Kram befreien, der da sonst so herum liegt. Das war keine leichte Aufgabe aber ich habe nicht lange gebraucht, bis sich das Chaos wieder auf dem Tisch ausgebreitet hat. Die Klausur wurde auf einer Webseite geschrieben, die im Vollbild angezeigt wurde. Chrome hat diverse Hotkeys von Windows deaktiviert, so konnte man beispielsweise nicht in einen anderen Tab wechseln, ohne dass die Klausur beendet wurde. Ist ja auch richtig, man soll die Klausur ja mit dem eigenen Wissen schreiben und nicht mit den Büchern im anderen Tab arbeiten. Allerdings hat die UX der Seite einen Nachteil. Es gab keine maximale Breite. So waren die Eingabefelder für Freitextantworten fast so breit wie das Browserfenster, also so breit wie der Monitor. Das ergibt auf einem Tablett oder Laptop auch Sinn. Aber ich habe an meinem Schreibtisch einen 34″ Ultra-Wide Monitor. Also gefühlt einen ganzen Meter Textfeld. Super unergonomisch so darauf zu schreiben. Und Fenster kleiner machen? Ging ja nicht, weil Klausurüberwachungsextension um Chrome. Aber ich bin ja nicht auf den Kopf gefallen, ich habe meiner VM einfach einen Full-HD Monitor verpasst, dann hat sich das Gaze in Grenzen gehalten und beim Filmen des Arbeitsbereiches hat man dann links, rechts, oben und unten graue Bereiche um das Fenster mit dem Browser gesehen. Hat geklappt. Wenn sich das überhaupt mal jemand angeschaut hat…

Jetzt aber rein in die erste Klausur. 30 Multiple Choice fragen, kein Problem, ein Punkt pro Frage. Zwei drein waren mir nicht sofort klar, kann ich aber später nochmal rein schauen, wenn ich die Freitextaufgaben gelöst habe. Es folgten 7 Freitextaufgaben zu je 10 Punkten. Ich legte los meine Antwort zur Frage 1 zu tippen, schneller als ich denken kann und so musste ich viel wieder raus löschen, weil sich die Finger verknotet haben. Aber geschafft, Frage 1 ist beantwortet. Etwas länger gebraucht als ich für die Frage im Zeitbudget hatte, aber was soll’s, die nächsten Fragen gehen bestimmt schneller. Frage zwei und drei liefen dann ganz gut, aber auch hier habe ich keine Zeit gut machen können. Bei Frage vier wollte ich am Ende die Absätze ein wenig umstellen, denn in einer andere Reihenfolge haben sie aufeinander aufgebaut. Also Strg+x zum Ausscheiden und Strg-v zum Einfügen. Aber nichts da. Der Text in der Zwischenablage wurde ersetzt mit „Das Einfügen von Text wurde durch das Klausur Überwachungs-Tool verhindert“. Strg+z ging übrigens auch nicht mehr. Mein kompletter erster Absatz war weg und ich hatte nur noch wenige Minuten Zeit um mich um die nächsten Fragen zu kümmern. Das ganze lässt sich auch in der Bewertung der Klausur erkennen. Gab es für die ersten beiden Fragen noch volle Punktzahl, hat das ab der vierten rapide abgenommen, nicht weil ich es nicht wusste, sondern weil ein Teil verloren ging und ich sowieso zu viel Zeit am Anfang verbummelt habe. Tja, das war es dann wohl mit der ersten Klausur. Ergebnis: 3,2.

Ich hatte aber keine Zeit zu verlieren, denn ich wollte ja in 1/12 Jahren fertig sein. Also nicht lange ärgern, die nächsten Klausuren habe ich dann Vorort handschriftlich verfasst und das hat geholfen. 1,0 und 1,3 kann sich sehen lassen. Manchmal ist es doch besser, wenn man langsamer schreibt. Vor allem wenn es keine zweite Iteration gibt in der man die Umsetzung gegen die Anforderungen abgleichen kann. Darauf folgten diverse Hausarbeiten mit anschließender Fragerunde und der Inhalt des ersten Semesters war im Kasten. Die Module des zweiten Semesters liefen auch ganz gut. Bis ich die Crux fand. Finance and Finance Organisation. Klingt harmlos, ist es mit BWL Bachelor wahrscheinlich auch. Aber ich musste erst mal lernen, wie eine Bilanz erstellt wird. Das hat ganz schön aufgehalten, dann kam noch dazu, das der zweite Teil des Moduls Risikomanagement war. Also gleich zwei sehr umfangreiche Themengebiete in einer Klausur. Ach-ja und als ich dann so weit war meine Klausur anzumelden… Fehlanzeige, die Anmeldefrist von 10 Tagen bezieht sich auf Arbeitstage und die sind im Frühsommer ja nicht unbedingt zwei Wochen. Also wieder eine Online Klausur. Ich wusste ja mittlerweile, dass ich Text nicht richtig editieren kann, also alles schön langsam und mit Bedacht getippt. Die Klausur ging 3 Stunden und ich war danach geistig ausgelaugt. So erschöpft habe ich mich noch nie gefühlt, weder nach einer anstrengenden Sport Session, noch nach intensiver Geistesarbeit. Aber ich habe es geschafft, nicht gut, aber geschafft. 3,0.

Der Inhalt des letzten Semesters kann kommen. Zwei Hausarbeiten und dann die Masterarbeit. Während ich für die Hausarbeiten der letzten beiden Semester recherchierte, habe ich ein Thema gefunden, dass ich auch im Berufsalltag spannend finde. Die Messbarkeit von Agilität. Hierzu wollte ich meine Arbeit schreiben, eine kleine Forschungsarbeit, die ich im Unternehmen durchführe, während ich meine eigentliche Arbeit auch noch machen darf. Ich habe mir zwar im Voraus zusichern lassen, dass ich die Masterarbeit im Unternehmen schreiben kann und dafür auch Zeit bekomme, aber wie das nun mal so ist, manche Themen warten nicht auf einen guten Zeitpunkt, sondern wollen gleich bearbeitet werden. Also habe ich die Richtung für meine Masterarbeit gefunden: Bewertung des Agilen Reifegrads der Entwicklungsabteilung. Doch ich konnte die Arbeit erst anmelden, wenn ich mindestens 85% der Credit-Points erreicht habe. Wie praktisch, dass das Abschließen aller Module mir 86% der erreichbaren CP geben. Da hat sich ja einer was bei gedacht. Nur blöd, dass ich dazu jetzt noch zwei Hausarbeiten abgeben muss. Also habe ich beide parallel erstellt. Natürlich zu zwei komplett unterschiedlichen Themen. wäre ja auch sonst zu einfach. Und nachdem ich dann endlich für die letzte Hausarbeit den Vortrag gehalten und einige Tage später die Note hatte, konnte ich meine Masterarbeit anmelden. Und dann? Das Prüfungsamt hat 4 Wochen Zeit die Anmeldung zu bearbeiten, haben sie auch ausgenutzt. Also wieder ein Monat vorbei. Der Plan die Arbeit noch bis Dezember 2024 zu schreiben war also dahin. Ich durfte erst im Oktober damit startet.

Die Arbeit bestand aus dem Auswerten eines Fragebogens, dieser musste aber erst einmal von möglichst vielen Mitarbeitern ausgefüllt werden. Und wenn man in einem Unternehmen mit Betriebsrat eine Befragung von Mitarbeitern durchführen will, dann gelten da klare Regeln, was abgefragt werden darf und was nicht. Also habe ich ungefähr einen Monat damit verbracht die Fragebogen zu erstellen und ihn sowohl von der Personalabteilung als auch dem Betriebsrat freigeben zu lassen. Dann vier Wochen Befragungszeit und schon war Dezember. Ich habe also die Auswertung der Befragung in die Weihnachtspause mitgenommen. Den Januar habe ich damit verbracht die eigentliche Arbeit zu schreiben, die Ergebnisse zu diskutieren und alles Rund zu bekommen, der Februar ging für das Lektorat drauf und im März habe ich dann endlich abgegeben. Nach 26 Monaten hatte ich meinen MBA in General Management abgeschlossen. Klingt verrückt? War es auch.

Dabei habe ich nicht nur viel über Methoden zum Lernen von neuem Fachwissen und zur Stressbewältigung gelernt, sondern auch verschiedene Perspektiven innerhalb der Betriebswirtschaftslehre eingenommen. Dabei habe ich viele neue Dinge gelernt und spannende Einblicke in andere Unternehmensstrukturen bekommen. Immerhin habe ich bisher nur in einem Unternehmen gearbeitet. Die Hilfsarbeiter Jobs während der Schulzeit und mein Work-and-Travel Jahr lasse ich mal außen vor.

Das was ich in diesen zwei Jahren gelernt habe lässt sich nicht so einfach zusammen fassen. Aber was wirklich zählt, ist nicht die Theorie allein, sondern die Fähigkeit, verschiedenste Perspektiven zu verbinden. Und das habe ich gelernt.

Agile Transformation – Wo wir angefangen haben und warum

15. Dezember 2025 by Platinenmacher Leave a comment

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.

Vom Elektronik-Ingenieur zum Software-Teamleiter – Meine ersten Schritte

13. Dezember 2025 by Platinenmacher Leave a comment

Ein Sprung ins kalte Wasser – ständiges schwimmen um nicht unterzugehen, aber mit Land in Sicht.

Ich habe mich für dich als Gruppenleiter für das Embedded Firmware Team entschieden. Dieser Satz hat Anfang 2022 mein Berufsleben und meinen Ausblick in die Zukunft fundamental verändert. Bis dahin war ich Elektronik Entwickler, tief in der Hardware-Design und Low-Level Programmierung. Plötzlich ging es nicht mehr nur um Stützkondensatoren, Controllerauswahl, Leiterplattendesign, sondern um Menschen, Prozesse und Verantwortung.

Die erste große Umstellung, die ich erfahren musste, war der Weg vom „Ich löse das Problem selbst“ zum „Ich ermögliche anderen, Probleme zu lösen“. Doch bevor ich das konnte, musste ich erst einmal die mitgebrachten Probleme lösen, die ich aus meiner vorherigen Rolle mitgebracht habe. Da der Wechsel im selben Unternehmen stattfand, habe ich neben den neuen Aufgaben auch noch alle bisherigen auf meinem Tisch liegen. Das Team das ich leite bestand aus Softwareentwicklern, die alle im Rahmen von vorherigen Projekten an Embedded-Linux Systemen gearbeitet haben. Dorthin konnte ich die Elektronik Probleme des Projekts aus dem ich gerade kam nicht delegieren. Also doch selbst lösen und langfristig für eine Veränderung der Verantwortung sorgen. Leichter gesagt als getan. Das Projekt in dem ich vor dem Stellenwechsel gearbeitet habe ist nicht abgeschlossen. Es stehen noch so viele Arbeitspakete aus, die nicht nur ich noch liefern sollten. Auch sind die Ressourcen so dünn verteilt, dass mein Weggang zu einem massiven Verzug im Zeitplan geführt hat. Was nicht gerade geholfen hat die bereits begonnenen Themen zeitnah zu beenden und mit dem Projekt abzuschließen. Der Plan sah vor das Gerät bis Mitte 2022 in die Serienproduktion zu überführen. Was allerdings nicht funktionierte, da es für den bestimmten Einsatzbereich nicht genügen Rechenperformance hatte. Initial vorhergesagte Leistungsanforderungen an die CPU der Embedded Baugruppe, die zu Projektbeginn die Hardwareauswahl bestimmten, reichten mit der jetzt verfügbaren Software doch nicht aus. Trotzdem sah der Projektplan eine Fertigstellung bis Mitte des Jahres vor. Also wurde alle Tätigkeiten, die man zur Erreichung des Projektziels erfüllen musste nach Plan durchgeführt. Eine EMV und Funkzulassung mit der Hardware, die erwiesenermaßen nicht leistungsfähig genug ist. Eine Weiterführung des Wartungsvertrags für die extern bezogene Baugruppen, zwei Lieferanten für eine stabile Supply-Chain. Alles für die Tonne, denn das Produkt erfüllt nicht die Leistungsanforderungen.

Plan B musste schnell her. Parallel zur Abarbeitung des Meilensteinplans wurde die Hardware neu entworfen und von einer komplett extern bezogenen Baugruppe auf eine Inhouse gefertigte, wesentlich leistungsfähigere Lösung gewechselt. Dieser Wechsel von Bezugsteil auf Fertigungsteil hat in der Projektkostenrechung nicht annähernd den Kostenumfang bekommen, den er verdient hätte. Die Aufgaben, die mit der bestehenden Hardware durchgeführt wurden haben eine Großteil des Puffers im Budget aufgebraucht. So standen wir nun vor der Situation mit sehr geringen finanziellen Mitteln eine komplexe Baugruppe zu entwerfen und eine passende Software zu entwickeln. Die Anforderungen an die Software waren so vage, dass wir im Grunde genommen alles hätten bauen können, was wir wollten, so lange es eine gewisse Webseite mit genügend Performance anzeigen kann. Die Wünsche an Funktionen waren umfangreich, der Zeitplan kurz und das Budget so gut wie nicht vorhanden. Es gab kein dediziertes Projektteam sondern nur Fachkenner, die neben ihrer Hauptaufgabe noch zusätzlich dieses Projekt bedient haben. So neben bei halt. Total easy. Nicht hilfreich war es, dass das große Projekt, zu dem diese Produkt ein Zubehör war auch mit enormen Verzögerungen zu kämpfen hatte und es nicht schaffte auf den Markt zu kommen. Somit bestand kein Zeitdruck, denn wenn das Zubehör vor dem eigentlichen Produkt auf den Markt kann, kauft es ja trotzdem keiner.

So dümpelte das Projekt von Monat zu Monat weiter, wurde mit minimalem Einsatz gerade gut genug gehalten um die vage formulierten Anforderungen grün zu testen. Es gab Kräfte im Unternehmen, die von dem Mehrwert des Zubehörs zum eigentlichen Produkt nicht überzeugt waren und die haben erwartungsgemäß auch nicht dazu beigetragen, dass der Projektablauf schneller lief, oder die hergestellte Qualität stieg. Alles in allem ein typisches Projekt, dass nach gravierenden Änderungen der Umwelt den ohnehin schon dünn aus-geplanten Plan stur verfolgte. Immerhin haben wir das schon mehrmals gemacht und es ist immer ein Produkt bei herausgenommen, dass unseren Kunden einen Mehrwert geleistet hat. Klassisch nach dem Wasserfall. Ist die Entwicklung fertig, folgt die Pflege. Aber ja keine neuen Funktionen. Hier trafen agile Denkweisen auf die bis dahin ausgeübten klassischen Projektplanungen. Mit dem Unterschied, dass man vergaß, dass Eigenentwicklung neben Zeit auch noch Ressourcen, also Geld benötigt. Als es absehbar war, dass wir den von uns auf die aktuell verfügbare Funktionalität angepassten Testplan erfolgreich abschließen können, wurde genau das gemacht „agil“ die Anforderungen so geschrieben, dass die Funktionalität validiert werden konnte. Somit ist das Produkt jetzt fertig und alle sind happy.

Ganz so einfach ist es natürlich nicht. Das Projekt hängt voll in der Schwebe. Die ersten Kunden haben bereits ihre Bestellung erhalten und arbeiten damit, allerdings gibt es keine Vision, wie wir in Zukunft mit diesem Zubehör weitere Mehrwerte schaffen können. Die gewünschte Funktionalität ist nur in einem minimalen Umfang umgesetzt, die es uns erlaubt die gewünschten Funktionen als umgesetzt zu bezeichnen, wohl wissend, dass alles was nicht explizit ausformuliert war nicht umgesetzt ist.

Doch was ist der Fehler, den ich gemacht habe? Ich habe keinen direkten Einfluss auf Projektentscheidungen und habe nur mit meinem Fachwissen geholfen das Projekt irgendwie über die Ziellinie zu schieben. Dabei haben wir sowohl die Ziellinie näher an das Produkt und das Produkt mit Stützrädern versorgt um das Ziel zu erreichen. Wenn ich ein Projekt sehen, das in einer vergleichbaren Situation steckt, dann werde ich nicht mehr versuchen das Ziel irgendwie zu erreichen, sondern versuchen darauf zu drängen das Ziel noch einmal, angepasst an die aktuelle Umwelt, zu hinterfragen und eventuell neu zu definieren. Denn wenn zum aktuellen Zeitpunkt nicht klar ist, was der Mehrwert für den Kunden ist, dann sollte an dieser Stelle angesetzt werden und nicht blinde Planerfüllung stattfinden.

Das hier oben beschriebene Beispiel hat keinen direkten Bezug zur Software-Teamleitung, oder? Stimmt. Aber es zeigt sich, dass Projektmanagement ein fundamentaler Bestandteil der Entwicklung ist. Software will agil entwickeln, also mit variablem Scope, kurzen Iterationsschleifen und früher Lieferung an den Kunden. Doch was ist der Kunde? Der, der nachher das Produkt aus dem Regal nimmt? Auch. Auf dem Weg trifft das Produkt aber auf viele Kunden. Das betrifft vor allem Software für Hardware basierte Produkte. Embedded Systeme sind fundamental komplexer als reine Software Produkte. Hier sind die Kunden, in der Literatur auch als Stakeholer bezeichnet, auch die Kollegen der anderen Fachbereiche Elektronik und Mechanik. Denn dort funktioniert Agilität etwas anders als bei Software. Der Klick auf „Kompilieren“ bei einer Leiterplatte kostet gerne vier- bis fünfstellig und dauert mehrere Wochen. Bei Kunststoff Spritzguss kann man an beide Werte noch eine Größenordnung dranhängen. Aber das sollte uns nicht davon abhalten hier auch Agilität zu denken. Dazu werden ich in späteren Beiträgen näher eingehen. In diesem Beitrag belassen wir es einfach mit der Erkenntnis, dass Kommunikation mit anderen Fachbereichen (oder auch Schnittstellenpartnern im gleichen Bereich) nicht nur ein „Soft Skill“ ist. Es ist der Schlüssel zum Erfolg. Entscheidungen trotz mangelnder Informationslage werden vereinfacht, wenn die Informationslage aktiv verbessert wird. Das ist einer der Grundsätze der Agilität. Transparenz in Fortschritt, Probleme und Meilensteinerreichung schaffen. Dabei geht es nicht darum einen Schuldigen am Projektverzug zu finden, sondern Transparenz zu schaffen um frühzeitig auf Probleme reagieren zu können.

Neben den Tätigkeiten im oben beschriebenen Projekt habe ich auch noch mein eigenes Team aufbauen dürfen. Gegründet wurde das Team während einer organisationalen Umstrukturierung. Der Organisationsaufbau hatte die letzten Jahre die einzelnen Geschäftsbereiche des Unternehmens mit einer eigenen Entwicklungsabteilung und eigenem Budget aufgesetzt. Durch globale Umstrukturierung in den Geschäftsbereichen wurden alle in der Niederlassung in der der ich arbeite ansässigen Entwicklungsabteilungen in eine neue Organisation transformiert. Dabei wurden Technologien in Chaptern organisiert, hier sind die einzelnen Personen mit Technologiebezug aufgehoben. So auch meine neue Gruppe mit Firmware und Embedded-Linux Bezug. Diese Chapter versorgen dann die unterschiedlichen Projekte mit Technologiewissen für die Implementierung der dort notwendigen Funktionalität. In der Theorie klingt das ganz logisch. Alle Softwareentwickler in eine Gruppe und dann Personenweise in die Projekte verteilt, um mögliche Freiräume so gut wie möglich abdecken zu können.

Um eine einheitliche Gestaltung der von den Chaptern erstellten Funktionalität über die Projekte zu erreichen wurden Technologie Arbeitsgruppen gebildet. Doch so schön das alles ist, sobald Projekte mit potenziellem Verzug drohen, werden alle vorausschauenden Tätigkeiten eingestellt, wenn sie nicht von einer bestimmten Person weiter getrieben werden.

„Du musst auch mal abgeben“ das war der Rat, den ich versucht habe zu befolgen. So habe ich die Aufgabe die Technologie Arbeitsgruppe für das einheitliche Embedded-Linux abgegeben. Ich wollte in dem Bereich nicht als der Manager erscheinen, der alles besser weiß und jetzt wird gemacht wie ich sage. Mir ist durchaus bewusst, dass ich fachlich teilweise weit hinter den Mitgliedern meines Teams zurückstehe. Ich bin Elektronik-Ingenieur und haben nur 15 Jahre Berufserfahrung . Das ist das nicht anders zu erwarten, wenn nur fähige und erfahrene Softwareentwickler in meinem Team sind. Aber ein Projekt ohne Budget und ohne direktes Produkt als Ergebnis zu leiten ist etwas neues, sowohl für mich als auch für die Softwareentwickler in meinem Team. Also musste ich nach einigen Monaten die schwere Entscheidung treffen, das ich das nicht delegieren kann sondern musste die Verantwortung für diese Projekt wieder zu mir nehmen. Das ist jetzt ungefähr ein Jahr her. In der Übergangsphase hatte ich dann drei Hüte auf. Das nie enden wollende Projekt für das Produkt Zubehör, die disziplinarische Leitung der Gruppe von Softwareentwicklern und die Leitung des Projekts zur Vereinheitlichung des Embedded Linux in unseren Produkten. In dieser Zeit lief nebenbei auch noch das berufsbegleitende Studium. Ich würde es nicht unbedingt empfehlen, aber ich habe in der Zeit neben den ganzen technischen, theoretischen und praktischen Erfahrungen auch viel über mich selbst und über meine Stressresistenz erfahren.

In der Zeit hat es geholfen in der Kommunikation auf volle Transparenz zu setzen. Ich weiß, dass ich in den letzten Jahren eine große Bandbreite an technischem Fachwissen aufbauen konnte, aber ich weiß auch, dass ich nicht alles weiß. Daher der klare Versuch im Team mit den Fachkennern das Vertrauen aufzubauen gemeinsam die beste Lösung zu finden. Auch wenn das nicht unbedingt die bequemste Lösung ist.

Abschließend möchte ich noch über ein Erfolg bei den ganzen Schwierigkeiten in den vorherigen Absätzen berichten. Diese Jahr haben wir genau ein Jahr lang mit agilen Methoden im Embedded-Linux Projekt gearbeitet. Wie die Transformation von „ja, agil hab ich schon mal gehört“ zu einem funktionierenden Ablauf im Team stattgefunden hat und welche Hürden auf dem Weg zu nehmen waren, ist dann Inhalt des nächsten Beitrags.

Warum ich wieder anfange zu bloggen – Motivation und Ziele

13. Dezember 2025 by Platinenmacher Leave a comment

Ich habe während der Zeit meiner Ausbildung zum Elektronik-Ingenieur und der Zeit in der ich als solcher gearbeitet habe viele Beiträge hier verfasst. Seit November 2013 183 um genau zu sein. Als Elektronik-Ingenieur war ich lange Zeit tief in der Welt der Elektronischen Komponenten und Hardware von Embedded-Systemen verwurzelt. In dieser Zeit habe ich zusammen mit Chris einen Podcast gestartet, der es auf über 40 Episoden geschafft hat. Der Podcast ist bei Spotify und iTunes gelistet. Ich habe in der Zeit von Corona auch angefangen bei Twitch.tv zu streamen. Da gab es regelmäßig Content zu Elektronik, Embedded Software und alles rund um den Themenkomplex. Alles mit der Prämisse, bis es funktioniert und nicht weiter.

Anfang 2022 hat sich für mich eine neue Möglichkeit eröffnet und ich habe mich auf eine Gruppenleiterstelle beworben. Im April 2022 wurde das dann auch Realität: Ich bin jetzt nicht nur für die Erledigung meiner zugewiesenen Aufgaben zuständig, sondern auch noch für das Management von echten Menschen! Das ist etwas, dass ich während meiner Ausbildung nie für mich selbst gesehen habe. Manager sind die, die einem als Entwickler das Leben schwer machen, die Budgets klein halten und überall nur Kosten einsparen wollen. Und jetzt bin ich selbst in der Rolle mit der Intention es besser zu machen. Da war ich also nun mit meinem eigenen Team. Neu gegründet aus Personen, die während organisationaler Umstrukturierung in den Topf Embedded Linux und Firmware geworfen wurden. So ging sie los die Reise vom Elektronik Entwickler zum Software Engineering Manager.

Das erste Jahr war gefüllt mit „Altlasten“, also Projekten an denen ich noch Elektronik entwickelt habe, deren Laufzeit länger gingen als geplant (ein Symptom, das die ganze agile Transformation beheben sollte). Ich habe mit den ganzen neuen Ideen, meiner Vision für das Team und den organisationalen Struktur ein turbulentes Jahr erlebt, das geprägt war von Überstunden und teilweise starken Kontextwechseln. EMV-Probleme mit der Netzwerkeinheit eines Produkts, die ich noch als Elektronikentwickler designend habe, Zulassungsprobleme eines WiFi Funkmoduls im Frequenzbereich von WiFi6 und die nächste Besprechung, in der es die notwendigen Personalressourcen für die strategische Ausrichtung unseres Embedded Linux Projekts zu verteidigen galt. In all diesem Trubel wollte das Team auch einen gewissen Zusammenhalt entwickeln, also habe ich mich, neben den rein technischen Problemen auch noch zwischenmenschlichen Konflikten gewidmet. Das kalte Wasser in das ich geworfen wurde war sehr kalt. In dieser Zeit hat es geholfen, dass ich nicht alleine mit all diesen Themen stand. Ich hatte Mentoren in Form meines eigenen Vorgesetzten, anderen Gruppenleitern und einem Coach, mit der ich all die nicht technischen Probleme und Situationen durchsprechen und mit einem Blick „von Außen“ eingeordnet bekam.

Ich hatte im Laufe des Jahres immer mehr Kontakt zu anderen nicht Engineering Managern. Die haben teilweise eine ganz andere Sprache gesprochen, als das in der Entwicklung zwischen den Ingenieuren üblich war. Ich habe zu diesem Zeitpunk gemerkt, dass es hier ein Übersetzer benötigt, der sowohl mit den Ingenieuren die technischen Details besprechen, als auch mit den Betriebswirten, dem Marketing und allen anderen nicht technischen Rollen im Unternehmen sprechen kann. Also habe ich mich dazu entschieden ein Fremdsprachen Studium parallel zu meinem gefüllten Arbeitstag zu verfolgen. Ich habe MBA General Management an der Hochschule Fresenius studiert.

Die einzige Möglichkeit hierfür Platz zu schaffen war es für die Zeit des Studiums andere Hobbys zu pausieren. Daher gab es seit Januar 2023 auch keine Podcasts oder Twitch streams mehr. Ich habe in der Zeit stattdessen die Felder der Agilen Führung von Unternehmen, Finanzorganisation, Marketing Management, Internationales Management, Generative KI, Datenanalyse für unternehmerische Entscheidungen, wirtschaftswissenschaftliche Modellierung, Organisationsmanagement, strategisches Management, Personalmanagement, Digitalisierung und Volkswirtschaftliche Managemententscheidungen ergründet.

Alle diese Disziplinen habe ich mit dem Blick des Elektronik-Ingenieurs begonnen und, so hoffe ich zumindest, mit einem erweiterten Horizont beendet. Warum möchte ich also wieder mit dem Bloggen beginnen? Ich habe im Studium viel Text produziert. Das hat mir geholfen Konzepte wirklich zu verstehen. Dabei war ein großer Faktor das wirklichen ausformulieren meiner Gedanken und nicht nur das stichpunktartige auflisten von Schlagworten, oder kurzen Sätzen. Ich möchte einerseits für mich das ganze weiterführen, also Konzepte ausformulieren, damit ich sie für mich selbst besser greifbar mache, andererseits aber auch anderen die Möglichkeit geben mit mir gemeinsam zu lernen und zu wachsen.

Ich bin der festen Überzeugung, dass wenn wir immer in der Komfortzone bleiben in der wir alles gut genug können, wir einen ganz großen Teil dessen verpassen, was wir leisten könnten. Daher werden hier in der nächsten Zeit in unregelmäßigen Abständen Beiträge erscheinen, in denen ich praktische Einblicke für Ingenieure, die in Führungsrollen wechseln geben möchte. Außerdem habe ich mich im Laufe des Studium mit agilen Methoden, nicht nur für die Softwareentwicklung, beschäftigt und möchte auch hierzu meine Gedanken ausformulieren.

Mein Ziel: Ich bringe mir selbst Klarheit in Bereiche in denen ich bisher hauptsächlich unbewusst agiert habe und gebe euch die Möglichkeit mit mir dazu in den Dialog zu gehen.

Was euch erwartet: Persönliche Geschichten aus meiner Transformation vom Elektronik Entwickler zum Engineering Manager; Lessons Learned aus der agilen Praxis wenn es sich nicht nur um Softwareprodukte handelt; Technische und organisatorische Tipps für stabile Prozesse, die für mich funktioniert haben.

Warum das für dich wichtig ist: Vielleicht befindest du dich nicht in meiner Situation, arbeitest aber mit Personen die es sind; Oder du hast ein ganz anderes Umfeld, das überhaupt nichts mit Entwicklung zu tun hat. Es ist erstaunlich welche Parallelen es zwischen vermeintlich unabhängigen Umfeldern gibt.

Wie ich nicht vergesse, was ich noch machen wollte

5. Januar 2025 by Platinenmacher Leave a comment

Mitten in einem Teams Call mit dem Team wird ein Thema angesprochen, um das sich mal gekümmert werden müsste. Kaum ist der Satz gefallen und alle haben dem zugestimmt, ist es auch schon wieder vergessen. Die Person, die den Hinweis gegeben hat, hat das Thema mental abgehakt, die Information wurde ja kommuniziert. Die Personen, die zugestimmt haben haben lediglich eine Meinung geäußert und wenn es eine zustimmende Meinung war, dann bleibt emotional auch nicht viel hängen. Negative Emotionen haben ein viel größeren Einfluss auf unser Erinnerungsvermögen [1]. Doch was passiert, dann? Wahrscheinlich nichts. Oder es kommt wieder, diesmal in eskalierter Form.

Während der Mittagspause in der Kantine wirst du von einem der Projektmanager zu einem Thema angesprochen und nach einem Bericht gefragt, den du vor ein paar Wochen erstellt hast. Details stehen im Bericht, der ist aber gerade nicht verfügbar (Immerhin sind wir gerade beim Essen) und du versprichst mit den Informationen im Nachgang auf den Projektmanager zu zukommen. Aber bis du wieder am Schreibtisch bist, hast du das natürlich wieder vergessen.

Doch wie kann ich verhindern, dass wir immer wieder von Themen heimgesucht werden, die wir initial mal angesprochen, dann aber in Vergessenheit gerutscht sind. Wie kann ich verhindern, dass ich Zusagen, die ich in Gesprächen gegeben nicht vergesse? In Zeitmanagement zwischen Teamführung und Studium habe ich beschrieben, wie ich mir Wissen aneigne und meine Zeit einplane.

Aufzeichnen

Der erste Schritt, den ich gehe ist das Thema einzufangen, ich mache mir eine Kurze Notiz auf einem Notizzettel, im Handy oder in einem der Tools mit denen ich sowieso arbeite. Wenn das Tool es unterstützt ein Fälligkeitsdatum festzulegen, dann setze ich das auf den aktuellen Tag. Beim Einfangen ist es wichtig, zeitnah in den nächsten Schritt überzugehen. Denn jetzt ist die Informationslage noch frisch.

Ansetzen

Beim Ansetzen gilt es zu entscheiden, was zur Ausführung notwendig ist. Betrifft es mehrere Personen, also ist eine Abstimmung notwendig, wie im ersten Beispiel; Oder reicht es wenn nur ich etwas machen muss, wie im zweiten Beispiel. Je nachdem welcher Zeitrahmen zum Bearbeitung zur Verfügung steht oder wie dringend das Umsetzen ist, plane ich in meinen Kalender einen Abstimmungstermin, oder für mich selbst einen Zeitslot ein. Ziel ist es zu diesem Zeitpunkt entweder mit dem Schritt Aufarbeiten, oder direkt mit dem letzten Schritt, dem Ausführen, weitermachen zu können. Dieser Schritt kann für alle Themen, die sich im Aufzeichnungszustand befinden gesammelt durchgeführt werden. Ich nehme mir jeden Tag drei Zeitpunkte vor, an denen ich die Aufzeichnungen weiter bearbeite. Morgens, nach der Mittagspause und vor Feierabend.

(Aufarbeiten)

Bei Themen, die eine Abstimmung benötigen, beispielsweise Änderungen in unserem agil entwickeltem Software Projekt, oder eine Verbesserung in einer extern genutzten API, müssen weitere Personen involviert werden. Für die Änderungen in unserem agil entwickelten Software Projekt steht mit dem Refinement-Termin sogar ein fester Zeitpunkt für die Aufarbeitung zur Verfügung. Für Themen außerhalb des Scrum Rahmens müssen gemeinsame Termine über den regulären Weg vereinbart werden.

Ausführen

Der letzte Schritt in der Kette ist das Ausführen. Zu diesem Zeitppunkt wurde das Thema ordentlich vorbereitet und ist nicht in Vergessenheit geraten. Jetzt muss es nur noch umgesetzt werden. Ziel erfüllt.