Kleine IT-Teams gewinnen: Warum KI große Entwicklerteams nicht automatisch besser macht

Mehr Entwickler bedeuten nicht automatisch mehr Geschwindigkeit

Viele Unternehmen glauben noch immer, digitale Projekte würden schneller, wenn mehr Entwickler darauf gesetzt werden. Mehr Menschen. Mehr Tickets. Mehr parallele Arbeit. Mehr Output.

Auf den ersten Blick klingt das logisch. Wenn ein Entwickler in einer Woche eine bestimmte Menge Code schreiben kann, müssten zehn Entwickler doch entsprechend mehr schaffen. Und wenn ein Projekt dringend ist, müsste ein größeres Team doch automatisch schneller liefern.

In der Praxis stimmt das häufig nicht. Digitale Projekte werden nicht automatisch schneller, wenn mehr Menschen daran arbeiten. Sie werden oft zuerst komplexer.

Mehr Abstimmung, mehr Übergaben, mehr Meetings, mehr unterschiedliche Interpretationen, mehr technische Abhängigkeiten, mehr Code Reviews, mehr Architekturabstimmung und mehr Koordinationsaufwand. Genau diese Dynamik wird in Zeiten von KI noch wichtiger.

Denn KI verändert Softwareentwicklung fundamental. Nicht, weil plötzlich jeder ohne Fachwissen perfekte Software bauen kann. Das ist ein gefährlicher Mythos. Sondern weil gute Entwickler, gute Product Owner und gut geführte Teams heute deutlich mehr Hebel bekommen.

Der Engpass verschiebt sich. Code zu schreiben wird leichter. Den richtigen Code zu schreiben bleibt anspruchsvoll. Code zu verstehen, zu prüfen, zu betreiben und langfristig wartbar zu halten, wird sogar noch wichtiger.

Deshalb ist die entscheidende Frage für Unternehmen nicht mehr: Wie viele Entwickler brauchen wir? Sondern: Wie klein kann das Team sein, das dieses Problem wirklich end-to-end lösen kann?

Meine klare Empfehlung aus vielen digitalen Projekten: Operative IT-Projektteams sollten selten größer als acht Personen sein. Nicht, weil acht eine magische Zahl ist. Sondern weil ab dieser Größe die Vorteile zusätzlicher Köpfe oft schneller abnehmen als die Koordinationskosten steigen.

KI macht Coding leichter, aber Projektführung wichtiger

KI-Tools haben die Art verändert, wie Software entsteht. Boilerplate-Code, Tests, Dokumentation, Refactorings, einfache Komponenten, API-Entwürfe, SQL-Abfragen, Skriptlogik oder technische Recherche können heute deutlich schneller vorbereitet werden als noch vor wenigen Jahren.

Es gibt belastbare Hinweise, dass KI-Assistenz bei bestimmten Entwicklungsaufgaben die Geschwindigkeit stark erhöhen kann. Eine bekannte Untersuchung zu GitHub Copilot zeigte beispielsweise, dass Entwickler eine klar abgegrenzte Aufgabe mit KI-Unterstützung deutlich schneller abschließen konnten.

Gleichzeitig zeigen neuere Untersuchungen, dass KI bei erfahrenen Entwicklern in komplexen, gewachsenen Codebasen nicht automatisch schneller macht und teilweise sogar zusätzlichen Review- und Korrekturaufwand erzeugt.

Genau darin liegt der Punkt. KI ist kein Ersatz für Führung, Architektur und Produktverständnis.

KI verstärkt gute Strukturen. KI beschleunigt klare Aufgaben. KI hilft guten Entwicklern, mehr Varianten schneller zu prüfen. KI reduziert repetitive Arbeit. KI macht kleine Teams leistungsfähiger.

Aber KI löst keine unklaren Ziele. Sie löst keine schwache Priorisierung, keine widersprüchlichen Anforderungen, keine fehlende Architektur, keine schlechte Datenqualität, keine unklare Verantwortung und keine fehlende Produktführung.

Im Gegenteil: Wenn ein Projekt schlecht geführt ist, kann KI das Problem sogar beschleunigen. Dann entsteht schneller mehr Code, aber nicht zwingend mehr Wert.

Genau deshalb sind kleine, gut geführte Teams heute stärker als große, schlecht koordinierte Teams.

Softwareentwicklung ist keine lineare Kapazitätsrechnung

In vielen Unternehmen wird Softwareentwicklung noch zu linear gedacht. Ein Entwickler schafft X. Zwei Entwickler schaffen 2X. Zehn Entwickler schaffen 10X.

So funktioniert Wissensarbeit aber nicht. Softwareentwicklung ist keine Fließbandarbeit. Sie ist ein Zusammenspiel aus Verstehen, Entscheiden, Entwerfen, Umsetzen, Prüfen, Integrieren und Betreiben.

Je mehr Menschen daran beteiligt sind, desto mehr Kommunikationslinien entstehen. Bei acht Personen gibt es theoretisch 28 direkte Kommunikationsbeziehungen. Bei 15 Personen sind es bereits 105. Bei 30 Personen sind es 435.

Natürlich spricht nicht jeder ständig mit jedem. Aber die Grundlogik bleibt: Mit jedem zusätzlichen Teammitglied steigt nicht nur die verfügbare Arbeitskraft. Es steigt auch der Abstimmungsbedarf.

Und dieser Abstimmungsbedarf ist in digitalen Projekten teuer. Jedes Missverständnis kann zu falscher Umsetzung führen. Jede unklare Schnittstelle erzeugt Rückfragen. Jede parallele Entscheidung kann Architekturkonflikte verursachen.

Ab einer gewissen Größe arbeitet ein Team nicht mehr hauptsächlich am Produkt. Es arbeitet am Management seiner eigenen Komplexität.

Große Dev-Teams erzeugen oft ihre eigene Beschäftigung

Ein unangenehmer Punkt, über den selten offen gesprochen wird: Große Entwicklungsteams erzeugen häufig Arbeit, die es ohne ihre Größe gar nicht gäbe.

Es braucht mehr Koordination, mehr Rollen, mehr Statusmeetings, mehr Abstimmungsrunden, mehr Dokumentation über Zuständigkeiten, mehr technische Governance, mehr Ticket-Management und mehr Prozess rund um den Prozess.

Das kann in großen Organisationen notwendig sein. Aber es ist kein Selbstzweck. In vielen Projekten entsteht irgendwann eine eigene Projektbürokratie.

Dann gibt es nicht mehr nur Entwickler, Product Owner und technische Verantwortung. Es gibt Teilprojektleiter, Proxy Product Owner, Scrum Master für mehrere Streams, Architekturboards, Release Boards, Change Boards, Steering Committees und Synchronisationsmeetings zwischen Teams.

Irgendwann wird mehr Energie darauf verwendet, Arbeit zu koordinieren, als Arbeit wirklich zu erledigen. Das ist besonders gefährlich in Projekten, die eigentlich schnell und pragmatisch sein müssten.

Kleine Teams haben einen natürlichen Vorteil: Ownership

Der größte Vorteil kleiner IT-Teams ist nicht Geschwindigkeit. Es ist Verantwortung.

In einem kleinen Team ist sehr schnell sichtbar, wer wofür steht. Wer versteht den Kunden? Wer kennt die Architektur? Wer entscheidet über Prioritäten? Wer sieht technische Risiken? Wer übernimmt Qualität? Wer hält das Zielbild zusammen?

In großen Teams verschwimmt Verantwortung häufig. Das macht Backend. Das liegt beim Frontend-Team. Das muss die Architektur entscheiden. Das ist eine Fachbereichsfrage. Das muss der Dienstleister klären.

Solche Sätze sind Warnsignale. Sie zeigen, dass Verantwortung nicht mehr beim Team liegt, sondern zwischen Rollen zirkuliert.

Kleine Teams können sich weniger verstecken. Das ist manchmal anstrengend. Aber es ist extrem wirksam.

Denn gute digitale Produkte entstehen nicht nur durch Spezialisierung. Sie entstehen durch Menschen, die das Problem verstehen und Verantwortung für das Ergebnis übernehmen.

Telegram als Beispiel für extreme Skaleneffizienz

Ein interessantes Beispiel für die Kraft kleiner Teams ist Telegram. Telegram ist sicher keine Blaupause für jedes Unternehmen und schon gar nicht für jedes Governance-, Moderations- oder Compliance-Modell. Aber als Beispiel für technische Skaleneffizienz ist es bemerkenswert.

Im März 2024 wurde Telegram mit rund 900 Millionen Nutzern und nur etwa 50 Mitarbeitenden beschrieben. Das entspricht rein rechnerisch etwa 18 Millionen Nutzern pro Mitarbeiter.

Ende 2024 meldete Pavel Durov dann, Telegram sei profitabel geworden. Laut TechCrunch sagte Durov, Telegram habe 2024 mehr als eine Milliarde US-Dollar Umsatz erzielt, über 12 Millionen zahlende Premium-Nutzer erreicht und mehr als 950 Millionen monatlich aktive Nutzer gehabt.

Man muss Telegram nicht in jeder Hinsicht als Vorbild sehen, um daraus eine wichtige Beobachtung abzuleiten: Skalierung entsteht nicht automatisch durch viele Mitarbeiter. Skalierung entsteht durch Produktlogik, technische Architektur, klare Entscheidungen und extreme Fokussierung.

Natürlich hat Telegram andere Rahmenbedingungen als ein typisches deutsches Mittelstandsunternehmen. Aber genau deshalb ist das Beispiel spannend.

Denn viele Unternehmen mit deutlich kleineren Nutzerzahlen, deutlich weniger Traffic und deutlich einfacheren digitalen Produkten arbeiten mit Entwicklungsteams, die viel größer sind als nötig. Nicht, weil das Produkt es zwingend erfordert. Sondern weil Komplexität organisatorisch gewachsen ist.

Kleine Teams sind kein Sparmodell

Kleine Teams dürfen nicht als reines Kostensenkungsmodell missverstanden werden. Es geht nicht darum, einfach weniger Menschen einzusetzen und zu hoffen, dass der Rest schon irgendwie mit KI erledigt wird.

Das wäre naiv. Ein kleines Team funktioniert nur, wenn es stark besetzt und gut geführt ist.

Es braucht klare Produktverantwortung, technisches Urteilsvermögen, gute Architekturentscheidungen, saubere Priorisierung, hohe Eigenverantwortung, starke Kommunikation, Qualitätsbewusstsein, Automatisierung, Teststrategie, Monitoring und ein gemeinsames Verständnis davon, was wirklich erreicht werden soll.

Ein kleines schwaches Team ist nicht besser als ein großes schwaches Team. Aber ein kleines starkes Team ist einem großen durchschnittlichen Team häufig überlegen.

Weil es weniger Reibung hat. Weil es schneller lernt. Weil es näher am Problem ist. Weil es Entscheidungen direkter trifft. Weil es weniger Übergaben braucht. Weil es Verantwortung nicht verteilt, sondern bündelt.

KI verstärkt genau diesen Effekt.

Warum KI kleine Teams besonders stark macht

KI verändert die Ökonomie kleiner Teams. Früher brauchte ein kleines Team für viele Dinge zusätzliche Spezialisten oder externe Unterstützung.

Heute kann ein starkes Team mit KI deutlich mehr selbst vorbereiten: technische Konzepte, erste Prototypen, Testfälle, Dokumentation, API-Spezifikationen, Datenanalysen, SQL-Entwürfe, Fehleranalysen, Code-Reviews, Refactoring-Vorschläge, UX-Varianten, Migrationsskripte und Monitoring-Checks.

Das heißt nicht, dass Experten überflüssig werden. Aber es heißt, dass ein gutes Kernteam heute viel länger handlungsfähig bleibt, bevor es zusätzliche Personen braucht.

Früher war Headcount oft der einfachste Hebel. Heute ist Klarheit der bessere Hebel.

Ein kleines Team mit klarer Architektur, sauberer Produktführung und gutem KI-Einsatz kann enorm viel bewegen. Ein großes Team ohne Klarheit wird durch KI nicht automatisch besser. Es produziert nur schneller mehr Abstimmungsbedarf.

Der neue Engpass ist nicht Code, sondern Kontext

KI kann Code erzeugen. Aber KI versteht nicht automatisch den echten Kontext eines Unternehmens.

Sie kennt nicht die politischen Realitäten, nicht die unausgesprochenen Erwartungen des Kunden, nicht die Historie der Systemlandschaft, nicht die Gründe, warum ein Prozess so gewachsen ist, nicht die tatsächlichen Einschränkungen im Betrieb, nicht die internen Zielkonflikte und nicht die wirtschaftliche Priorität.

Genau deshalb bleibt Kontext der entscheidende Engpass. Und Kontext lässt sich in kleinen Teams deutlich besser halten.

In einem kleinen Team wissen die Beteiligten eher, warum etwas gebaut wird. Sie verstehen besser, welche Entscheidung welche Konsequenz hat. Sie können schneller erkennen, ob ein KI-generierter Vorschlag fachlich passt oder nur technisch plausibel klingt.

Große Teams verlieren Kontext schneller. Anforderungen werden fragmentiert, Tickets kleiner geschnitten, Entwickler sehen nur noch Ausschnitte und Entscheidungen werden weiter entfernt vom eigentlichen Problem getroffen.

Das ist gefährlich. Denn KI kann in solchen Strukturen sehr produktiv wirken, obwohl das Team am falschen Problem arbeitet.

Acht Personen als sinnvolle Obergrenze für das operative Kernteam

Meine praktische Empfehlung: Ein operatives digitales Produkt- oder Projektteam sollte in der Regel nicht größer als acht Personen sein.

Das bedeutet nicht, dass im gesamten Unternehmen nur acht Menschen beteiligt sein dürfen. Natürlich braucht es Stakeholder, Fachbereiche, IT, Security, Datenschutz, Betrieb, externe Spezialisten oder Management.

Aber der operative Kern, der das Produkt wirklich baut, priorisiert und verantwortet, sollte klein bleiben.

Eine sinnvolle Struktur kann zum Beispiel so aussehen: ein Product Owner oder Digital Lead für Ziel, Priorität, fachliche Klarheit und Stakeholder-Kommunikation; ein Tech Lead oder Solution Architect für technische Leitplanken, Architektur, Qualität und langfristige Wartbarkeit; drei bis fünf Entwicklerinnen und Entwickler mit passenden Schwerpunkten; und eine QA-, Automation- oder DevOps-nahe Rolle für Qualität, Deployment, Tests und Betrieb.

Damit liegt man bei sechs bis acht Personen im operativen Kern. Das ist groß genug, um relevante Arbeit zu leisten. Und klein genug, um schnell zu bleiben.

Auch etablierte agile Empfehlungen gehen in diese Richtung: Der Scrum Guide beschreibt Scrum Teams als kleine, cross-funktionale Einheiten und nennt typischerweise zehn oder weniger Personen; kleinere Teams kommunizieren demnach besser und sind produktiver.

Auch Amazons bekanntes Prinzip der Two-Pizza-Teams zielt auf kleine, autonome Teams mit klarer Ownership. AWS beschreibt diese Teams idealerweise als Einheiten unter zehn Personen, die weniger Kommunikationslinien und weniger Entscheidungsbürokratie erzeugen.

Acht ist daher keine starre Dogma-Zahl. Aber acht ist eine sehr gute operative Grenze. Wenn ein Team größer wird, sollte man nicht automatisch weiter aufstocken. Man sollte prüfen, ob das Problem besser in mehrere klar geschnittene Teams mit eigener Verantwortung zerlegt wird.

Große Vorhaben brauchen nicht große Teams, sondern klare Schnitte

Natürlich gibt es digitale Vorhaben, die größer sind als ein Acht-Personen-Team: Plattformen, ERP-Modernisierungen, CRM-Rollouts, E-Commerce-Ökosysteme, Data- und KI-Initiativen, internationale Produktlandschaften oder Legacy-Migrationen.

Aber auch solche Vorhaben profitieren nicht davon, wenn man alle Menschen in ein riesiges Team steckt.

Der bessere Weg ist meistens: kleine Teams, klare Domänen, klare Schnittstellen, gemeinsames Zielbild, einheitliche technische Standards, saubere Entscheidungslogik und starke übergreifende Führung.

Also nicht ein Team mit 30 Personen. Sondern zum Beispiel drei Teams mit jeweils sechs bis acht Personen.

Ein Team verantwortet das Kundenportal. Ein Team verantwortet CRM und Vertriebsprozesse. Ein Team verantwortet Datenintegration und Reporting. Alle arbeiten auf dasselbe Zielbild ein. Aber sie haben jeweils klare Ownership.

Das ist ein großer Unterschied. Denn Skalierung bedeutet nicht, alle Menschen in dieselbe Abstimmung zu zwingen. Skalierung bedeutet, Verantwortung so zu schneiden, dass Teams autonom liefern können, ohne das Gesamtbild zu verlieren.

Was Unternehmen falsch machen, wenn Projekte langsam werden

Wenn digitale Projekte langsam werden, reagieren Unternehmen oft reflexartig mit mehr Kapazität. Wir brauchen mehr Entwickler. Wir brauchen noch eine Agentur. Wir brauchen ein größeres Team. Wir müssen parallelisieren. Wir müssen mehr Tickets schaffen.

Manchmal stimmt das. Aber oft ist es die falsche Antwort.

Denn wenn ein Projekt wegen unklarer Anforderungen langsam ist, helfen mehr Entwickler nicht. Wenn die Architektur unklar ist, helfen mehr Entwickler nicht. Wenn Entscheidungen nicht getroffen werden, helfen mehr Entwickler nicht.

Wenn der Product Owner überlastet ist, wenn Fachbereiche sich widersprechen, wenn Qualitätssicherung fehlt oder wenn niemand das Gesamtbild führt, helfen mehr Entwickler ebenfalls nicht.

Dann vergrößert zusätzlicher Headcount nur das bestehende Problem. Aus einem unklaren kleinen Projekt wird ein unklareres großes Projekt.

KI macht schwache Führung sichtbarer

Vor KI konnte man in Softwareprojekten lange den Eindruck erzeugen, dass vor allem Umsetzungskapazität fehlt. Wir kommen nicht hinterher. Die Entwicklung ist überlastet. Das dauert, weil wir zu wenig Leute haben.

Heute wird diese Erklärung schwieriger. Denn wenn Coding, Prototyping und technische Recherche schneller werden, sieht man deutlicher, wo die eigentlichen Bremsen liegen.

Unklare Prioritäten, schwache Produktführung, langsame Entscheidungen, zu viele Stakeholder, zu viele Abhängigkeiten, zu große Teams, zu wenig Ownership und zu wenig technische Leitplanken.

KI nimmt Unternehmen nicht die Führungsarbeit ab. Sie macht nur schneller sichtbar, wo Führung fehlt.

Das ist unbequem, aber wertvoll. Denn es zwingt Unternehmen, digitale Projekte nicht länger als reine Umsetzungsmaschine zu betrachten.

Softwareentwicklung ist keine Ticketfabrik. Softwareentwicklung ist Produktarbeit. Und Produktarbeit braucht kleine, starke, verantwortliche Teams.

Was ein kleines Hochleistungsteam auszeichnet

Ein kleines IT-Team ist nicht automatisch gut. Kleinheit ist nur dann ein Vorteil, wenn das Team bestimmte Eigenschaften erfüllt.

Erstens: Ein klares Ziel. Das Team muss wissen, welches Problem es löst und woran Erfolg gemessen wird. Ohne klares Ziel wird auch ein kleines Team nur schnell im Kreis laufen.

Zweitens: End-to-end-Verantwortung. Das Team sollte nicht nur entwickeln, sondern auch verstehen, testen, ausliefern, messen und verbessern. Wer nur Teilstücke baut, entwickelt selten echte Produktverantwortung.

Drittens: Technische Leitplanken. Kleine Teams brauchen klare Architekturprinzipien, Code-Standards, Review-Regeln, Testautomatisierung und Deployment-Prozesse. Sonst wird Geschwindigkeit später mit Wartungsschulden bezahlt.

Viertens: Direkter Zugang zu Entscheidungen. Ein kleines Team muss schnell klären können, was wichtig ist. Wenn jede Entscheidung durch fünf Gremien muss, verliert das Team seinen Vorteil.

Fünftens: Starker Product Owner oder Digital Lead. Jemand muss Ziel, Priorität, Fachlichkeit, Stakeholder und Umsetzung zusammenhalten. Ohne diese Rolle wird auch ein gutes Dev-Team irgendwann zum reinen Ticketlieferanten.

Sechstens: Bewusster KI-Einsatz. KI sollte nicht beliebig genutzt werden, sondern entlang klarer Aufgaben: Code-Assistenz, Tests, Dokumentation, Analyse, Prototyping, Qualitätssicherung, Wissensarbeit. Entscheidend bleibt, dass Menschen prüfen, bewerten und Verantwortung übernehmen.

Der eigentliche Vorteil kleiner Teams ist Lernfähigkeit

In digitalen Projekten gewinnt nicht das Team, das am Anfang alles weiß. Es gewinnt das Team, das am schnellsten lernt.

Kleine Teams lernen schneller, weil Feedback direkter wirkt. Ein Fehler wird schneller sichtbar. Eine Kundenreaktion landet schneller beim Team. Eine technische Einschränkung wird schneller diskutiert. Eine Prioritätsänderung kann schneller verarbeitet werden. Ein Architekturproblem wird schneller gemeinsam verstanden.

In großen Teams gehen diese Lerneffekte oft verloren. Feedback wird gefiltert. Fehler werden verteilt. Verantwortung wird abstrahiert. Lernen wird zu einem Reporting-Punkt.

Gerade in Zeiten von KI ist Lernfähigkeit entscheidend. Denn KI erhöht die Geschwindigkeit, mit der Varianten entstehen können. Aber nur gute Teams können bewerten, welche Variante wirklich sinnvoll ist.

Was Führungskräfte messen sollten

Wenn Unternehmen kleinere IT-Teams ernst nehmen, müssen sie anders messen.

Nicht nur: Wie viele Entwickler arbeiten am Projekt? Wie viele Tickets wurden geschlossen? Wie viele Story Points wurden geliefert? Wie viele Features wurden gebaut?

Sondern: Wie schnell kommen wir von Idee zu nutzbarem Ergebnis? Wie viele Übergaben braucht eine Entscheidung? Wie oft deployen wir sicher? Wie hoch ist der Review- und Nacharbeitsaufwand? Wie gut versteht das Team den Kundenkontext?

Wie klar sind Ownership und Architektur? Wie viele offene Entscheidungen blockieren Umsetzung? Wie viel Wert entsteht wirklich beim Nutzer oder im Prozess?

Diese Fragen sind anspruchsvoller. Aber sie führen näher an die Wahrheit. Denn ein großes Team mit hoher Ticketzahl kann trotzdem wenig Wirkung erzeugen. Ein kleines Team mit klarem Fokus kann dagegen in kurzer Zeit echte Ergebnisse liefern.

Wann größere Teams trotzdem sinnvoll sind

Dieser Artikel ist kein Plädoyer dafür, jedes Entwicklungsteam künstlich klein zu halten. Es gibt Situationen, in denen mehr Menschen notwendig sind.

Zum Beispiel bei großen Migrationsprogrammen, parallelen Produktlinien, komplexen Plattformen mit mehreren Domänen, internationalem Rollout, regulatorisch anspruchsvollen Systemen oder hoher Betriebs- und Sicherheitsverantwortung.

Aber auch dann sollte die Frage nicht lauten: Wie bauen wir ein möglichst großes Team? Sondern: Wie schneiden wir das Vorhaben so, dass kleine Teams klare Verantwortung übernehmen können?

Das ist der Kern. Nicht jedes Unternehmen braucht kleine Projekte. Aber fast jedes Unternehmen braucht kleinere, klarer geführte Teams.

Fazit: In Zeiten von KI gewinnt nicht Headcount, sondern Klarheit

KI verändert Softwareentwicklung. Aber nicht so, wie viele glauben.

KI bedeutet nicht, dass Entwickler überflüssig werden. KI bedeutet nicht, dass jeder ohne Fachwissen komplexe Systeme bauen sollte. KI bedeutet nicht, dass Qualität, Architektur und Produktführung weniger wichtig werden.

Das Gegenteil ist der Fall. Je schneller Code entstehen kann, desto wichtiger wird die Frage, welcher Code überhaupt entstehen sollte. Je leichter Umsetzung wirkt, desto wichtiger wird Führung. Je mehr KI generieren kann, desto wichtiger werden Kontext, Prüfung, Verantwortung und Entscheidung.

Deshalb werden kleine, gut geführte IT-Teams in den kommenden Jahren einen enormen Vorteil haben. Nicht, weil sie billiger sind. Sondern weil sie weniger Reibung haben, schneller lernen, Verantwortung klarer halten und KI gezielter einsetzen können.

Große Entwicklerteams wirken oft mächtig. Aber Macht ist nicht dasselbe wie Wirkung. In vielen digitalen Projekten entsteht Wirkung nicht durch mehr Menschen, sondern durch weniger Übergaben, bessere Entscheidungen und klare Ownership.

Die Zukunft der Softwareentwicklung gehört nicht automatisch den größten Teams. Sie gehört den Teams, die klein genug sind, um schnell zu bleiben - und stark genug, um Verantwortung zu übernehmen.