Suche
Scale up

Skalieren zum nächsten Level: Wachstum jenseits von zehn Leuten und 100 000 Zeilen Code

Matthias Bohlen
BT-Magazin-4-15_Aufmacher_Bohlen_iStock_ysunnie_900x600

©iStockphoto.com/ysunnie

Sagen wir, Sie sind Gründer eines erfolgreichen Start-ups. Mit drei Freunden zusammen haben Sie die erste Version Ihrer Software geschrieben. Sie haben inzwischen genügend Kunden, und das Geld kommt herein. Großartig! Doch was jetzt? Sie wollen Ihre Codebasis auf jenseits von 100 000 Zeilen skalieren, und Ihre Teams sollen auf mehr als zehn Leute wachsen, richtig? Welche Hindernisse dann zwangsläufig auftauchen und was Sie tun können, um solides Wachstum zu ermöglichen, darum geht es in diesem Artikel.

Als ich in den letzten Semestern meines Informatikstudiums steckte (1980er-Jahre), arbeitete ich für eine Firma, die man heute ein Start-up nennen würde. Vier Leute haben die Firma gegründet. Sie wollten Rechner für die Steuerung von Industrieprozessen herausbringen, auf Basis des MC68000-Prozessors von Motorola, der damals gerade neu herausgekommen war. Also baute der Mitbegründer die Hardware, einer schrieb das Betriebssystem, einer den Texteditor und ich (als „Externer“) den Compiler. Einer der vier Gründer übernahm den Vertrieb, denn er war gut darin, Leute zu begeistern. Kunden kauften die neue Hardware, denn sie war schneller und reaktionsfähiger als alle Mikrocomputer, die es bis dahin gab. Der IBM PC war in Deutschland noch nicht im Handel, sah nicht gut aus und hätte auch, was die Performance anbetrifft, nicht mithalten können. Das Ganze funktionierte. Es gab zahlende Kunden, und die Wachstumsgeschichte der Firma nahm ihren Lauf. Die Firma gibt es noch heute, und sie ist immer noch erfolgreich.

Wachstum

Wie diese Firma beginnen viele. Zunächst funktioniert das auch gut. Wenige Jahre nach Einsetzen der Kundennachfrage gibt es aber meist eine Veränderung: Die Firma möchte wachsen und mehr Geld verdienen. Dazu macht sie sich das unbestreitbare Gesetz für geschäftliches Wachstum zu Nutze, denn es gibt nur drei Wachstumsfaktoren, um ein Geschäft wachsen zu lassen:

  1. Erhöhe die Zahl der Kunden
  2. Erhöhe den durchschnittlichen Wert einer Transaktion pro Kunde
  3. Erhöhe die Zahl der Transaktionen pro Kunde

Wenn Sie diese drei Faktoren um je 15 Prozent erhöhen, wächst Ihr Umsatz um 52 Prozent. Also gut, drei Wege, um zu wachsen. Ganz einfach, oder? Das hängt natürlich davon ab, wo Sie stehen. Sagen wir, Sie sind der erfolgreiche „Vertriebler“ Ihrer Firma. Sie haben ein wahres Feuer im Markt entfacht, das sich schnell ausbreitet. Bald stehen große Kunden bei Ihnen Schlange, um Ihr Softwareprodukt zu kaufen.

Jedoch: Weil die Kunden groß sind, brauchen sie neue Features oder Anpassungen Ihres Produkts. Als guter Vertriebler verkaufen Sie, was Sie nicht haben und sagen „Natürlich, kein Problem. Legen Sie Ihr Geld hierher, und wir sehen uns in sechs Monaten wieder.“ Dann gehen Sie zu Ihrem Entwicklungsteam und bringen ihm die Nachricht.

Zu geringe Lieferfähigkeit

Wenn Sie das einige Male machen, haben Sie die Anzahl der Kunden erhöht (Wachstumsfaktor 1), doch Sie haben die Fähigkeit Ihres Teams nicht verbessert, das Bestellte auch zu liefern. Das Team wird versuchen, sein Bestes zu tun und die Kunden, die Sie mitgebracht haben, zufriedenzustellen. Doch weil es nur wenige Leute im Team gibt und die Konfusion unter ihnen groß ist, können sie nur wenig tun. Mehr Leute und klarere Abläufe müssten her. Das ist die Wachstumshürde Nummer eins für eine Softwarefirma: die limitierte Lieferfähigkeit.

Konfusion

Ihre Firma liefert die Software also endlich aus. Die Kunden probieren sie aus und sind nicht zufrieden. Sie berichten von Fehlern und mangelnden Features. In der Zwischenzeit haben Sie, der erfolgreiche Vertriebler, weitere Kunden akquiriert und das Team dazu gebracht, auch für diese Kunden Software zu schreiben. Im Team mischt sich nun das Bugfixing für „alte“ Kunden mit der Featureentwicklung für „neue“ Kunden.

Beschwert sich ein alter Kunde, lassen die Entwickler alles fallen, arbeiten an der Beschwerde, liefern einen Fix und kehren dann zu ihrer Featurearbeit zurück. Das verursacht Multitasking und noch mehr Bugs als zuvor. Das Ganze ist nicht linear: Doppelt so viel Arbeit verursacht mehr als doppelt so viele Bugs wie zuvor.

Jetzt sind die Kunden unglücklich und weigern sich, zu bezahlen, weil die Qualität so niedrig ist. Dadurch fällt der Wachstumsfaktor 2 (durchschnittlicher Transaktionswert pro Kunde) und hat eine negative Auswirkung auf den Cash Flow der Firma. Das ist die Wachstumshürde Nummer zwei: Konfusion im Prozess.

Zu viel Kopplung

Schlussendlich hat Ihre Firma Erfolg beim Anstellen neuer Leute. Sie wachsen auf 20 Mitarbeiter. Gut so, oder?

Sie sind nun von einem auf drei Teams gewachsen. Alle Teams arbeiten, um neue Features zu Ihrer Software hinzuzufügen. Plötzlich kommt ein Entwickler aus Ihrem Mobile-Apps-Team vorbei und beschwert sich, dass ein Mitglied des Core-Teams etwas im Core geändert hat, sodass seine App plötzlich nicht mehr funktioniert und gefixt werden muss. Der Mitarbeiter aus dem Core-Team sagt natürlich, er habe nur einen Teil im Code geändert, der mit der Mobile-App nichts zu tun hat. Und er sagt, er verstünde überhaupt nicht, wie es möglich sei, dass die Mobile-App kaputtgegangen ist.

Die zwei fixen das Problem gemeinsam und machen weiter.

Zwei Tage danach passiert dasselbe: Ein Teammitglied ändert etwas, und ein Teil des Systems, der scheinbar nichts damit zu tun hat, funktioniert nicht mehr. Innerhalb der nächsten sechs Monate nimmt die Zahl dieser Beschwerden immer weiter zu. Ihr Team wird langsamer.

Wachstumsfaktor 3 (Anzahl Transaktionen pro Kunde) lässt nach, weil die Teams nicht mehr in der Lage sind, ebenso viele Features pro Monat zu liefern, wie zuvor.

Das war Wachstumshürde Nummer drei für ein Softwaregeschäft: Zu viel Kopplung in der Softwarearchitektur.

Teamaufteilung unpassend

Nach einer Weile stellen Sie vielleicht fest, dass die Teams unfähig geworden sind, ihre Versprechen einzuhalten. Team A merkt an, dass sie auf Team B warten müssen, weil dort eine Komponente entwickelt wird, auf die sie aufbauen. Team A wird noch weiter verzögert, wenn Team B gerade dabei ist, einen anderen Kunden zu bedienen.

Zunächst kurieren Sie das Problem noch, indem Sie den Kunden mitteilen, dass Ihre Firma „ein wenig später“ liefern wird. Plötzlich kommt jedoch auch noch ein Mitglied aus Team C und sagt Ihnen, dass sie auf die Teams A und B warten müssen, weil (Sie ahnen es schon) sie Komponenten von dort benötigen. Team C ist blockiert, weil sie auf A warten, die wiederum auf B warten.

Das kratzt schon wieder an Wachstumsfaktor 3: Die Anzahl Transaktionen pro Kunde lässt nach, weil es Verzögerungen in der Erfüllung früherer Transaktionen gibt.

Wir begegnen hier Wachstumshürde Nummer vier für eine Softwarefirma: Ein Mismatch zwischen der Teamorganisation und der Produktarchitektur.

Ursachen

Teams und Geschäftsführung stellen fest: Die bestehenden Strukturen aus der Gründungsphase reichen nicht mehr aus. Woran liegt das, und was können Sie als Chef tun, wenn Sie in derselben Situation stecken?

Wenn Sie Wachstum nicht systematisch planen und durchführen, werden sich seltsame Effekte einstellen. Die hohe Kundennachfrage führt zu Zeitdruck und Konfusion. Skalieren Sie eine kleine, leicht verwirrte Firma, erhalten Sie eine große, stark verwirrte Firma. Zeitdruck und Konfusion werden in der Folge dazu führen, dass die Architektur des Produkts immer weiter verfällt, und Sie haben nach ca. fünf Jahren ein Produkt mit einem toten Kern – das ist bei uns Beratern die Bezeichnung für den Zustand, in dem jedes neu eingebaute Feature mehr kostet, als es nützt.

In der Regel unterstützen Architekturen, die für kleine Systeme gemacht wurden, kein nachhaltiges Wachstum, sondern müssen rechtzeitig dafür überarbeitet werden. Bei Prozessen ist es dasselbe: Anfängliche Prozesse, in denen man viel von Hand tut, skalieren nicht beliebig weit. Und: Teams, die keine klare Aufgabenzuordnung haben, skalieren ebenfalls nicht, weil sie nicht wissen, wie sie mit wachsender Firmengröße arbeiten und kommunizieren sollen.

Der Faktor 10

Was können Sie als Chef einer erfolgreichen Firma, die jetzt skalieren möchte, gegen die Wachstumsschmerzen tun? Das Skalieren einer Softwarefirma besteht aus drei Komponenten:

  • Die Architektur des Produkts fehlerfrei erweiterbar machen.
  • Die Prozesse klären, vereinfachen, automatisieren.
  • Die Organisation der Architektur und der Prozesse angemessen umstellen.

Betrachten Sie das Kräftedreieck aus A, P und O in Abbildung 1. Wenn Sie an einer der drei Ecken ziehen (also etwas verändern), müssen die anderen angepasst werden, sodass sie sich mitbewegen können.

Abb. 1: Architektur, Prozess, Organisation

Abb. 1: Architektur, Prozess, Organisation

Machen Sie ein Gedankenexperiment. Stellen Sie sich vor, Ihre Firma multipliziert sich mit zehn: Zehnmal mehr Umsatz, zehnmal mehr Anfragen von Kunden, zehnmal größere Software. Wie müssten dann Architektur, Prozesse und Organisation aussehen, um das zu bewältigen? Wenn Sie groß denken und gleichzeitig etwas realistisch veranlagt sind, merken Sie: „Das geht nicht einfach mit zehnmal mehr Leuten. Das muss schlauer funktionieren.

Bevor Sie also richtig zuschlagen und von 100 000 auf eine Million Zeilen Code hochskalieren, überlegen Sie: Fehler entstehen, wenn eine Änderung an einer Stelle des Codes Nebenwirkungen an einer anderen Stelle des Codes erzeugt. Die Wahrscheinlichkeit dafür steigt mit der Zahl der Kommunikationsverbindungen zwischen den Codestellen. Wenn Sie Code schreiben, in dem alles mit allem verbunden ist, haben Sie beliebig viele Möglichkeiten für Fehler. Architektur skaliert also nur, wenn ein Subsystem in kleine Teile zerteilt ist, die intern stark und nach außen wenig kommunizieren. Teilen Sie also Ihr System entlang fachlicher Grenzen in Subsysteme auf. Diese Subsysteme lassen Sie intern sehr viel tun, doch nach außen nur über eindeutig definierte Schnittstellen miteinander kommunizieren (Abb. 2).

Abb. 2: Kopplung in der Architektur reduzieren

Abb. 2: Kopplung in der Architektur reduzieren

Soll ein Prozess plötzlich zehnmal mehr leisten, so muss er so klar sein, dass mehr Menschen oder mehr Maschinen ihn ausführen können. Sprechen Sie mit Ihren Teams: Wenn eine Tätigkeit so richtig gut klappt, fragen Sie warum. Lassen Sie es sich an einem Whiteboard erklären. Wenn das Bild, das entsteht, ganz klar ist, lassen Sie Ihre Mitarbeiter eine Schritt-für-Schritt-Anleitung (ein „How-To“) für diese Tätigkeit im Prozess aufschreiben. Verteilen Sie diese How-Tos in der Firma und lassen Sie andere Leute Feedback geben. Wenn das How-To automatisierbar ist, die Ergebnisse gute Qualität haben und es sich finanziell lohnt, dann überlassen Sie diese Arbeit ab jetzt einer Maschine. Wenn nicht, erlauben Sie Ihren Mitarbeitern, sich aus den How-Tos eigene Prozesse zusammenzustellen, diese zu leben und zu verbessern.

Werfen Sie ein Auge auf diese Prozesse: Lassen Sie die Teams herausfinden, was das Bottleneck ihres eigenen Prozesses ist. Ist es ein Mensch, eine Maschine, eine Methode, eine Fähigkeit oder Wissen? Lassen Sie die Teams selbst melden, wo das größte Hindernis zur Skalierung besteht und adjustieren Sie entsprechend.

Sind Architektur und Prozesse klar genug aufgeteilt, können Sie daran gehen, die Organisation anzupassen. Seien Sie sich bewusst: Wenn in der Software eine Komponente A und eine Komponente B eng zusammenarbeiten sollen, hat es Sinn, die Teams, die diese Komponenten hervorbringen, ebenfalls eng zusammenarbeiten zu lassen (oder gleich von demselben Team machen zu lassen). Wenn Sie hingegen wollen, dass es in der Software eine stark ausgeprägte trennende Schnittstelle gibt, geben Sie das, was diesseits und jenseits der Schnittstelle liegt, am besten zur Realisierung in getrennte Teams.

Zeichnen Sie außerdem einen Abhängigkeitsgraphen der Komponenten. Sie erkennen daraus, wer auf wen warten muss, wenn die Komponenten gebaut werden sollen. Lassen Sie die Mitarbeiter Vorschläge machen, wie Abhängigkeiten aufgelöst werden können, sodass ein Team unabhängig und schlagkräftig wird. Beispielweise könnte eine Komponente B zuerst als Vorabversion gebaut werden, um zu prüfen, ob Komponente A bereits damit funktioniert. Das stabilisiert die Schnittstelle, und das Team, das sich um B kümmert, kann danach unabhängig arbeiten, ohne das Team, das an A arbeitet, warten zu lassen.

Stellen Sie Ihre Teams schlussendlich um, sodass sie so getrennt bzw. verbunden sind, wie es die Zielarchitektur Ihres Produkts verlangt. In Abbildung 3 erstellt Team 1 die Ergebnisse 1a und 1b (z. B. ablauffähige Docker-Container), Team 2 erstellt Ergebnis 2. 1a und 1b sollen mit 2 nur sehr lose gekoppelt sein, deshalb gibt man sie zur Entwicklung in verschiedene Teams.

Abb. 3: Teamschnitt und Softwareschnitt

Abb. 3: Teamschnitt und Softwareschnitt

Jetzt erst ist der Zeitpunkt gekommen, entschlossen neue Mitarbeiter einzustellen. Herrscht Klarheit in der Architektur und sind die Bottlenecks in den Prozessen bekannt, dann ist auch klar, an welchen Stellen „mehr vom selben“ etwas nützt und wo es eher schadet oder überflüssig ist. Sie wissen dann, ob Sie besser mehr Entwickler, mehr Tester oder mehr Kundenberater einstellen sollten, und setzen Ihr Kapital sinnvoll ein.

Fazit und Ausblick

In diesem Artikel habe ich gezeigt, welche Vorteile es hat, wenn Sie die Skalierung Ihrer Softwarefirma systematisch und schrittweise angehen. Hier noch einmal die Schritte, die Sie gehen sollten, in der idealen Reihenfolge:

  • (1a) Die Architektur des Produkts fehlerfrei erweiterbar machen.
  • (1b) Die Prozesse klären, vereinfachen, automatisieren.
  • (2) Die Organisation der Architektur und der Prozesse angemessen umstellen.

Schritte 1a und 1b können parallel erfolgen. Beides braucht seine Zeit und beeinflusst sich gegenseitig. Schritt 2 sollten Sie erst durchführen, wenn Sie weitgehend Klarheit in den ersten beiden Schritten haben. Menschen verändern sich nicht sonderlich gern, vor allem: Sie werden ungern von außen verändert.

Für diese Schritte gibt es bewährte Methoden und Tools, auf die ich in zukünftigen Artikeln zu sprechen kommen werde.

Geschrieben von
Matthias Bohlen
Matthias Bohlen
Matthias Bohlen arbeitet als Experte für effektive Produktentwicklung. Teams engagieren ihn als Coach in vielen Projekten, um Prozesse, Architektur und Organisation für sich selbst zu finden und aufzustellen. Matthias Bohlen hilft aktuell auch Teams, die gerade die Startup-Phase verlassen und zu einer erfolgreichen Company skalieren. Er hat für Sie zu dem Thema weiteres Material zusammengestellt, das Sie unter http://scaletonextlevel.com finden können.
Kommentare

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.