Gastkommentar : Kontinuierlich besser: Die Macht der kleinen Schritte

In gewissen Kreisen ist die Verbesserung und die Entwicklung in kleinen Schritten schon lange gelebte Praxis. Einige, zumeist Berater mit Verkaufsambitionen, versuchen dies als ganz neue, herausragende Idee zu verkaufen und nennen es dann „Agile“ oder „Scrum“. Aus der Softwareentwicklung kommend, ist dieses Vorgehen in den letzten Jahren sehr populär geworden. Es handelt sich um nichts grundlegend Neues, denn große Dinge sind schon immer durch iterative kleine Schritte entstanden.

Viele kennen den PDCA-Zyklus: Plan, Do, Check, Act. Eine von Walter Shewhart erstmals beschriebene und in den 1940 Jahren durch Edwards Demings 14 Prinzipien für gutes Management populär gewordene Herangehensweise, Prozesse und Produkte zu verändern und zu entwickeln.

Ab den 1950er Jahren griffen Führungskräfte von Toyota in Japan die Idee des PDCA-Zyklus auf und kombinierten diese mit ihrer geistigen Haltung des Kaizen, wonach man Verbesserung wertschätzend für KundInnen und Mitarbeitende stets iterativ in kleinen Schritten vollzieht. Der Vorteil der kleinen Schritte besteht im Wesentlichen in zwei Aspekten:

Man erkennt schon früh Erfolge, was zu mehr Motivation führt.

Im Fall von Fehlern kann man früh eingreifen und diese korrigieren. Dadurch ist der Aufwand einer Fehlerkorrektur gering, und man gewinnt Zeit.

Diese Herangehensweise hat neben Toyota eine Vielzahl von Unternehmen sehr erfolgreich gemacht. In den 1990er Jahren wurde dieses Vorgehen in der Softwareentwicklung noch weiter etabliert, und seitdem wollen fast alle „Scrum“ einführen oder „agil“ sein.

Wie bei Kaizen in den Jahrzehnten davor, haben die meisten nicht verstanden, worum es geht. Oftmals klammern sich Entscheider an die Implementierung von Methoden. Sie vergessen dabei die Tatsache, dass es zu weitaus größerem Anteil um die menschliche Haltung geht, wozu ein Unternehmen da ist und wie es mit KundInnen und Mitarbeitenden umgeht.

Welche Einsatzgebiete gibt es für die kurzzyklische iterative Veränderungsarbeit? Egal, die Vorgehensweise funktioniert sowohl in der Prozess- als auch in der Produktentwicklung. Die Übertragung auf physische Produkte ist sicherlich aufwändiger.

Denn möchte man eine kleine Iteration umsetzen, muss man erst einen Prototypen herstellen, von dem man weiß, dass dieser noch lange nicht dem angestrebten Endprodukt ähnelt. Diese Kosten werden gescheut, da die Rückmeldungen von AnwenderInnen und die Lerneffekte stark unterschätzt werden. Dieses Dilemma kann man nur überwinden, wenn man größer und zeitlich übergeordneter denkt.

Am 20. Juli 1969 betrat Neil Armstrong als erster Mensch die Mondoberfläche, nachdem John F. Kennedy diese Mission im Mai 1961 ankündigte. Zu dem Zeitpunkt hatten die USA gerade mal 20 Minuten Erfahrung mit bemannter Raumfahrt, und diese bestand nur aus einer parabelförmigen Flugbahn.

In nicht mal einem Jahrzehnt hat die NASA alles gelernt, was nötig war, um auf einem Himmelskörper in knapp 400.000 km Entfernung, also der 400-fachen Entfernung der Flughöhe von 1961, bemannt zu landen. Computerprogramme waren in der Zeit sehr rudimentär, und weil Magnetbänder und Lochkarten in Schwerelosigkeit nicht funktionieren, mussten andere Wege gefunden werden.

Die Rechenkapazität der gesamten Saturn V Mondrakete hatte gerade einmal 72 kBytes – heute lächerlich, damals eine große Leistung.

Wir kennen alle die berühmten Mondbilder der ersten Landung. Was aber kaum bekannt ist, ist der Weg dorthin. Die Mission der Mondlandung hieß Apollo 11, es gab also davor schon entsprechende Versionen. Wiederum davor fanden die Gemini-Missionen 3 bis 12 statt. Und auch innerhalb der einzelnen Missionen wurden viele kleinere Tests mit Anlagen und Einrichtungen durchgeführt, die erst entwickelt werden mussten.

Damit war das gesamte Mondprogramm nichts anderes als ein großes Projekt nach den heutigen Prinzipien der Agilität. Jede Mission war ein MMP (Minimum Marketable Product), jedes Modell oder Mock-Up war ein MVP (Minimum Viable Product). Man muss historisch eindeutig feststellen, dass es die Mondlandung nie gegeben hätte, hätte man das Projekt nicht in viele kleine Lernschritte unterteilt.

Auch heute gibt es die Organisationen, die bei der Produktentwicklung kleine Iterationen nutzen. Elon Musk ist bekannt für seine schrägen Ideen, und man kann ihm sicher vorwerfen, dass er vieles verspricht und erst spät liefert – aber er liefert.

Bei Space-X sind die iterativen Schritte aus der Raumfahrt leicht erkennbar, und auch seine Kontrahenten, wie Jeff Bezos (Blue Origin) oder Richard Branson (Virgin Galactic), arbeiten ähnlich.

Aber auch bei anderen Sachen, die aus Musks Ideenblase kommen, wie bei den Fahrzeugen von Tesla, sieht man die Vorgehensweise sehr schön: Das Produkt, etwas das Model S, ist im Wesentlichen seit dem Release im Jahr 2012 äußerlich nur wenig verändert worden, aber der Schein trügt.

Es gibt jedes Jahr eine Vielzahl an Veränderungen, die in das bestehende System integriert werden. Vieles findet auf der Software-Ebene statt, was dazu führt, dass auch Kunden mit älteren Modellen von Verbesserungen profitieren können. Im Gegensatz zu den ersten Gehversuchen deutscher Hersteller muss ein Produkt von Tesla für ein großes Update nicht in eine Werkstatt, denn das erfolgt – wie bei jeder anderen IT-Ressource – over-the-air.

Und damit erkennt man den grundlegenden Unterschied zwischen alter und neuer Produktentwicklung. Damit Produkte in iterativen, kleinen Zyklen konstant weiterentwickelt werden können, müssen diese von den Kundenbedürfnissen her gedacht werden.

Die Verlagerung möglichst vieler Features auf die Software-Ebene erleichtert eine konstante Weiterentwicklung enorm. Aber auch die Hardware-Seite kann so entwickelt werden, dass konstante Veränderungen im Lebenszyklus möglich sind.

Produkte wie ein Tesla Model S haben keinen typischen Produktlebenszyklus mehr. Kunden bekommen immer ein MMP, das konstant weiterentwickelt wird und davon profitieren bei Software-Themen auch Kunden, die ältere Ausführungen haben. Das schafft Begeisterung auf Kundenseite und damit eine gute Kundenbindung.

Die Verbesserung und Entwicklung der iterativen kleinen Schritte ist nicht neu. Schon in der Vergangenheit waren große Innovationen nur so möglich. Kurzzyklische Entwicklungen funktionieren auch bei der Produktentwicklung.

Dafür ist ein anderes Vorgehen erforderlich, das die emotionale Ebene der Kundenbedürfnisse in den Mittelpunkt stellt und dabei möglichst viele Features einerseits modularisiert und andererseits auf die Software-Ebene verlagert.