Seit Menschengedenken wird versucht, das „Unbekannte“ in kleinen Schritten mit den verschiedensten Methoden zu erschaffen. Aus Steinen werden Stufen, aus vielen Stufen wird eine Pyramide. Wahrscheinlich war auch der „Oberbauleiter“ der Cheops-Pyramide jemand, der das Endprodukt noch nicht kannte und von den ständigen „Changes“ des Herrn Pharao mehr als genervt war. Aber er hat es geschafft, die Pyramide steht noch heute!

Vor etwa 30 Jahren versuchte die Technologiebranche, neue und schlanke Methoden zu nutzen. Alles wurde „Lean“und das Schlagwort „kontinuierliche Verbesserung“ thronte über allem und schien der Stein der Weisen zu sein. Agil, schnell, wendig – Turnschuhe statt rahmengenähter Budapester. Trotzdem stagnierte der Fortschritt in der Projektentwicklung, vor allem im Softwarebereich. Meiner Meinung nach ist agiles Vorgehen nur sehr bedingt mit den neuesten UX-Erkenntnissen, Design-Anforderungen und skalierbarer Entwicklung vereinbar.

Mittlerweile gilt „Agile Development“ seit ca. 20 Jahren als das Betriebsprinzip Nr. 1, um Programme und Apps zu entwickeln. Dennoch gibt es vier Schwächen, die offensichtlich sind:

1. Irrtum 1: Menschen sind keine Automaten

2. Irrtum 2: Design ist kein „Ding“, sondern ein Prozess

3. Irrtum 3: 14 Tage sind zu kurz. Die wenigsten Produkte sind in der Zeit eines Sprints so definierbar, dass am Ende des Sprints „alles im Lot“ ist.

Wie hat das alles eigentlich angefangen?

1940er bis 1970er Jahre – Toyota Production System (TPS)
1988 – Lean Production
2001 – Agile Entwicklung
1995 – Scrum

Auf dem Weg zur ständigen Verbesserung

Das TPS wurde von den 1940er bis in die 1970er Jahre kontinuierlich weiterentwickelt. Auf diese Weise war es Toyota möglich, sich seine führende Position als Weltmarktführer in der Automobilbranche zu erarbeiten und über viele Jahrzehnte zu halten. Diese glanzvollen Anfänge konzentrierten sich auf die Beseitigung von

• Muda (sinnlose Tätigkeiten, das Nichtvorhandensein von Sinn oder Nutzen)
• Mura (Inkonsistenz) und
• Muri (Überlastung).

Die Beseitigung von Muda, d. h. die Eliminierung unnötiger Tätigkeiten, war für Toyata wahrscheinlich der wichtigste Bereich, und es wurden sieben Arten von „Muda“ entdeckt. Am schädlichsten für die Produktivität waren überschüssige Lagerbestände (sowohl fertige Produkte als auch zu viele Rohstoffe und untätige Maschinen). Toyata hatte Geld für Dinge ausgegeben, die kein Geld einbrachten. Maschinen, die stillstehen, stehen still… Toyotas Antwort auf Lagerbestände und Überschüsse war mehr oder weniger eine logistische und wurde als „Just-in-Time“ bekannt. Keine großen Lager – alles wurde auf die Straße verlagert und konnte innerhalb kürzester Zeit abgerufen werden. Just in Time bedeutet „gerade noch rechtzeitig“. Nicht 4 Stunden zu früh, aber auch nicht 10 Minuten zu spät.

„Erhalte die Materialien gerade noch rechtzeitig für die Montagelinie, um sie gerade noch rechtzeitig zu verarbeiten, damit das Fertigprodukt dem Kundenbedarf entspricht.“

„Der Toyota Weg“

Ist eher eine Philosophie als eine PM-Methode und erfordert die Bereitschaft zur kontinuierlichen Verbesserung, einschließlich der Bewältigung von Herausforderungen auf dem Weg zu einer langfristigen Vision, Kaizen (Innovation in Operations).

„Real Place, Real Thing“

Auch diese Schlagworte hat uns Toyota beschert. War früher der Herr Fabrikdirektor ein Unbekannter in den Maschinenhallen, so sollte er nach TPM nicht nur hin und wieder durch seinen Fabrik „spazieren“, sondern sich mit der Arbeit, den Arbeitern und dem Weg zum fertigen Produkt an Ort und Stelle befassen.

„Geh und schau selbst!“

und dann die Entscheidungen nach der realen Situation zu treffen, wie man sie eben nur vor Ort erfahren kann. Daraus entstand der Bottom-up-Ansatz, der revolutionär war: Plötzlich galt der einfache Arbeiter am Fließband nicht mehr als Werkzeug, sondern als wichtige Ressource auf dem Weg zur kontinuierlichen Verbesserung. Jeder Mitarbeiter, unabhängig von seiner Position, war plötzlich wichtig. Wow!

Eine Idee geht um die Welt

In Amerika wurde der Toyata-Ansatz um das Jahr 1988 herum als „Lean Management“ und „Lean Production“ umgesetzt. Ob in Japan oder in den USA  – wir befinden uns immer noch in der Welt der Herstellung von „echten“ Produkten. So gesehen haben Autos, Windeln und Tütensuppen viel gemeinsam. Es gibt Rohstoffe, Produktions- und Vertriebswege, Logistik. Also viel zu sehen und anzufassen und damit leichter zu verstehen und zu verändern. Lean ist perfekt für die Produktion von physischen Gütern. Vor allem, wenn es einen etablierten Markt und ein reifes Produkt gibt. Es basiert auf der relativ guten Vorhersagbarkeit der Nachfrage und der Möglichkeit, die Lieferkette zu gestalten. Die Entwicklung neuer Produkte erfolgt durch „Forschungs- und Entwicklungsabteilungen“. Diese greifen mit großer Kreativität in den morphologischen Baukasten, um neue Produkte zu erfinden. Ob es darum ging, synthetisches Insulin bei Genentech oder den Swiffer bei Proctor & Gamble zu entwickeln, der Prozess war langwierig, aber ziemlich linear. Am Anfang stand immer eine recht intensive Marktforschung und -analyse, bevor mit der Entwicklung des Produkts begonnen werden konnte.

Der Wasserfall als „Sündenbock“

Mit der Zeit wurden die Produkte immer weniger greifbar. Zur „Hardware“ kam die „Software“ und damit war ein ganz anderer „Herstellungsprozess“ erforderlich. Es gab kein physisches Vorprodukt, das verändert wurde. Es gab nur eine Idee. Was sollte das Programm leisten?
Auch hier ging es darum, die Realisierung Schritt für Schritt zu begleiten und zu steuern. Vom Bekannten zum Unbekannten, Schritt für Schritt. Oder von Kaskade zu Kaskade, womit wir beim Wasserfall wären.

Der Begriff „Wasserfall“ ist zu einem Sammelbegriff für einen linearen Entwicklungsprozess geworden, dessen Höhepunkt die Veröffentlichung eines vollständig realisierten Produkts ist. Der Hauptkritikpunkt an dieser Methode ist, dass die Definition aller Details und Funktionen im Vorhinein zu aufwendig ist. Das Problem kennt jeder, der mit Lasten- und Pflichtenheften zu tun hat. Weder Kunde noch Agentur oder Programmierer sehen sich in der Lage, zu Projektbeginn eine vollständige Liste aller Funktionen zu erstellen. Und selbst wenn das der Fall wäre: Das fertige Produkt, das Programm oder die App, kann immer noch ein Reinfall sein. Das Wasserfallmodell ist daher ein Paradebeispiel für die Notwendigkeit, wiederholte Iterationen durchzuführen, die entwickelten Module frühzeitig zu testen und auch die Anforderungen und das Feedback der Nutzer einzubeziehen, um nicht nur die „time to market“ zu verbessern, sondern auch die Marktchancen frühzeitig auszuloten. Testen nicht erst dann, wenn alles fertig ist – sondern kleinteilig. Ansonsten droht ein Szenario wie beim Berliner Flughafen. Hätte man das Brandschutzsystem vielleicht früher testen sollen.

Wir kommen langsam in  1990er Jahren und die Rettung scheint in Sicht – !

There’s a New Kid in Town: Wie kann man Lean Production in der Software-Entwicklung nutzen?

Bei den bewährten Lean-Systemen aus der Produktion stand und steht der Zeitfaktor im Vordergrund: Das Produkt soll in kürzerer Zeit zu geringeren Kosten auf den Markt gebracht werden. Das Produkt als solches war ja bereits definiert und vorhanden. Die Frage ist: Wie kann die Kinderwindel im Disney-Layout nun schnell und kostengünstig produziert werden? Ich bin mir nicht sicher, aber ich glaube, genau hier liegt der Denkfehler in der Adaption für die digitale Industrie. Geht es wirklich darum, schneller und billiger auf den Markt zu kommen? Geht es nicht darum, das PRODUKT so zu programmieren, dass es den Bedürfnissen der Nutzer entspricht? Es geht weniger um die Cashflow-Perspektive, sondern mehr um die Effizienz im Kreativ- und Entwicklungsprozess. Gerade die Designphase ist ein wesentlicher Prozessbestandteil, der im Wasserfallmodell oft als dummer Zeitfresser gebrandmarkt wurde.

Der „Kampf“ zwischen den Verfechtern des Wasserfallansatzes und des agilen Lean-Ansatzes war in vollem Gange. Um ehrlich zu sein, wurde letztendlich über zwei  Diagramme gestritten und dabei aus den Augen verloren, dass Wasserfall das große Ganze im Blick hat und agile Methoden nur einen Teil des Ganzen!

Agile Entwicklung geht fälschlicherweise davon aus, dass das jeweilige „Feature“ eines Softwareprodukts überarbeitet wird. Und Wasserfall geht ebenso fälschlicherweise davon aus, dass das gesamte Produkt nie mehr überarbeitet wird. Beides ist falsch.

Wir dürfen nicht aus den Augen verlieren, dass wir die Software jederzeit iterieren können – es müssen keine Produktionslinien umgestellt, keine Werkzeuge geändert, keine anderen Logistikwege entwickelt werden. Es ist nur ein Stück Code! Das ist ein Luxus, den man nicht oft genug betonen kann.

Jedes technologische Produkt kann auf diese Weise in Stufen entwickelt werden, die auf ein Endziel und ein vollständig „fertiges“ Produkt ausgerichtet sind. Erfolgreiche Softwareentwicklung erfordert Strategie, Forschung, Design und „genchi genbutsu“. Der Toyota Weg lässt grüßen!

Die lange Diskussion „Wasserfall vs. agile Entwicklung“ ist eine falsche Gegenüberstellung, beide Methoden sind nicht „exklusiv“. Ein Unternehmen kann gleichzeitig eine langfristige Strategie haben und verfolgen, während die Produktentwicklung schrittweise und iterativ erfolgt.

Scrum: Ein Fehler?

Eine Verschmelzung beider Ansätze, sei es von Entwicklern oder Product Ownern, führte zu einer virtuellen Fertigungsstraße für die Programmentwicklung: Alle Anforderungen werden gerade noch rechtzeitig („just in time“) ermittelt, und dann sprintet ein funktionsübergreifendes Team los, um in sich abgeschlossene, lauffähige Module zu programmieren. Der Begriff „Scrum“ war geboren, in Anlehnung an eine Spielsituation im Rugby, bei der sich beide Mannschaften an der Mittelllinie gegenüberstehen und auf den Anpfiff warten – bevor es auf dem Spielfeld wild zugeht…
Keine Frage: Hier muss der Scrum Master als „Coach“ aktiv eingreifen, damit die Leute nicht wild durcheinander rennen und kreatives Chaos verbreiten.

Scrum ist da, hat seine Daseinsberechtigung und Spielregeln, die es zu beachten gilt.

• Ein Sprint muss zeitlich begrenzt sein, damit die Software in einem „iterativen“ Zyklus zur Marktreife gebracht werden kann.
• Das Sprint Planning findet unmittelbar vor dem Sprint statt (just in time), damit das Team die aktuellsten Informationen berücksichtigen kann.
• Tägliches Stand-up mit Rederecht nur für die Entwickler kurzfristig, um „operative Verbesserungen“ zu erreichen. Keine Diskussionen, weil dadurch die Maschinerie inaktiv bleibt.
• Sprint-Ende: Was wurde entwickelt und wie funktioniert die Iteration? Was wurde nicht fertig gestellt und was kann verbessert werden?
• Sprint-Rückblick: Was ist gut gelaufen, was ist schlecht gelaufen – Ziel ist es, den Output an „fertig“ zu erhöhen.
• Backlog als Sammlung all dessen, was getan werden soll und muss. Oft ist es – um bei Toyota zu bleiben – eine Muda-Sammlung all dessen, was im Sprint verworfen wurde.

Agile Manifest

Wer sich mit Scrum beschäftigt, kommt um das Agile Manifest nicht herum. Der Begriff „Manifest“ klingt nach Marx, und ein bisschen Marx steckt auch in Scrum selbst. Die Arbeiter sind diejenigen, die nach der „reinen Lehre“ die Produktionsmittel besitzen sollten.

Das Manifest beschreibt vier „Werte“ und zwölf „Prinzipien“. Die Idee war wohl, Entwickler als Menschen zu sehen und nicht als Zahnräder in einer Maschine, die unbegrenzt Gas geben können. Aus Sicht einer Agentur mit vielen digitalen Projekten wird auch heute noch – oft vom Kunden – ausgegangen, dass die Programmierer die ganze Nacht Zeit haben und wenn es nicht reicht, können sie ja am Wochenende arbeiten. Die Website muss schließlich online gehen…

Die meisten Entwickler, mit denen ich zusammenarbeite, haben eine Leidenschaft dafür, Dinge gut zu machen. Der Zeitfaktor bezieht sich hier nicht so sehr auf Nachtarbeit – sondern eher darauf, dass 14 Tage eben nur 14 Tage sind und sie dadurch in der Zwickmühle sind, zu liefern. Man liefert dann nicht das Beste, sondern nur das Beste, was man in 14 Tagen erreichen kann. Nur wenige Künstler sind wirklich in der Lage, ihre Kunst in Sekundenschnelle zu liefern. Und wenn der Maler das Wohnzimmer in Höchstgeschwindigkeit blau streichen soll, kann sich jeder das Ergebnis vorstellen. Je kürzer die Zeit, desto besser das Ergebnis stimmt meistens nicht.

Manchmal haben Scrum und agiles Arbeiten sektiererische Züge angenommen. Es kommt vor, dass „Scrumisten“ die Einhaltung des Manifests mit Prince2-ähnlichen Zügen verteidigen. Quasi im Wahn zu bekehren und auf die reine Lehre zu achten. Andererseits gibt es auch das Gegenteil, wie das Manifest zu interpretieren ist: Die Anforderungen sind nur ein Vorschlag, die Designs sind eine Interpretation, alles ist ein Spiel, dessen Spielregeln immer wieder angepasst werden können und man muss nur aufpassen, dass das Endergebnis noch „funktioniert“.

Mehr Zeit schafft nicht mehr Kreativiät

Das ganze System ist wie der Scrum-Zyklus: Es läuft heiß. In einem Unternehmen, auch in einem Softwareunternehmen, gibt es immer funktionale Abhängigkeiten und die Notwendigkeit der internen Abstimmung zwischen Abteilungen oder Teams. Designer, Produktmanager und Entwickler sind eben nicht in diesem Maße selbstorganisiert und eine „Insel“, sondern auch Teil eines Ganzen. Und dieses Ganze ist nicht das MVP, sondern das Unternehmen mit all seinen sozialen und funktionalen Abhängigkeiten, im Guten wie im Schlechten. Wer als Designer arbeitet, steht vor der gleichen Herausforderung wie ein Programmierer: In 14 Tagen etwas „Tolles, Buntes, Einzigartiges“ zu schaffen, ist schwierig. Designprozesse bleiben kreative Prozesse. Weniger Zeit bedeutet nicht, dass man das durch mehr Kreativität kompensieren kann.

Forschung und Design wollen echte und wirklich passende Lösungen für Kundenprobleme. Das was abgeliefert wird, ist im Vergleich zum angedachten „glanz“ dann doch etwas blass – und das hat nichts mit mangelnden Können oder Wollen zun tun!
Bei den Entwicklern zeigt sich die Misere am deutlichsten. Trotz „Manifest“ werden sie wie Maschinen am Fließband behandelt, mit der Erwartung, immer produzieren und liefern zu können. Angehalten, schneller zu werden und einfach nur zu arbeiten. Wann seid ihr endlich „fertig“?

Und Führungskräfte wundern sich, warum trotz neuer Methode mit allem „Scrum und Dran“ das Produkt so fehlerhaft ist.

Wir sind weit davon entfernt, mit Scrum und agiler Entwicklung alles „Muda“ zu beseitigen, diese Methoden liefern eher Nachschub! So werden Burnouts produziert, die Backlogs wachsen und keiner ist mit seinem Beitrag wirklich zufrieden. Es hätte besser laufen können. So ist es gerade noch „jut jejange“, wie der Kölner sagt.

Wie kommt man aus diesem Schlamassel raus?

Einfach aufhören! Eine kundenorientierte Lösung lässt sich nicht in einen Sprint pressen. Eine Lösung muss die Zeit haben, sorgfältig recherchiert, entworfen und entwickelt zu werden, um sicherzustellen, dass sie den Bedürfnissen der Kunden entspricht. Ein produktzentrierter Ansatz, bei dem das Kundenerlebnis im Vordergrund steht, ist eine bessere Wahl als agiles Vorgehen und Scrum. Dieser Ansatz kann auch eine Kombination aus agilen Methoden und anderen Prozessen beinhalten, um sicherzustellen, dass das Endprodukt den Kundenanforderungen entspricht und dennoch schnell marktfähig ist. Es ist an der Zeit, einen neuen Standard in der Entwicklung zu etablieren der auf einem produktzentrierten Ansatz basiert und den Bedürfnissen sowohl der Kunden als auch der Entwicklungsteams gerecht wird.