Wenn Ihr Team zu groß wird: Das hat bei uns wirklich funktioniert
Sechs Monate gescheiterter Experimente. Das haben wir dabei tatsächlich herausgefunden.
Sommer 2024. Unser Team war auf vierzehn Leute gewachsen, und plötzlich fühlte sich alles falsch an.
Stand-ups zogen sich über 45 Minuten hin. Die halbe Mannschaft starrte auf ihre Bildschirme und hörte offensichtlich nicht zu. Von ausgelieferten Features erfuhren wir im Nachhinein, meist wenn ein Kunde sie erwähnte.
Irgendetwas war kaputtgegangen, und wir wussten nicht genau, wann.
Als es anfing schiefzulaufen
Diese täglichen Check-ins? Die reinste Folter. Marko erzählte von seiner API-Arbeit, während Miloš auf sein Handy starrte und ganz offensichtlich ans Mittagessen dachte. Darija erklärte derweil ihre CSS-Probleme einem Raum voller Backend-Entwickler, denen das herzlich egal war.
Während wir uns in Meetings zu Tode langweilten, passierte die eigentliche Arbeit im Verborgenen. Jemand erwähnte beiläufig, er habe gerade ein Feature ausgeliefert, von dem keiner von uns je gehört hatte. Meist, weil Stefan aus dem Marketing um „einen kleinen Gefallen“ gebeten hatte und unsere hilfsbereiten Entwickler ihn einfach … erledigt hatten.
Unsere gescheiterten Experimente (alle)
August 2024: Die Aufteilung
Wir haben versucht, uns in ein Frontend- und ein Backend-Team aufzuteilen. Jedes Team mit eigenem Stand-up, eigenem Fokus.
Hielt genau einen Sprint. Bei Arheev müssen beide Seiten nun mal ständig miteinander reden. Wer hätte das gedacht?
September 2024: Asynchrone Updates
„Machen wir statt Meetings einfach tägliche Slack-Updates!“
In der ersten Woche posteten alle ausführliche Updates. In der zweiten Woche wurden sie kürzer. In Woche drei waren wir bei „hab an Sachen gearbeitet“ angekommen, und gelesen hat sie ohnehin niemand.
Oktober 2024: Rotierende Team-Leads
Jede Woche leitet jemand anderes das Stand-up, mit Schwerpunkt auf seinem Bereich. Klang in der Theorie großartig.
In der Praxis: Manche landeten in jedem Meeting (weil sie überall mitarbeiteten), andere tauchten gar nicht mehr auf. Am Ende hatten wir mehr Silos als vorher.
November 2024: Fast hätten wir aufgegeben
Wir versuchten es wieder mit „kein formaler Prozess, regelt das einfach selbst“. Nach zwei Wochen hatten wir dieselben Probleme wie zuvor.
Sechs Monate Scheitern. Uns gingen die Ideen aus.
Anfang 2025: Die zufällige Lösung
Geplant war das nicht. Jemand schlug vor, für einen besonders hartnäckigen Bug in Arheev Mob Programming auszuprobieren.
Fünf Leute, ein Bildschirm, ein Problem, das Frontend, Backend und Datenbank gleichzeitig betraf. Wir dachten, das bleibt eine einmalige Sache.
Der Bug wurde behoben. Aber noch etwas anderes passierte: Die Leute lernten Teile der Codebasis kennen, die sie nie angefasst hatten. Die Frontend-Entwicklerin verstand, warum die Datenbankabfrage langsam war. Der Backend-Entwickler sah, warum der Ladezustand wichtig war.
Wir fingen an, das wöchentlich zu machen. Nicht für alles, aber für komplexe Features oder harte Bugs.
Was sich wirklich verändert hat
Wissen verbreitete sich schneller. Wenn alle sehen, wie etwas funktioniert, gibt es am Ende nicht die eine Person, die als Einzige den Deployment-Prozess kennt.
Weniger „Das ist nicht mein Problem“-Momente. Schwer zu behaupten, das Frontend gehe einen nichts an, wenn man gerade beim Debuggen des React-Rendering-Problems geholfen hat.
Code-Reviews wurden besser. Wer Code reviewte, den er live hatte entstehen sehen, gab besseres Feedback als jemand, der ohne Vorwissen auf den Diff schaute.
Was immer noch kaputt ist
Seien wir ehrlich: Wir haben nicht alles gelöst.
Mob Programming skaliert nicht auf 14 Leute. Meist sitzen 4 bis 6 in einer Session. Alle anderen arbeiten für sich weiter. Also haben wir weiterhin Koordinationsprobleme.
Manche hassen es. Besonders Introvertierte. Zwei Stunden in einer Gruppen-Coding-Session zu sitzen, kann auslaugen. Wir haben noch nicht herausgefunden, wie es für alle funktioniert.
Silos gibt es immer noch. Selbst mit Generalisten wird irgendwer zur „Person, die sich mit AWS auskennt“ oder zur „Person, die den Zahlungsablauf versteht“. Nur eben … weniger als vorher.
KI-Tools helfen, aber sie sind keine Zauberei. Klar, Sie können sich von Claude beim SQL-Schreiben helfen lassen, wenn Sie eigentlich Frontend-Entwickler sind. Aber Sie müssen trotzdem verstehen, was Sie tun. KI macht Lernen leichter, nicht überflüssig.
Wo wir heute stehen (November 2025)
Stand-ups dauern wieder 15 Minuten. Wir reden tatsächlich über das, was zählt, statt Statusberichte abzuliefern.
Mob-Programming-Sessions finden 2- bis 3-mal pro Woche statt. Nicht alle machen jedes Mal mit. Das ist in Ordnung.
Wir haben immer noch Koordinationsprobleme. Wir haben immer noch Wissenssilos. Aber sie sind kleiner und weniger schmerzhaft als vor sechs Monaten.
Falls Sie gerade dasselbe durchmachen
Wir haben sechs Monate mit verschiedenen Ansätzen verschwendet. Das würden wir unserem früheren Ich sagen:
Teilen Sie das Team nicht auf. Solange Sie nicht wirklich groß genug sind (50+ Leute), schafft eine Aufteilung mehr Probleme, als sie löst.
Zwingen Sie nicht alle, über Nacht zu Generalisten zu werden. Das geht nur schrittweise. Mob Programming oder Pair Programming hilft, aber es dauert Monate, nicht Wochen.
Akzeptieren Sie, dass es zu einer gewissen Spezialisierung kommen wird. Das ist in Ordnung. Sorgen Sie nur dafür, dass nichts Kritisches an einer einzigen Person hängt.
Probieren Sie die 30-%-Regel. Wenn Sie neben Kundenprojekten ein eigenes Produkt bauen, reservieren Sie Kapazität dafür. Sonst wird es nie gebaut.
Ihre Erfahrung wird anders aussehen. Wir sind vierzehn Remote-Leute, die eine HR-Plattform bauen. Ihr Team, Ihr Produkt, Ihre Rahmenbedingungen sind andere.
Aber wenn sich Ihre Stand-ups wie Zeitverschwendung anfühlen und Sie ständig erst von Arbeit erfahren, wenn sie schon erledigt ist, haben Sie vielleicht dieselben Probleme wie wir.
Anders als Ihre Lieblings-Büro-Sitcom hat diese Geschichte kein sauberes Ende. Wir probieren weiter, während wir wachsen.
