10 Voraussetzungen für Skalierbarkeit, die Sie kennen sollten, bevor Sie wachsen
Mach dich bereit, denn ich werde dir die harte Wahrheit über Skalierbarkeit erzählen.
Beginnen wir damit, beim Skalieren im Geschäftsleben ehrlich zu sein:
Die meisten Skalierungsversuche scheitern.
Was ist also das Geheimrezept? Wie skaliert man ein Team erfolgreich, und warum ist das so schwierig?
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Wenn du lange genug im Bereich der Softwareentwicklung tätig bist, hast du dieses Albtraumszenario wahrscheinlich schon erlebt:
- Dem Kunden werden jede Menge Funktionen in unrealistisch kurzer Zeit versprochen (und niemand hat den Mut, das zu hinterfragen).
- Später, wenn die Deadline bedrohlich nah ist, entscheidet jemand mit Befugnissen, noch mehr Teams zum Projekt hinzuzuziehen, um den Termin einzuhalten.
- Dann beginnt alles auseinanderzufallen.
Klingt das bekannt?
In diesem Artikel erkläre ich dir, was du tun musst, um genau diese Albtraumsituation in Zukunft zu vermeiden (oder, falls du bisher Glück hattest, damit sie erst gar nicht eintritt).
Meine Erkenntnisse beruhen auf der Skalierung von Softwareentwicklungsteams, aber die grundlegende Theorie kannst du auf jede Branche anwenden, wenn du ein Unternehmen oder ein Team vergrößern möchtest. Das ist auch hilfreich, wenn du eines der bekannten Skalierungs-Frameworks wie Large Scale Scrum (LeSS), Scrum@Scale oder SAFe einsetzt.
Das liegt daran, dass ich mich auf mehrere wichtige Aspekte der Skalierbarkeit konzentriere, die in diesen Methoden nie erwähnt werden – die grundlegende Wahrheit über die Natur des Skalierens, die oft vergessen oder ignoriert wird.
Das grundlegende Gesetz der Skalierung
Das grundlegende Gesetz der Skalierung ist eine empirische Beobachtung dessen, was in Projekten passiert, wenn sie wachsen:
Skalierung verstärkt das Schlechte und macht das Gute schwieriger.
Die Formulierung stammt von mir, aber ich bin weder der Einzige noch der Erste, der diese Erkenntnis hatte.
Schauen wir uns anhand einiger Skalierbarkeitsbeispiele an, was dieses Gesetz in der Praxis bedeutet.
1. Beispiel: Kommunikation und Skalierbarkeit
Das Erste und offensichtlichste ist die Kommunikation. Es ist allgemein bekannt, dass mit steigender Anzahl von Personen in einem Projekt auch die Zahl der Kommunikationskanäle zunimmt. Wenn die Kommunikationskanäle von Anfang an nicht gut sind, wird das Problem durch Skalierung nur noch größer.
Andererseits bringt auch eine gute Kommunikation zu Beginn bei der Skalierung Herausforderungen mit sich: nicht nur durch die höhere Personenzahl, sondern auch durch deren Verteilung. Oft entstehen neue Teams an unterschiedlichen Standorten, was zu Veränderungen bei den Kommunikationskanälen führt – etwa von persönlichen Meetings zu Videokonferenzen oder indem das Whiteboard durch ein elektronisches Tool ersetzt wird.
2. Beispiel: Continuous Integration/Continuous Delivery und Skalierbarkeit
Das grundlegende Gesetz der Skalierung zeigt sich auch in Continuous Integration (CI) und Continuous Delivery (CD) Pipelines. Gibt es nur ein Team, ist alles recht einfach.
Kommen zwei Teams ins Spiel, werden CI- und CD-Systeme meist deutlich komplexer – in der Regel gibt es bei n Teams etwa n+1 CI-Pipelines (je ein Pipeline pro Team, plus eine für die Integration). Das hat offensichtliche Auswirkungen auf die Bereitstellung von Umgebungen sowie auf die Abstimmung zwischen den Teams.
3. Beispiel: Feedback-Loops und Skalierbarkeit
Ein letztes Beispiel: Feedback-Loops. Größere Projekte erzeugen längere Feedbackzyklen. Dadurch wird es viel schwieriger, das System iterativ zu verbessern, was das Risiko erhöht, am Ende das falsche Produkt zu bauen.
Dies sind nur drei Beispiele für Herausforderungen, die durch das Skalieren entstehen. Dir fallen bestimmt noch viele weitere ein.
Nehmen wir an, du bist bereit, die damit verbundenen Kompromisse einzugehen. Dann muss dein Projekt als nächstes einige wichtige Voraussetzungen erfüllen, um wirklich skalierbar zu sein.
10 Voraussetzungen für Skalierung
Ob dein Unternehmen, Projekt oder Team skalierbar ist, hängt von mehreren Voraussetzungen ab, die du unten findest. Wenn sie erfüllt sind, ist die Skalierbarkeit hoch. Wenn eine davon nicht passt, ist das Risiko zu scheitern enorm hoch.
1. Das Vorhandensein klarer, gemeinsamer Ziele
Das sollte eigentlich selbstverständlich sein, aber in meiner Erfahrung fehlt es oft gerade daran. Ohne klare, gemeinsame Ziele arbeiten Teams in verschiedene Richtungen – und ein nützliches Ergebnis wird deutlich schwerer erreichbar.
2. Der Einsatz geeigneter Metriken
Je größer das Projekt, desto wichtiger ist es, die Auswirkungen der getroffenen Entscheidungen messen zu können. Zum Beispiel: Hat die Hinzunahme eines neuen Teams die Fähigkeit des Projekts zur Auslieferung verbessert? Fordern wir die Teams so sehr, dass die Qualität leidet? Arbeiten die Teams gut zusammen oder behindern sie sich gegenseitig?
3. Eine geeignete Architektur
Wenn die „Form“ des Systems nicht zur Teamstruktur passt, wird die Hinzufügung weiterer Teams die Situation nur verschlechtern. Dies ist eine direkte Auswirkung des Conway’schen Gesetzes, einer wohlbekannten empirischen Beobachtung, die sich in der Praxis bewährt hat.
4. Verfügbarkeit von Führungs- und Fachkompetenzen
Mängel an Fähigkeiten wirken sich mit zunehmender Projektgröße noch negativer aus.
5. Gute Kommunikationskanäle
Je mehr Menschen beteiligt sind, desto mehr Kommunikation findet statt. Erfolgreiches Skalieren erfordert eine effektive, schlanke Kommunikation.
6. Gute Priorisierung und Planung
Fehlende oder unzureichende Priorisierung und Planung ist aus meiner Erfahrung ein sehr häufiger Faktor für das Scheitern von Projekten. Besonders dann, wenn mehr als ein Team beteiligt ist, müssen Priorisierungs- und Planungsaktivitäten darauf achten, die Auswirkungen von Verzögerungen und fehlender Synchronisierung abzufedern.
7. Gute Erhebung und Verwaltung von Anforderungen
Dies geht Hand in Hand mit Priorisierung und Planung. Außerdem verstärken sich die Auswirkungen falscher, missverstandener oder unnötiger Anforderungen mit der Anzahl der Teams.
8. Hochwertige Arbeit
Je größer das Projekt, desto gravierender werden die negativen Auswirkungen von schlechter Qualität. In einigen (und durchaus häufigen) pathologischen Szenarien werden manche Fehler zu Features, da der Rückkopplungszyklus für Korrekturen so lang ist, dass andere Teams längst ihre Workarounds entwickelt haben, um diese Fehler zu umgehen.
9. Verfügbarkeit von Ressourcen
Mehr Teams benötigen mehr Schreibtische, Computer, Werkzeuge und Umgebungen.
10. Konsequente Automatisierung
Jede manuelle Tätigkeit ist ein Engpass, dessen Auswirkungen mit steigender Anzahl von Menschen und Teams immer stärker werden. Ein, meiner Meinung nach, sehr typisches Beispiel: manuelle Testaktivitäten, um sicherzustellen, dass vor einem Produktiv-Release keine Regressionen eingeführt wurden. Nach meiner Erfahrung ist das einer der größten Engpässe in jedem Projekt – besonders jedoch in Projekten mit mehr als einem Team.
Vorsicht vor verfrühter Skalierung
Skalierbarkeit steht bei Startups und Seriengründern ganz oben auf der Agenda – und sie können uns ein oder zwei Lektionen über zu frühes Skalieren erteilen.
Wenn du mit dem Skalieren beginnst, bevor wirklich alle Voraussetzungen für ein erfolgreiches Skalieren eines Unternehmens, Teams oder einer Organisation erfüllt sind, tritt das auf, was in der Startup-Szene als „verfrühte Skalierung“ bezeichnet wird.
Eine einfache Definition von verfrühter Skalierung vom Serienunternehmer Jim Pitkow:
Verfrühte Skalierung: Wachsen in Erwartung von Nachfrage anstelle von wachstumsgetriebenem Wachstum durch tatsächlich bestehende Nachfrage.
Tatsächlich braucht sorgfältiges Skalieren Zeit – und echte Skalierbarkeit entsteht durch einen reellen Bedarf an Wachstum und nicht durch eine künstlich erzeugte Vorstellung, allein durch Größe und Schnelligkeit Fortschritt zu erzielen.
Die Startup-Szene bietet einige Lehren, die wir für unsere Teams und Projekte mitnehmen können, wenn wir darüber nachdenken, ob es Zeit zum Skalieren ist oder nicht. Hier sind einige Statistiken aus dem Startup Genome Report Extra über verfrühte Skalierung:
- Startups, die richtig skalieren, brauchen 76 % länger, um die Teamgröße zu erreichen, als Startups, die zu früh skalieren.
- 74 % der schnell wachsenden Internet-Startups scheitern aufgrund von verfrühter Skalierung.
- Startups, die richtig skalieren, wachsen etwa 20-mal schneller als Startups, die zu früh skalieren.
Wenn du an weiteren Statistiken zum Unternehmertum interessiert bist, schau dir unsere Studie zu den unternehmerischsten Bundesstaaten Amerikas an.
Bist du wirklich bereit zu skalieren?
Wenn dein Projekt gut geführt ist und die oben genannten Voraussetzungen erfüllt, sollte deine nächste Frage lauten:
„Wie viele Teams können produktiv mitwirken?“
Diese Frage werden wir im nächsten Abschnitt beantworten.
Wo liegt die Grenze der Skalierbarkeit? Brooks’ und Amdahls Gesetze
Es ist allgemein bekannt, dass das Hinzufügen weiterer Personen zu einem Softwareprojekt nicht zwangsläufig die Produktivität erhöht.
Tatsächlich führt das Hinzufügen von mehr Menschen in den meisten Fällen zu einem starken Einbruch der Produktivität.
Fred Brooks machte diese Beobachtung in seinem Buch The Mythical Man Month, was als Brooks’ Gesetz bekannt wurde:
„Das Hinzufügen von Arbeitskräften zu einem verspäteten Softwareprojekt verzögert es weiter […] Die Anzahl der Monate eines Projekts hängt von seinen sequentiellen Einschränkungen ab. Die maximale Anzahl an Mitarbeitenden hängt von der Zahl unabhängiger Teilaufgaben ab. Aus diesen beiden Größen können Zeitpläne mit weniger Leuten und mehr Monaten abgeleitet werden […]. Es ist jedoch nicht möglich, funktionierende Zeitpläne mit mehr Leuten und weniger Monaten zu erstellen.“
Der zweite Teil des obigen Zitats ist meiner Meinung nach der interessanteste. Tatsächlich ist es im Prinzip die sprachliche Version von Amdahls Gesetz—einer Formel, die das maximale theoretische Beschleunigungspotenzial eines parallelen Systems angibt:
Amdahls Gesetz
Beschleunigung = 1 / (s + p / n )
Wobei:
s = Anteil der sequentiellen Aufgaben
p = Anteil der parallelisierbaren Aufgaben
s + p = 1
n = Anzahl der Prozessoren (in unserem Fall der Teams)
Tatsächlich ist ein Projekt mit mehreren Teams eine Art paralleles System, wobei jedes Team eine Recheneinheit darstellt. In der Praxis besagt Amdahls Gesetz, dass die maximale Menge an gleichzeitiger Arbeit durch die Menge an sequentieller Arbeit begrenzt wird, die erledigt werden muss.
Mit einfachen Worten bedeutet dies, dass Dinge, die in einer bestimmten Reihenfolge erledigt werden müssen, Einschränkungen dafür darstellen, wie viel die Teams zeitgleich bearbeiten können.
Was ist sequentielle Arbeit im Kontext der Softwareentwicklung?
Sie fragen sich vielleicht, welche Art von Arbeit sequentiell ist und somit Softwareteams beeinflusst.
Hier sind einige Beispiele (ich bin sicher, Ihnen fallen noch viele weitere ein):
- Jegliche Arbeiten an Integrations- und Deployment-Pipelines
- Zusammenführen von Softwareänderungen in gemeinsam von verschiedenen Teams genutztem Code
- Jegliche Art von Synchronisierung – zum Beispiel, wenn ein Team auf die Ergebnisse eines anderen Teams warten muss, bevor es weiterarbeiten kann
- Warten auf die Bereitstellung von Ressourcen
Amdahls Gesetz auf das Skalieren von Teams anwenden
Das untenstehende Diagramm zeigt die Auswirkungen des Amdahlschen Gesetzes beim Skalieren der Teamanzahl auf die Produktivität.
Wir sehen, dass die Produktivität mit steigender Teamanzahl zunächst unterproportional zunimmt – bis zu einem Höhepunkt und anschließend wieder abnimmt.
Eine Veranschaulichung des Amdahlschen Gesetzes: Der Durchsatz an Ergebnissen steigt mit der Anzahl der Teams, aber nur bis zu einem bestimmten Punkt – und das entspricht meist nicht den Hoffnungen des Managements.
Wenn Sie sich aus diesem Artikel nur eine Sache merken, dann diese:
Mehr Teams können den Durchsatz erhöhen – aber nur bis zu einem bestimmten Punkt.
Was ist also die ideale Teamgröße für ein bestimmtes Projekt?
Leider gibt es keine Gleichung, mit der man im Voraus die ideale Anzahl an Teams für ein bestimmtes Projekt berechnen kann. Der einzige Weg ist, mithilfe von Projektkennzahlen Dinge wie Produktivität und Qualität zu messen und zu beobachten, was passiert, wenn Teams hinzugefügt oder entfernt werden. Meine Empfehlung: Starten Sie klein mit einem Team von 3-6 Personen und erweitern Sie nur dann, wenn es wirklich erforderlich ist.
Irgendwann stellen Sie vielleicht fest, dass Sie bereits die maximale Teamanzahl erreicht haben und Ihr Projekt dennoch nicht alle Anforderungen erfüllen kann. Dann sind Priorisierungs- und Kommunikationskompetenzen gefragt, denn möglicherweise müssen Sie schwierige Gespräche mit Ihren Kunden führen.
Überlegungen zur Teamstruktur: Feature-Teams oder Komponenten-Teams?
Wenn ein neues Team zum Projekt hinzukommt, wie soll es arbeiten? Stellen Sie sich zunächst diese beiden Fragen:
- Werden Sie für die End-to-End-Entwicklung von für Kunden sichtbaren Funktionen verantwortlich sein, oder verändern Sie etwas im System, um Ihr Ziel zu erreichen?
- Werden Sie für die Arbeit an einer bestimmten Komponente zuständig sein, die einen Teil der für den Nutzer sichtbaren Funktionalität bereitstellt?
Wenn Sie bei Nr. 1 „Ja“ gesagt haben, wird das Team ein Feature-Team sein.
Wenn Sie bei Nr. 2 „Ja“ gesagt haben, wird es ein Komponententeam sein.
Tipps zur Auswahl der richtigen Teamstruktur
Die Wahl der geeigneten Teamstruktur und Teamorganisation ist sehr wichtig, aber nicht einfach. Aktuell scheinen Feature-Teams in den meisten Situationen die bevorzugte Option zu sein. Allerdings basiert diese Entscheidung oft auf Gewohnheit oder Routine und nicht auf Daten.
Die Realität ist: „Es kommt darauf an“. Genauer gesagt, hängt es von der Systemarchitektur ab. Softwareprojekte neigen dazu, dem sogenannten Conway’s Gesetz zu folgen—einer empirischen Beobachtung von Mel Conway:
„Organisationen, die Systeme entwerfen … sind darauf beschränkt, Strukturen zu produzieren, die Kopien der Kommunikationsstrukturen dieser Organisationen sind“
Anders ausgedrückt: Die „Form“ der Teamstruktur muss zur „Form“ des Systems passen, sonst wird das Projekt mit ernsthaften Problemen konfrontiert.
Deshalb empfehle ich Managern immer, erfahrene Architekten und technische Leiter in Entscheidungen über die Teamstruktur einzubeziehen—sonst betreiben Manager tatsächlich Systemdesign, ohne es zu merken (und ohne die entsprechenden Fähigkeiten). Das wiederum kann das Risiko eines Projektmisserfolgs erheblich erhöhen.
Zwei Paradoxe der Skalierbarkeit
Aus meiner Erfahrung als Berater bei einer Reihe großer Projekte bin ich zu dem Schluss gekommen, dass Projekte in den meisten Fällen aus den falschen Gründen skaliert werden.
Ich habe zwei Paradoxe erfunden, die das, was ich in der Praxis gesehen habe, zusammenfassen:
Erstes Paradoxon der Skalierung
Die meisten Projekte werden hochskaliert, weil sie die Voraussetzungen für Skalierung nicht erfüllen.
Zweites Paradoxon der Skalierung
Projekte, die die Voraussetzungen für Skalierbarkeit erfüllen, haben einen geringeren Bedarf zu skalieren.
Das erste Paradoxon besagt, dass Projekte in den meisten Fällen langsam vorankommen, weil sie schlecht gemanagt werden.
Das zweite besagt, dass gut gemanagte Projekte einfach deshalb weniger skaliert werden müssen, weil sie gut gemanagt sind.
Tatsächlich hatten die produktivsten Projekte, die ich gesehen habe, nur ein oder zwei kleine Teams und erfüllten alle Voraussetzungen für Skalierbarkeit. Von allen groß angelegten Projekten, an denen ich beteiligt war, habe ich nicht ein einziges gesehen, bei dem alle Voraussetzungen für Skalierbarkeit erfüllt waren. Tatsächlich hatten alle große Schwierigkeiten, auch nur einige dieser Voraussetzungen zu erfüllen.
Wenn Sie an einem Projekt beteiligt sind, das Probleme und Verzögerungen hat, ist die beste Empfehlung, die ich geben kann, das Chaos zunächst zu verkleinern, bevor Sie überlegen, das Projekt zu vergrößern.
Wichtige Hinweise, um Ihre Teams richtig zu skalieren
Das Skalieren von Software-Teams ist nicht einfach und muss mit äußerster Sorgfalt erfolgen. Zum Abschluss ein paar Gedanken, wie Sie den effektivsten Weg finden, ein Software-Entwicklungsteam zu skalieren:
- Wenn Sie an den Voraussetzungen für Skalierbarkeit arbeiten, stellen Sie möglicherweise fest, dass Sie das Team klein halten können und so alle Probleme vermeiden, die mit größerer Teamgröße einhergehen.
- Andererseits, wenn Ihr Projekt bereits groß und herausfordernd ist, konzentrieren Sie sich zunächst darauf, das Chaos zu verkleinern.
Hier sind die ersten Schritte, die ich nach der Lektüre dieses Artikels empfehle:
- Finden Sie heraus, was tatsächlich vor Ort passiert
- Implementieren Sie einige Kennzahlen, um die aktuelle Situation sowie die Qualität der getroffenen Entscheidungen bewerten zu können.