Hendrik Dahmke: Product Velocity braucht gemeinsames Verständnis

Viele Organisationen haben agile Teams, abgestimmte Planungszyklen und moderne Werkzeuge. Trotzdem verlieren sie Zeit zwischen Management, Systems Engineering, Hardware und Software. Das Problem liegt selten in einem einzelnen Team. Es entsteht dort, wo Vision, technisches Verständnis und Entscheidungsfreiheit nicht zusammenpassen.

Hendrik Dahmke betrachtet Product Velocity aus der Perspektive eines Systems Engineers. Sein Ausgangspunkt ist die Frage, wie Systeme so entwickelt werden, dass Menschen ihre Zusammenhänge verstehen und Verantwortung übernehmen können. Dabei verbindet er Erfahrungen aus Scrum und SAFe mit technischer Autonomie und einem konkreten KI-Projekt.

Dieser Artikel ist ein Gastbeitrag. Hendrik beschreibt darin sein persönliches Verständnis von Product Velocity.

Gastbeitrag von Hendrik Dahmke: Was ist Product Velocity für mich?

Warum ich mich freue, dass jemand darüber schreibt

Ubiquitous Computing war mein letzter Kurs in der Uni. Es ging darum, Systeme so mit der Umwelt zu vereinbaren, dass diese nicht auffallen. Ein Beispiel war ein Bauer, der wissen wollte, ob ein weibliches Schwein schwanger ist oder nicht. Ihm wurden viele Lösungen vorgestellt, aber keine davon wollte er haben. Heute hat er zwei LEDs an der Wand, eine rote für schwanger, eine grüne für nicht schwanger. Die Schweine gehen ihren gewohnten Gang, Technik unter dem Boden scannt die Schweine, die LED zeigt an: schwanger oder nicht. Der Bauer weiß sofort Bescheid. Das ist mein Lieblingsbeispiel für Ubiquitous Computing.

Der andere wichtige Punkt aus diesem Kurs ist „Time to Market“. Es bringt nichts, das beste System zu haben, wenn es keiner nutzt.

„Die Universität hat mich mit zwei Ideen entlassen, die ich bis heute nicht losgelassen habe: Systeme, die unsichtbar funktionieren, und Produkte, die rechtzeitig ankommen.“

Hendrik Dahmke

Die Universität hat mich mit zwei Ideen entlassen, die ich bis heute nicht losgelassen habe: Systeme, die unsichtbar funktionieren, und Produkte, die rechtzeitig ankommen. Dann kam das Berufsleben: Scrum-Teams, SAFe, Quartalsplanungen. Gute Frameworks, aber irgendwo zwischen der Vision des Managements und dem tiefen Wissen der Ingenieure geht etwas verloren. Nicht weil die Menschen schlecht sind. Sondern weil das System keine Brücke zwischen ihnen baut.

Scrum, SAFe und die fehlende Brücke

In einem Scrum-Team habe ich gelernt, wie man zusammen Software agil entwickelt. Agil bedeutet, auf Wünsche einzugehen. Bei Scrum geht es darum, in vorgegebenen Zeiten Werte zu liefern, sei es neue Funktionalität, Anpassungen der Funktionalität oder für das Team in Form von Refactoring.

Was aber, wenn das Team nach Scrum arbeitet, jedoch nicht der Kunde und der Kunde während der Zeitabschnitte doch Änderungen haben möchte?

Dann gibt es aber auch SAFe, kurz Scrum in groß mit mehreren Scrum-Teams. Im Kern geht es darum, zusammenzusitzen, zu überlegen, was wir in noch längeren Zeitabschnitten schaffen können, und die Abhängigkeiten, die man zu anderen Teams hat, sichtbar zu machen. Durch diese Kommunikation soll man ein besseres Bild vom Ganzen bekommen.

Dazu hat sich SAFe erweitert und nimmt auch agile Hardwareentwicklung mit. Ein weiterer Schritt für Ubiquitous Computing: Wenn die Hardware weiß, was die Software will, kann man die Hardware anpassen und umgekehrt.

Was aber, wenn das Management oben steht und nicht ganz versteht, was die Teams genau machen? Das Management hatte eine Vision, eine Idee, und wollte diese umsetzen. Was aber, wenn der CTO nicht ganz versteht, wie man diese umsetzen kann oder was man dafür braucht?

Wenn das Management nicht ganz versteht, wie diese Scrum-Teams arbeiten, wie kann das Management dann Vertrauen haben, dass die Vision richtig umgesetzt wird? Wenn der CTO nicht ganz versteht, wie man die Vision technisch umsetzen kann, wie soll die Technik sie dann umsetzen können?

Product Velocity öffnet den Problemraum

Die Vision ist nicht das Problem. Sie ist der Antrieb, warum wir Sachen machen. Die Teams sollen diese Vision umsetzen. Scrum und SAFe sind Frameworks primär für die Softwareentwicklung. Ein Punkt, der mir gefehlt hat, ist die Systementwicklung oder auch der Problemraum: Was soll dieses System können? Welche Aufgaben sollen gelöst werden? Hier kommt Product Velocity ins Spiel.

Product Velocity nimmt einen Systems-Engineering-Blick auf die Entwicklung ein, auf Hardware, Software und das Management. Damit öffnen wir den Problemraum und finden heraus, welche Funktionalität das System braucht, um seine Aufgaben zu lösen. Genau das schafft gemeinsames Verständnis.

Ich mag den Begriff Product Velocity. Velocity ist für mich ein Vektor mit Geschwindigkeit. Die Geschwindigkeit ist die Summe aus Management, Hardware und Software. Das Produkt kann sich also nur so schnell bewegen wie alle drei individuell.

Verantwortung und technische Autonomie

Product Velocity nimmt also direkt auch das Management mit in die Verantwortung. Ein Management, das Verantwortung übernimmt, überträgt dieses Handeln auch an die Teams, und diese wiederum zeigen mehr Verantwortung. Durch diese Verantwortung entstehen Geschichten wie die von Ingenuity. Als ein für die Lagebestimmung benötigter Sensor nicht mehr wie vorgesehen genutzt werden konnte, griffen die NASA-Ingenieure auf eine vorhandene Trägheitsmesseinheit (IMU) zurück – Sensorik, wie sie in ähnlicher Form auch in Smartphones eingesetzt wird. Über die Beschleunigungssensoren der IMU und die Mars-Schwerkraft konnten sie die Neigung der Drohne mathematisch bestimmen. Statt neue Hardware zu benötigen, lösten sie ein Hardwareproblem mit vorhandener Sensorik, Software und tiefem Systemverständnis.

Product Velocity beginnt nicht mit einem Framework. Es beginnt mit der Frage: Versteht das Management wirklich, was die Teams bauen, und verstehen die Teams wirklich, wohin das Management will? Wenn beide Antworten Ja sind, bewegt sich das Produkt. Wenn nicht, bewegt sich nur die Zeit.

„Autonomie ist eine Bedingung, die für Ingenieure geschaffen wird, damit sie Entscheidungen innerhalb ihrer Expertise treffen und ausführen können, anstatt darauf zu warten, dass ein Prozess jede Entscheidung vorgibt.“

Hendrik Dahmke

Autonomie ist eine Bedingung, die für Ingenieure geschaffen wird, damit Ingenieure Entscheidungen innerhalb ihrer Expertise treffen und ausführen können, anstatt darauf zu warten, dass ein Prozess jede Entscheidung vorgibt. Genau diese Rahmenbedingungen muss das Management schaffen.

Ein KI-Projekt als Beispiel

In meinem Fall betreue ich ein Projekt, in dem wir Künstliche Intelligenz für Systems-Engineering-Aufgaben einsetzen wollen. Mir wurde die Freiheit gegeben, selbst eine Roadmap zu erstellen. Auch wenn ich eine Vorstellung hatte, musste ich mich selbst in dieses Thema einlesen und ausprobieren. So habe ich eine Validierungspipeline für Anforderungen mit Claude in sieben Minuten erstellt. Ich habe gesagt, was ich gerne machen würde: ein Projekt für das Validieren und Verifizieren von Anforderungen, nicht mehr, nicht weniger.

Einige Minuten später hatte Claude einen Prototypen erstellt. Mir war nicht bewusst, wie groß der Umfang war und was KI-Systeme heute können. Ich hatte keine Begrifflichkeiten. All das wurde mir von Claude gebaut und erklärt.

Damit hatte ich ein Fundament, um eine mögliche Roadmap zu erstellen, Use Cases zu definieren und herunterzuschreiben, wo die Reise hingehen sollte. Damit bewaffnet konnte ich das Projekt leiten und auf Kurs halten.

Ich weiß aber nicht alles. Die zugrunde liegende Softwarearchitektur stammt von meinem Kollegen. Genau wie ich hatte er sich in das Thema eingelesen. In diesem Bereich hatte er seine Roadmap erstellt. Zusammen haben wir unsere Ideen zusammengebracht.

Unser Management hat uns nicht gesagt, wie wir KI einsetzen sollen. Es hat das Problem beschrieben, das wir lösen wollen. Den Weg dorthin mussten wir selbst finden. Genau das verstehe ich unter technischer Autonomie. Nicht, dass niemand hinschaut. Sondern, dass alle verstehen, welches Problem gelöst werden soll, und den Ingenieuren zutrauen, den besten Weg dorthin zu finden.

Was Kontrolle kostet

Stellen wir uns für einen Moment das Gegenteil vor. Für jede technische Entscheidung müssten wir zunächst das Management überzeugen. Für jede Richtungsänderung bräuchten wir eine Freigabe. Jede neue Erkenntnis würde erst durch mehrere Ebenen laufen, bevor wir sie ausprobieren dürften. Hätten wir jede Entscheidung erst erklären und genehmigen lassen müssen, hätten wir wahrscheinlich immer noch über den ersten Use Case diskutiert. Stattdessen hatten wir innerhalb weniger Minuten einen funktionierenden Prototypen. Nicht weil wir schlauer waren, sondern weil wir ausprobieren durften.

Die Alternative klingt so absurd, dass sie nicht real sein kann. Leider ist sie in vielen Unternehmen Realität. Fehlendes Vertrauen und fehlendes technisches Verständnis werden durch Kontrolle ersetzt. Langfristige Ziele und damit echte Innovation werden durch arbiträre Erfolgszahlen in einer Excel-Tabelle ersetzt, die Monat für Monat eingehalten werden müssen. Das Management hat nicht einfach Vertrauen gegen Kontrolle eingetauscht, sondern das optimiert, was es messen konnte, da niemand etwas Besseres für das Management gebaut hat.

Fazit

Es geht nicht darum zu fragen, was wir können oder nicht. Es ist wichtig zu akzeptieren, dass Verantwortung für das Management bedeutet, zu verstehen, was das Team braucht. Für das Team heißt es, die Initiative zu ergreifen. Erst dann können wir die Frage stellen: Sind wir bereit, Verantwortung zu übernehmen?

Über Hendrik Dahmke

Hendrik Dahmke arbeitet als Systems Engineer und erstellt Systemmodelle. Ihn beschäftigt, wie Menschen technische Systeme verstehen, wie Komponenten und Funktionen zusammenwirken und warum technisch funktionierende Systeme trotzdem Orientierung vermissen lassen.

Auf seinem Blog The Systems Engineer schreibt er über Systems Engineering, Software, Organisationen und verständliche Technik. Sein Ziel ist, Systeme so sichtbar zu machen, dass Ingenieure und Nutzer ihre Zusammenhänge und Entscheidungen nachvollziehen können.