Die ewige Softwarekrise
Softwareprojekte dauern zu lange, kosten zu viel und liefern zu wenig. Diese Klage ist so alt wie die Softwareentwicklung selbst. Die Reaktion darauf ist häufig vorhersehbar: Mehr Entwickler einstellen, längere Arbeitszeiten, bessere Tools, schnellere Rechner. Kurz gesagt — schneller tippen.
Aber was, wenn das Problem gar nicht in der Geschwindigkeit des Tippens liegt?
Die Zahlen erzählen eine andere Geschichte. Eine Geschichte, in der nicht die Effizienz der Entwicklung das Problem ist, sondern die Effektivität — die Frage, ob wir das Richtige entwickeln, nicht wie schnell wir es tun.
Effizienz — wie entwickelt wird
Die Flow Efficiency misst den Anteil der Zeit, in der an einem Feature tatsächlich aktiv gearbeitet wird, im Verhältnis zur gesamten Durchlaufzeit. In den meisten Unternehmen liegt dieser Wert bei erschreckend niedrigen 15 Prozent.
Der Rest — 85 Prozent — sind Wartezeiten. Warten auf Freigaben, auf Zuarbeit anderer Teams, auf Entscheidungen, auf Testumgebungen, auf Code Reviews. Das Feature liegt im Backlog, in der Warteschlange, im Review-Prozess. Es wird nicht bearbeitet. Es wartet.
Was bedeutet das? Selbst wenn wir die reine Entwicklungszeit um 50 Prozent beschleunigen könnten — durch bessere Tools, schnellere Entwickler, effizientere Prozesse —, würde das die Gesamtdurchlaufzeit nur um 7,5 Prozent verkürzen. Die Hälfte von 15 Prozent ist 7,5 Prozent. Der Effekt ist marginal.
Der Multitasking-Faktor
Die ohnehin niedrige Flow Efficiency wird durch Multitasking weiter verschlechtert. Wenn ein Entwickler an drei Projekten gleichzeitig arbeitet, sinkt nicht nur die verfügbare Zeit pro Projekt auf ein Drittel — es kommt zusätzlicher Kontextwechsel-Overhead hinzu. Studien zeigen, dass jeder Wechsel zwischen Aufgaben 15 bis 25 Minuten an Wiedereinarbeitungszeit kostet.
Das Ergebnis: Die effektive Arbeitszeit pro Projekt kann auf deutlich unter 30 Prozent des theoretischen Werts fallen. Schnelleres Tippen hilft da wenig.
Effektivität — was entwickelt wird
Noch dramatischer wird das Bild, wenn man nicht fragt, wie entwickelt wird, sondern was. Eine Studie der Universität Karlsruhe kam zu einem ernüchternden Ergebnis: Nur 20 Prozent der entwickelten Features werden von den Nutzern tatsächlich regelmäßig verwendet.
Das bedeutet: Von fünf Features, die ein Team entwickelt, werden vier selten oder nie benutzt. Nicht weil sie schlecht umgesetzt wären. Sondern weil sie niemand braucht — oder zumindest nicht in der Form, in der sie gebaut wurden.
Die Konsequenz ist einfach, aber unbequem: Das größte Einsparpotenzial liegt nicht darin, Features schneller zu entwickeln. Es liegt darin, die richtigen Features zu entwickeln — und die falschen gar nicht erst anzufangen.
Lösungsansätze
Wenn 80 Prozent der entwickelten Features nicht genutzt werden, ist die wichtigste Fähigkeit eines Produktteams nicht das schnelle Umsetzen, sondern das konsequente Nein-Sagen. Und damit verschiebt sich der Fokus von der Entwicklung zur Produktsteuerung.
Starke Product Owner sind der Schlüssel. Ein Product Owner, der jede Anforderung durchwinkt, ist kein Product Owner — er ist ein Backlog-Verwalter. Ein starker Product Owner versteht die Nutzerbedürfnisse tief genug, um zwischen „nice to have” und „wirklich nötig” unterscheiden zu können. Er sagt häufiger Nein als Ja. Und er verteidigt diese Entscheidungen gegenüber Stakeholdern, die „nur noch dieses eine Feature” wollen.
Validierung vor Umsetzung ist der zweite Hebel. Prototypen, Nutzertests, A/B-Tests, Fake-Door-Experiments — es gibt heute zahlreiche Methoden, um eine Hypothese zu prüfen, bevor man ein Team wochenlang damit beschäftigt. Jedes Feature, das durch einen solchen Validierungsschritt fällt, spart ein Vielfaches der Kosten, die der Test verursacht hat.
Wartezeiten reduzieren bleibt der dritte Ansatzpunkt. Wenn 85 Prozent der Durchlaufzeit Wartezeit sind, lohnt sich jede Investition in kleinere Batchgrößen, schnellere Entscheidungswege und autonomere Teams mehr als jede Investition in schnellere Entwickler.
Fazit
Die Mathematik ist eindeutig. Eine Organisation, die konsequent nur die richtigen 20 Prozent entwickelt und gleichzeitig die Wartezeiten im Prozess halbiert, kann ihre Produktivität um ein Vielfaches steigern — konservativ geschätzt um den Faktor fünf.
Kein neues Tool, kein schnellerer Rechner und kein noch so talentierter Entwickler kann dieses Potenzial heben. Es liegt nicht im Code. Es liegt in der Frage, welcher Code überhaupt geschrieben werden sollte.
Softwareentwicklung wird nicht durch schnelleres Tippen schneller. Sie wird schneller, indem man weniger tippt — aber das Richtige.
Geschäftsführer
Michael Schwarze ist Geschäftsführer von atra consulting und erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung. Er hat in Startups und Konzernen gearbeitet und begeistert sich für moderne Softwarearchitekturen und dynamisch-typisierte Sprachen.
