Engineering Operating Model

Einheitliche Codebasis in einem Monat und Orientierung für ein Team im Blindflug

1 bis 2 Tickets: lagen jeweils im Backlog, bei einem Team aus drei Entwicklern
4 Monate: blieb der vorherige Entwickler, bevor er wegen derselben Lücke ging
1 Person: war die einzige Quelle für Aufgaben und Richtung im Team

Ein kritischer Pfad entsteht von links nach rechts über vier Meilensteine, in einer Endlosschleife.

Fallakte

Branche: EdTech
Region: Deutschland
Leistung: Engineering Operating Model
Team: Wayne ArendseLeiter Delivery & TransformationYurii KotulaCEO & Leiter Engineering
Systeme: Turborepo-Monorepo
Next.js-Admin-Panel
Backends in Node.js und Ruby on Rails
Bull-MQ-Worker
Zahlungen über Mollie
Datenlebenszyklus nach DSGVO

Ausgangslage beim Kunden

Der Kunde betreibt in Deutschland eine digitale Lizenzplattform. Das Produkt basierte ursprünglich auf WordPress und WooCommerce. Das Unternehmen entschied, es auf einen modernen Next.js-Stack zu bringen, während die Live-Plattform für die Lernenden weiterlief.

Intelvision stellte drei Entwickler für diese Arbeit. In den ersten Wochen zeigte sich: Das Problem lag nicht im Code, sondern in der Ebene darüber. Die Kraft zur Umsetzung hatte der Kunde. Ihm fehlte das Operating Model, um diese Kraft in eine Richtung zu lenken.

Das geschäftliche Problem

Der Tech Lead des Kunden kannte die Codebasis von innen und prüfte jede Änderung. Planung, Delegation und Roadmap verlangten andere Fähigkeiten, und dafür war niemand zuständig. Die Arbeit kam als einzelne Tickets beim Team an, auf Zuruf in eine Kanban-Spalte gelegt, oft mit Titel, aber ohne Beschreibung.

Im Alltag sah das so aus: Ein Entwickler schloss eine Aufgabe ab, meldete eine leere Warteschlange und wartete, bis ein oder zwei neue Tickets auftauchten. Es gab keine Sprints, keine Planung, kein Grooming und über lange Zeit keine gemeinsamen Calls. Das Team sah nicht über das aktuelle Ticket hinaus und konnte daher nicht sagen, ob noch sechs Wochen Arbeit vor ihm lagen oder sechs Monate. Ein Entwickler, der vor diesem Einsatz dieselbe Position hatte, ging nach vier Monaten und nannte als Grund, dass es keinen geregelten Prozess gab.

Was auf dem Spiel stand

Ein Team aus drei Entwicklern arbeitete mit einem Backlog von ein bis zwei Tickets. Qualifizierte Kapazität lag dadurch jede Woche zeitweise brach.
Der vorherige Entwickler ging nach vier Monaten wegen derselben Lücke im Operating Model. Das gefährdete die Kontinuität und drohte Kosten für eine Neubesetzung zu verursachen.
Alle Aufgaben und die gesamte Ausrichtung liefen über eine einzige Person. Fiel sie aus, stand das ganze Team still.

Was nicht funktionierte

Kein Planungsrhythmus: keine Sprints, kein Grooming, keine Roadmap, die das Team nachvollziehen konnte.
Tickets entstanden auf Zuruf, oft mit Titel, aber ohne Beschreibung.
Nach dem Start des Teams gab es lange Zeit keine festen Team-Calls.
Ein früherer Abgang ging auf dieselbe Ursache zurück, vier Monate nach Beginn des damaligen Einsatzes.

Vorgehen bei der Analyse

Die Analyse betrachtete das Projekt auf drei Ebenen gleichzeitig, denn ein Backlog, das leerläuft, ist nie nur ein Backlog-Problem.

Strategie
Wozu dient die Arbeit?
Der Kunde investiert, um ein funktionierendes Produkt auf einen modernen Stack zu heben, vermutlich vor einer Finanzierungsrunde. Es geht um echtes Geld, also muss die Richtung dahinter für alle nachvollziehbar sein, die umsetzen. Benennen, welches Ergebnis jede Phase der Migration bringen soll; langfristige Ziele für das Team sichtbar machen, statt sie bei einer Person zu lassen; den Ticketfluss an ein Ziel koppeln, das das Team sieht, nicht an spontane Anfragen.
Abläufe
Wohin geht die Zeit wirklich?
Kapazität ging zwischen den Aufgaben verloren, nicht bei ihrer Bearbeitung. Die Entwickler lieferten schnell und warteten dann, bis die nächste Aufgabe definiert war. Einen schlanken Planungsrhythmus für ein Team aus drei Personen einführen; Tickets so beschreiben, dass man ohne Rückfrage starten kann; einen regelmäßigen Abgleich einplanen, damit Prioritäten vorab feststehen und nicht erst auf Zuruf entstehen.
Technologie
Trägt das System die Last sicher?
Der Stack wurde bereits konsolidiert und modernisiert. Die Lücke lag nicht im Code, sondern in den Entscheidungen drumherum. Die Zusammenführung im Monorepo als stabile Basis für jede Änderung beibehalten; die riskanten Migrationen zuerst angehen, damit sich früh zeigt, ob der Plan trägt; das Code-Review wie bisher als Quality Gate beibehalten.

Was sich geändert hat

Die schwierigste Migration kam bewusst zuerst.
Die Checkout-Seite wurde vor den einfacheren Seiten von WooCommerce auf Next.js mit Mollie neu gebaut. Am Checkout hingen Zahlungslogik, Gutscheine und rechtliche Pop-ups. Funktionierte er als Erstes, wusste der Kunde: Es lohnt sich, die gesamte Migration abzuschließen. Diese Entscheidung kam aus dem Engineering selbst, nicht aus einem Plan von oben.
Aus fünf Systemen wurde eine Codebasis.
Mehr als fünf getrennte Repositories (ein mobiles Frontend, ein Node.js-Backend, ein Next.js-Admin-Panel, ein Worker und ein Scraper für staatliche Prüfungen) wurden in einem einzigen Turborepo-Monorepo mit gemeinsamen internen Paketen zusammengeführt. Doppelter Code verschwand, und das Team hatte eine einzige verlässliche Quelle. Die Zusammenführung dauerte etwa einen Monat.
Die Lücke im Operating Model wurde als eigentlicher Engpass benannt.
Die Analyse trennte eine gesunde Umsetzungsebene von einer fehlenden Planungsebene. Die Empfehlung war eindeutig: Ein Team aus drei Entwicklern braucht in dieser Phase einen Product Manager oder Delivery Manager und einen festen Planungsrhythmus. Erst diese Struktur macht aus schneller Umsetzung stetigen Fortschritt.

Entscheidungen

Das Operating Model in Ordnung bringen, nicht nur die Tickets.
Naheliegend wäre gewesen, die Warteschlange einfach weiter zu füllen. Stattdessen benannte das Projekt die fehlende Planungsebene als Engpass, denn ein volleres Backlog im selben kaputten Rhythmus schiebt den nächsten Stillstand nur hinaus.
Infrastruktur vor Features.
Die Zusammenführung der Repositories brachte nichts, was Lernende sehen konnten. Sie kam trotzdem zuerst, weil jede spätere Änderung von einer einzigen, wartbaren Codebasis abhing.
Die schwierigste Migration zuerst.
Mit dem Checkout zu beginnen war riskanter als mit den Landingpages. Es war die richtige Reihenfolge: Der Teil, der am ehesten scheitern konnte, bewährte sich früh, als eine Kurskorrektur am wenigsten gekostet hätte.

Ergebnisse

Bereich	Vorher	Nachher
Struktur der Codebasis	5+ unverbundene Repositories mit doppelt vorhandenem gemeinsamem Code	Ein Turborepo-Monorepo mit gemeinsamen Paketen, zusammengeführt in rund 1 Monat
Checkout-Stack	Bisheriger WooCommerce-Checkout	In rund 4 Wochen auf Next.js mit Mollie neu gebaut
Planungsrhythmus	Keine Sprints, kein Grooming, Backlog von 1 bis 2 Tickets	Lücke im Operating Model erkannt, Planungsstruktur empfohlen
Sichtbarkeit der Roadmap	Richtung lag bei einer Person, für das Team unsichtbar	Als zentraler Engpass benannt, mit einem klaren Weg zur Lösung

Strike Team

Erfahrene Engineering-Leads finden in einer Engineering Diagnostic zum Festpreis den eigentlichen Engpass und bleiben, bis er behoben ist. Project Rescue, Fractional CTO, Architektur und Business Cases.

Mehr zum Strike Team