Developer Experience verbessern: Engineering Velocity Schritt für Schritt steigern

Developer Experience – kurz DevEx oder DX – wird oft missverstanden. Es geht nicht um Komfort, nicht um schöne Tools und nicht um das Wohlbefinden einzelner Entwickler als Selbstzweck. Developer Experience ist ein Produktivitätsfaktor.

Konkret bedeutet Developer Experience: Wie viel kognitive Last tragen Entwickler, die nichts mit dem eigentlichen Problem zu tun hat, das sie lösen sollen? Wie viel Zeit geht täglich für Konfiguration, Umgebungs-Setup und administrative Tätigkeiten verloren – Dinge, die im Geschäftsergebnis unsichtbar sind, aber real Zeit und Motivation kosten?

Ein Entwickler muss sich mit der Plattform auseinandersetzen – das ist unvermeidlich. Aber er muss nicht jedes Detail eines Kubernetes-Deployments kennen, nur um ein Feature zu testen. Wenn das die Realität ist, ist das kein Kompetenzproblem. Es ist ein Developer Experience-Problem.

Es gibt einen Satz, den kennt jedes Entwicklungsteam: „Bei mir läuft es.“ Gemeint ist: lokal, in der eigenen Umgebung, mit den eigenen Konfigurationen. In der Produktion – oder auf dem Rechner eines Kollegen – sieht das dann anders aus.

Das „It works on my machine“-Syndrom ist kein Einzelproblem und kein Zufall. Es ist ein Symptom. Ein Zeichen dafür, dass Entwicklungsumgebungen nicht standardisiert, nicht reproduzierbar und nicht produktionsnah sind. Wer es früh erkennt, kann gegensteuern – bevor es zu echten Produktionsausfällen kommt.

Hinter dem Stillstand stecken selten technische Probleme allein. Meistens sind es Annahmen – über Rollen, Verantwortlichkeiten und die Frage, wer sich wem anpassen muss. Diese Annahmen sind in vielen Organisationen tief verwurzelt und werden selten explizit ausgesprochen. Genau deshalb sind sie so wirksam.

Diese Überzeugung ist weit verbreitet – und sie ist falsch. Entwickler müssen sich mit einer neuen Plattform vertraut machen, neue Arbeitsweisen übernehmen, dazulernen. Das ist richtig und zumutbar. Aber sie müssen nicht von heute auf morgen ein anderer Mensch sein.

Eine Plattform ist kein Selbstzweck. Sie ist ein Werkzeug – und ein Werkzeug hat sich den Menschen anzupassen, die damit arbeiten, nicht umgekehrt. Eine Plattform, die Entwickler zwingt, sich vollständig neu zu orientieren, bevor sie produktiv sein können, hat ihr eigentliches Ziel verfehlt.

Der richtige Ansatz dreht die Perspektive um: Entwickler sollen eine Plattform vorfinden, auf der sie produktiv arbeiten können. Das ist keine Frage von Komfort – sondern von Wirksamkeit.

Der am häufigsten unterschätzte Faktor ist die kognitive Last. Die letzten Jahre haben in vielen Engineering-Organisationen eine massive Komplexitätszunahme gebracht – mehr Tools, mehr Abstraktionsschichten, mehr Verantwortung für Entwickler. Diese Komplexität wurde oft einfach weitergegeben, ohne sie zu strukturieren oder zu reduzieren.

Das Ergebnis: Entwickler tragen eine kognitive Last, die nichts mit dem eigentlichen Problem zu tun hat, das sie lösen sollen. Sie müssen Kubernetes-Deployments verstehen, CI/CD-Pipelines konfigurieren und Infrastruktur-Entscheidungen treffen – parallel zur eigentlichen Entwicklungsarbeit.

Ein weiterer unterschätzter Punkt ist die Einführung von Plattformen selbst. Zu oft wird dabei auf Demos und YouTube-Videos verwiesen, die zeigen, wie einfach alles ist – ohne zu berücksichtigen, dass das Fundament stimmen muss, bevor man darauf aufbaut.

Wissen, was zu tun ist, und wissen, wie man anfängt, sind zwei verschiedene Dinge. Das Engineering Velocity Framework ist kein Alles-oder-nichts-Ansatz – es ist ein iterativer Weg, der mit einem klaren ersten Schritt beginnt.

Schritt 1: Bestandsaufnahme – Toollandschaft bewerten

Der erste und wichtigste Schritt ist eine ehrliche Bestandsaufnahme. Nicht isoliert beim Platform-Team, nicht isoliert bei den Entwicklern – sondern gemeinsam. Wo geht täglich Zeit verloren? Welche Tools funktionieren, welche erzeugen Reibung? Wo entstehen Wartezeiten, und warum?

Diese Aufnahme liefert keine generischen Antworten, sondern konkrete, priorisierte Erkenntnisse – zugeschnitten auf die eigene Infrastruktur, die eigenen Teams und die eigenen Engpässe. Erst auf dieser Basis lassen sich sinnvolle nächste Schritte definieren.

Schritt 2: Eine App, ein Team – fokussiert starten statt in die Breite gehen

Der häufigste Fehler beim Start: zu breit ansetzen. Unternehmensweite Rollouts, die alle Teams gleichzeitig umstellen wollen, scheitern an ihrer eigenen Komplexität.

Der richtige Ansatz ist der umgekehrte: Eine konkrete Applikation, ein konkretes Team. Den Prozess dort durchdenken, optimieren und zum Laufen bringen – und dann skalieren. Immer vom Einfachen zum Schwierigen. Was in einem Team funktioniert, kann auf andere übertragen werden. Was in einem Big Bang eingeführt wird, hat keine zweite Chance.

Schritt 3: Quick Wins, die sofort Vertrauen schaffen

Vertrauen in eine neue Plattform entsteht nicht durch Versprechen – sondern durch Erfahrungen. Deshalb sind frühe Quick Wins entscheidend, nicht weil sie das Problem lösen, sondern weil sie zeigen, dass es lösbar ist.

Zwei Bereiche eignen sich dafür besonders: erstens die Standardisierung von Environments, weil sie sofort spürbar ist – Onboarding geht schneller, Setup-Probleme verschwinden. Zweitens die Inner Dev Loop, weil eine messbar kürzere Feedback-Zeit im Arbeitsalltag täglich wahrgenommen wird.

Wenn Entwickler plötzlich wieder Spaß an der Arbeit haben – weil Dinge einfach funktionieren – steigt die Akzeptanz der Plattform. Und mit der Akzeptanz steigt die Adoption. Das ist kein angenehmer Nebeneffekt. Es ist das Ziel.

Echte Engineering Velocity zeigt sich nicht in Dashboards – sie zeigt sich im Arbeitsalltag. Environments werden stabiler. Deployments werden vorhersehbarer. Und das Platform-Team wird seltener für Routineaufgaben gebraucht, weil Entwickler sie selbst erledigen können.

Die Kosten des Stillstands sind real – sie sind nur schwer sichtbar. Kein Produktionsausfall trägt das Label „verursacht durch schlechte Developer Experience“. Kein Quartalsreport weist aus, wie viel Entwicklungszeit in Konfiguration und Warten versickert ist.

Aber das größte Risiko ist ein anderes: das Schatten-Team. Entwickler, die die Plattform dauerhaft umgehen, bauen parallele Strukturen auf, die nie produktionsnah getestet werden. Irgendwann muss deployed werden – und dann zeigt sich, was monatelang verborgen war.

Dazu kommt ein strukturelles Problem: Wer heute nicht in Developer Experience investiert, kämpft morgen mit Fluktuation. Gute Entwickler wechseln nicht nur wegen Gehalt. Sie wechseln, wenn sie das Gefühl haben, mehr mit Werkzeugen zu kämpfen als mit echten Problemen. In einem Markt, in dem Entwickler knapp sind, ist das kein abstraktes Risiko – es ist eine konkrete Gefahr für die Lieferfähigkeit.