• Home
  • |
  • Blog
  • |
  • Produktentwicklung: Warum wir nicht besser werden

12. Mai 2020

Produktentwicklung: Warum wir nicht besser werden

Ein einzelnes Team ist schnell mit Scrum oder Kanban versorgt und beginnt mit Fokus, ständiger Verbesserung und Transparenz die Welt innerhalb des Teams besser zu machen. Nicht immer sind jedoch die Verbesserungen außerhalb eines solchen Teams spürbar, bleibt es doch aus Lean-Sicht eine lokale Optimierung – welche die Kette nicht schneller macht, sondern unter Umständen sogar ausbremsen kann.

Doch nicht nur der Lean-Philosoph, sondern auch das beschriebene Team, kommt schnell auf das „System“ zu sprechen: Nach den ersten paar Iterationen der teaminternen Verbesserung kommen Probleme an die Oberfläche, deren Ursprung außerhalb des Teams liegen. Nicht selten sind dies Erwartungen und Vorgaben des Managements welche im Widerspruch zu den Prinzipien und Erfahrungen stehen, die den Erfolg von „Lean“ ausmachen.

„Oh, das sind große Worte…“, wirst Du jetzt denken, „das ist doch nicht überall so“. Nun, die Gemeinsamkeiten zwischen verschiedenen Unternehmen/Organisationen hinsichtlich ihrer Einstellung zur Produktentwicklung sind nicht zu übersehen, viele von ihnen folgen ähnlichen Mustern und Reflexen. Und genau diese sind es, die aus Lean-Sicht die oft beklagten Probleme in einer Entwicklungsorganisation verursachen. Meine Aussage beinhaltet natürlich auch, dass in Deiner Organisation das alles ganz anders sein kann.

Aus meiner Sicht ist es bisher niemand besser gelungen diese Gemeinsamkeiten auf den Punkt zu bringen als Donald Reinertsen in seinem Buch „The Principles of Product Development Flow“. Dieses Buch halte ich auch elf Jahre nach seiner Veröffentlichung immer noch das für das mit am Abstand beste Buch über das Wesen der Produktentwicklung. Reinertsen fasst die vorherrschenden (problematischen) Denkmuster in zwölf Statements zusammen. Diese sind:

  1. Das Unvermögen die wirtschaftlichen Aspekte korrekt zu bestimmen (Failure to Correctly Quantify Economics)
  2. Das Ignorieren von Warteschlangen (Blindness to Queues)
  3. Die Verehrung von Effizienz (Worhsip of Efficiency)
  4. Die Ablehnung von Variabilität (Hostility to Variability)                 
  5. Die Verehrung von Planeinhaltung (Worship of Conformance)
  6. Das Verankern von großen Losgrößen (Institutionalization of Large Batch Sizes)
  7. Das mangelnde Ausnutzen von Kadenzen (Underutilization of Cadence)
  8. Das Managen von Zeitleisten anstatt von Warteschlangen (Managing Timelines instead of Queues)
  9. Das Fehlen von WIP-Limitierungen (Absence of WIP Constraints)
  10. Der Mangel an Flexibilität (Inflexibility)
  11. Das nichtwirtschaftliche Management des Flusses durch die Entwicklung (Noneconomic Flow Control)
  12. Zentrales Management (Centralized Control)

(Übersetzung nach meinem Verständnis, Original-Begriff in Klammern)

Vielleicht kommt Dir jetzt schon der eine oder andere Punkt bekannt vor, aus dieser kurzen Liste wird jedoch nicht bei jedem Punkt sofort klar, was dahintersteckt. Im Folgenden werde ich diese 12 Probleme kurz besprechen, damit kann Dir diese Liste als kleine Checkliste bei Deinen Verbesserungsaktivitäten in Deiner Organisation dienen.

1. Das Unvermögen die wirtschaftlichen Aspekte korrekt zu bestimmen

Viele Metriken (immer wieder leichtfertig als KPI bezeichnet) stehen unter strenger Beobachtung der Prozessverbesserer und Führungskräfte. Sie sollen uns Anhaltspunkte dafür liefern, ob die von uns unternommenen Anstrengungen auch der Verbesserung der Organisation dienen. Die Messgrößen werden hierbei jedoch oftmals aus dem Bauch oder durch Überlieferung definiert, ohne sich mit deren Wechselwirkungen auseinanderzusetzen. Da jede Veränderung eines Parameters sich immer auf andere Parameter auswirkt, ist gezieltes Handeln nur möglich, wenn eine gemeinsame „Währung“ zur Abwägung von Veränderungsmaßnahmen existiert. „Währung“ sollte hier durchaus wörtlich genommen werden, denn letztendlich geht es immer um die Auswirkungen einer Maßnahme auf den Gewinn, der mit einem Produkt über seinen gesamten Lebenszyklus hinweg erzielt wird. Kennzahlen wie Qualität, Entwicklungszeiten, Auslastung, usw. sind nur indirekte Messungen der Einflüsse auf den Gewinn. Wer wirtschaftlich optimierte Entscheidung treffen will, muss alle Messungen in eine finanzielle Währung umrechnen können:

  • Welcher Gewinn entgeht uns durch einen Monat Projektverzögerung?
  • Bei welcher Auslastung haben wir den maximalen Gewinn?
  • Welche Auswirkungen hat Qualitätskennzahl XY auf den Gewinn?
  • Welche Auswirkungen hat die Auslastung auf die Projektverzögerung?

Diese Fragen lassen sich beliebig fortsetzen, die meisten mir bekannten Organisationen haben keine Antwort darauf. In diesem Fall wird jede Entscheidung zu einer lokalen Optimierung und ein wirtschaftliches Optimum könnte sich nur durch reinen Zufall ergeben. Besonders prominent an dieser Stelle ist das in vielen Organisationen fehlende Verständnis für die negativen Auswirkungen einer zu hohen Auslastung auf den Projektgewinn durch Verzögerungskosten (Cost of Delay, COD). Auch wenn das der rote Faden bei Donald Reinertsen ist, in diesem einen Zitat von fasst er alles zusammen:

„While you may ignore economics, it won’t ignore you.“

Donald Reinertsen

2. Das Ignorieren von Warteschlangen

Die Mathematik der Warteschlangentheorie setzt die Auslastung eines „Servers“ (Mensch, Organisationseinheit, Maschine usw.) in das Verhältnis zu der Länge der Warteschlange mit unerledigten Aufgaben vor dem Server. (Mehr zu diesem Thema findest du in meinem Artikel „Mehr Gewinn durch weniger Effizienz“ im Projektmagazin. Falls Du kein Abo hast, kann ich ihn Dir auf Anfrage gerne zusenden).

Die Warteschlangentheorie zeigt uns, dass der Zusammenhang zwischen Auslastung und Länge der Warteschlange (also der Lieferzeit) des Servers nicht linear ist. Bei hoher Auslastung kann eine weitere Erhöhung der Auslastung um wenige Prozent die Lieferzeit um beträchtliche Faktoren nach oben katapultieren. Du kennst diesen Effekt vom Stau aus auf der Autobahn, der aus dem Nichts kommt. In einer Entwicklungsorganisation, sind Warteschlangen vor jedem Team, vor dem Experten, vor dem Prüfstand usw. zu finden. Obwohl sie überall existieren, sind sie oftmals – genauso wenig wie die Mathematik dahinter – nicht im Bewusstsein der Führungskräfte und der Mitarbeiter. Wer sich jedoch erst einmal über die Verzögerungskosten in seiner Organisation bewusst ist, der erkennt, dass die bislang unsichtbaren Warteschlangen jeden Tag gigantische Summen Geld vernichten, die in keinem Excel des Controllings auftauchen. Warteschlangen zu visualisieren und sie als primäres Management-Instrument zu verwenden ist der Schlüssel um „Verstopfungen“ rechtzeitig zu erkennen und den Fluss in der Entwicklung aufrecht halten zu können.

3. Die Verehrung von Effizienz

Forderungen nach Erhöhung der Effizienz sind omnipräsent. Solange damit die Verringerung von Verschwendung (Waste) gemeint ist kann ich gut damit leben. Nicht selten beziehen sich solche Aussagen jedoch auf die Auslastung von Menschen und Maschinen. Eine hohe Auslastung geht jedoch mit großen Warteschlangen und somit hohen Verzögerungskosten einher. Dass ein schneller Fluss auf der gesamten Kette lokale Ineffizienzen bedingt, ist spätestens seit dem Erfolg des Toyota-Produktionssystem klar. Dennoch hat diese Erkenntnis noch nicht Einzug in alle Produktionen und schon gar nicht in die Entwicklungsorganisation gehalten.

Auch die Warteschlangenformel bestätigt uns: 100 % Effizienz/Auslastung entspricht einer unendlichen Lieferzeit. In der Praxis behelfen wir uns einfach damit, ständig Aufgaben umzupriorisieren (und damit alle Vorhaben gleich langsam fertig zu stellen). Um einen wirklichen Fluss in der Produktentwicklung zu erreichen und die Liegezeiten zu minimieren, muss die Auslastung deutlich nach unten gefahren werden. Als Richtwert gilt hier eine Zielgröße von 80% bis 85%. Eine solche Vorgabe ist jedoch nach meiner Erfahrung in der Praxis politisch nicht durchsetzbar, da die Organisationen lediglich ein Gefühl für die Kosten der Kapazität entwickelt haben (welche natürlich bei geringer Auslastung steigen), nicht jedoch für die Kosten von Verzögerungen.

Übrigens: In Workshops zur Bestimmung von solchen Verzögerungskosten kommen regelmäßig Werte zwischen 10.000€ und 100.000 € pro Tag(!) an die Oberfläche. Die sind sehr hohe Werte, mit denen der Regel niemand rechnet. Nur unter Kenntnis dieser Kosten kann jedoch in der Produktentwicklung die betriebswirtschaftlich optimale Auslastung bestimmt werden und die liegt nur selten über 90%.

4. Die Ablehnung von Variabilität

Wer in der Produktion oder der Betriebswirtschaft sozialisiert wurde, strebt danach Variabilität zu minimieren und Dinge planbar zu machen. Die Natur der Produktentwicklung hält jedoch zwei unangenehme Wahrheiten bereit:

  1. Produktentwicklung, als innovatives Vorhaben, ist kaum planbar.
  2. Die Verringerung der Variabilität in der Produktentwicklung würde unsere Innovationskraft und damit unsere Wettbewerbsfähigkeit beschädigen.

Ist das wirklich wahr? Betrachten wir einmal die Wertschöpfung: Die Produktion betreibt Wertschöpfung, indem sie mit hoher Präzision und Qualität immer wieder das gleiche macht. Stelle ich ein Produkt her, habe ich Wert geschaffen. Stelle ich dasselbe Produkt noch einmal her, habe ich wieder Wert geschaffen. Cool. Entwickle ich ein Produkt, habe ich Wert geschaffen. Entwickle ich das gleiche Produkt noch einmal, habe ich keinen Wert geschaffen. Die Produktentwicklung lebt also davon, bei jedem Vorhaben etwas komplett Neues, noch nie Dagewesenes zu machen. Wie soll sich so etwas präzise planen lassen? Natürlich können wir auch Kundenwünsche bedienen, indem wir bestehende Technologien neu zusammensetzen oder bestehende Produkte anpassen. Dies ist jedoch aus meiner Sicht eher der Bereich der „Applikation“ und nicht der Kern der Produktentwicklung, die unser Überleben in der Zukunft sichert.

Die oft bekämpfte Variabilität erhöht nicht nur die Kosten sondern generiert uns auch Chancen für Innovation. Sie ist also auch nur eine Stellvertreter-Messgröße für unser eigentliches Ziel: die Optimierung des Gewinns mit dem Produkt. Wie bei allen Optimierungen im Lean-Bereich ist auch diese eine U-Kurven-Optimierung also die Abwägung von zwei oder mehr Parametern. Es gibt demnach einen Punkt der optimalen Variabilität, an dem die Differenz zwischen den durch die Variabilität erzeugten Kosten und Chancen maximal ist. Vermutlich wird es uns nie gelingen, dies wirklich in Euros oder Dollars auszudrücken, aber eines sollte aus meinen Ausführungen klar sein: Null Variabilität bedeutet null Gewinn.

5. Die Verehrung von Planeinhaltung

„Planeinhaltung“ begegnet mir immer wieder als zu optimierende Metrik. Müssten wir dazu nicht parallel messen, ob der Plan auch im wirtschaftlichen Optimum entspricht? Und auch wenn der Plan das gestern getan hat, tut er es heute immer noch? So langsam kannst Du das Muster in der Argumentation von Donald Reinertsen erkennen: wenn ich vom Plan abgewichen bin, was verursacht mehr Kosten: mit der Abweichung weiterzuleben oder die Abweichung zu korrigieren? Was ist das wirtschaftliche Optimum für mein Vorhaben?

In diesen Punkt spielt auch die Tradition hinein, Produktentwicklung in Projekten zu organisieren. Doch wie soll ich einen Plan, also ein Budget einen Umfang und einen Zeitraum für etwas festlegen, das ich noch nie im Leben gemacht habe? Und wenn ich, wie üblich, mit verschiedenen Annahmen in mein Projekt gestartet bin, wie kann ich Umfang und Zeitplan und Budget des Projekts mitten im Projekt ändern, wenn ich damit eine Chance seitens Markt oder Technologie ergreifen kann? Wurde nicht schon vor zwei Jahren vom Vorstand beschlossen wie viele Entwickler ich für welchen Zeitraum bekomme? Der wirklich innovativ sein will und Druck im Markt erzeugen will, muss sich von Projektdenken und langfristigen Plänen verabschieden, also agil sein. Damit beziehe ich mich an dieser Stelle aber auf das Grundverständnis von Produktentwicklung, Innovation und Markt und nicht auf die Einführung von Scrum.

6. Das Verankern von großen Losgrößen

Nur wenige Entwickler und Führungskräfte machen sich Gedanken über Losgrößen in der Entwicklung. Für viele sind Losgrößen nur einen Thema der Produktion, dabei drängt uns unsere Sozialisierung zu einer gesteigerten (gefühlten) Effizienz, was in vielen Lebensbereichen zum Arbeiten mit großen Losgrößen führt. Beispiele für Lose in der Entwicklung sind zum Beispiel:

  • Wie viele Zeichnungen nehmen wir in unser Review Meeting?
  • Wie viele Fragen möchten wir mit einem Versuch oder Experiment beantworten?
  • Wie viele Anforderungen bauen wir in die nächste Version unseres Produkts ein?
  • Wie viele Anforderungen unseres Produkts testen wir im nächsten Testlauf?

In der Produktion gibt es eine wirtschaftlich optimale Losgröße. Zu große Lose erzeugen zu hohe Bestandskosten, weil zu viel Rohmaterial und halbfertige Erzeugnisse im Umlauf sind, ohne Umsatz zu generieren. Zu kleine Losgrößen lassen die ungeliebten Rüstkosten überproportional in den Stückpreis einfließen. Dasselbe Prinzip gilt auch in der Entwicklung: Zu große Losgrößen erzeugen hohe Verzögerungskosten, weil Zeichnungen, Aufgaben, Produkte usw. herumliegen, ohne das an ihn weitergearbeitet wird oder das in der Entwicklung wichtige Feedback erzeugt wird. Kleine Losgrößen der Entwicklung legen hingegen die Transaktionskosten (Kosten für Aufbau, Test, Meeting usw.) ungünstig auf die einzelnen Elemente um. Ziel muss also auch in der Produktentwicklung sein, Tätigkeiten in einer wirtschaftlich optimalen Losgröße durchzuführen.

Lean Development und agile Ansätze gehen zum Beispiel solch einen Weg. Die weitverbreiteten phasengetriebenen Prozesse arbeiten hingegen mit der maximal möglichen Losgröße: Zuerst wird alles definiert, dann alles konzipiert, dann alles aufgebaut, dann alles getestet. Unabhängig davon, bei welchen Zahlenwerten die Verzögerungs- und Transaktionskosten für bestimmte Tätigkeiten in der Produktentwicklung liegen: Ein solcher, mit der maximal Losgröße operierender, phasengetriebener Entwicklungsprozess ist aus wirtschaftlichen Gesichtspunkten so ziemlich das schlechteste, was man machen kann. Das ist kein Glaubenssatz, sondern ein Ergebnis der Mathematik hinter der Produktentwicklung.

7. Das mangelnde Ausnutzen von Kadenzen

Das Arbeiten in festen Takten, sogenannten Kadenzen, ist für die meisten Entwicklungsorganisation fremd. Üblich ist die Vorgehensweise, einen bestimmten Arbeitsumfang zu planen und die auftretende Variabilität durch Terminverschiebungen auszugleichen. Dies bringt jedoch unnötig Komplexität und Variabilität in das Entwicklungsvorhaben, da sich Synchronisationspunkte mit Stakeholdern und Feedbackschleifen ständig verschieben. Das Arbeiten in festen Takten schafft hingegen feste Synchronisationspunkte ohne jeglichen Planung-und Koordinierungsaufwand. Der immer auftretenden Variabilität wird hier durch eine Anpassung des Arbeitsumfangs begegnet, die Termine bleiben unverändert. Getaktetes Arbeiten mit kleinen Losgrößen erzeugt einen stetigen Fluss durch die Organisation und verbessert automatisch die Planungsgenauigkeit: bei der Arbeit in festen Takten lernt die Organisation viel schneller, was in einem Takt möglich ist, als bei klassischen Planungs-Ansätzen in denen der Umfang den Zeitraum vorgibt und jedes Mal andere Zeithorizonte im Spiel ist.

In der Produktentwicklung haben Kadenzen noch einen weiteren wichtigen Aspekt: nur ein regelmäßiger Aufbau und Test des Produkts während des Enticklungsvorhabens ergibt eine klare Messung über den Fortschritt. Der traditionelle Ansatz, ganz lange zu denken und erst zum Schulß etwas zu bauen, erhöht Risiko und Variabilität unnötig und führt regelmäßig zu Eskalationen und Task-Forces. Systemintegrationen in ein einer bestimmten Kadenz durchzuführen schaffte regelmäßig Feedbackschelifen über Technologie und Anforderungen und führt trotz Schleifen schneller zum Ziel.

8. Das Managen von Zeitleisten anstatt von Warteschlangen

Historisch bedingt versuchen Organisationen Tätigkeiten zu organisieren, indem sie diese auf der Zeitachse terminieren. Dass dies in der Entwicklung nur sehr eingeschränkt funktioniert, kennt jeder der schon einmal mit den typischen Gantt-Charts agiert hat. Grund dafür ist nicht eine fehlerhafte Planung oder eine schlechte Umsetzung, sondern die der Produktentwicklung zwangsläufig innewohnende Variabilität. Der typische Reflex gegen aus dem Ruder laufende Zeitpläne ist eine noch detailliertere Planung, welche das Vorhaben noch schwieriger handhabbar macht.

Weil wir Planeinhaltung fordern, zwingen wir die Menschen dazu unsichtbare Puffer in den Plan einzubauen. Schon in den 1980er Jahren hat das Critical Chain Project Management (CCPM) gezeigt, dass sich die Planeinhaltung bei Projekten deutlich und nachhaltig verbessern lässt, wenn man nur die Sequenz der Tätigkeiten definiert und nicht deren Start- und Endpunkt auf der Zeitleiste festnagelt. Das zollt der Variabilität Tribut („es braucht eben so lange es braucht“) und verhindert unsichtbare Puffer. Durchgesetzt haben sich solch zuverlässigen Ansätze nicht, zu groß ist das Verlangen Arbeitspakete im Kalender zu verwalten. Das Management von Zeitachsen rührt mitunter auch daher, dass Mitarbeiter in zu vielen Projekten gleichzeitig verpflichtet sind, zusammen mit der Annahme dass sich die Verteilung der Arbeitszeiten über die Projekte hinweg irgendwie zentral verwalten ließe.

9. Das Fehlen von WIP-Limitierungen

Die Limitierung von WIP (Work in Process, Menge der gleichzeitigen Arbeit) ist ein sehr mächtiges Werkzeug zur Prozessverbesserung, wenn nicht das mächtigste. Auch wenn ich in der Praxis immer das Gegenteil beobachte: Die Annahme, dass man möglichst viel bekommt, wenn man möglichst viel beginnt ist ebenso verbreitet, wie jene, dass ein früher Start ein frühes Ende bedeutet. Beides führt dazu, dass alles gleichzeitig gemacht wird und alles (gefühlt) in der Unendlichkeit fertig wird.

Die Limitierung von WIP ist ein essentielles Lean-Instrument und wird in der Regel durch die Etablierung eines Pull-Systems umgesetzt. Die großen Vorteile einer WIP-Limitierung sind aus meiner Sicht:

  • Deutliche Senkung der Durchlaufzeiten (und damit Verringerung von COD)
  • Verringerung von Verschwendung durch Kontext-Wechsel
  • Erhöhung von Fokus und Motivation
  • Erhöhung der Transparenz zur Prozessverbesserung (Probleme beheben, anstatt daran vorbeizuarbeiten)

WIP-Limits können dabei auf verschiedenen Ebenen eingesetzt werden. Auf persönlicher Ebene oder auf Team- oder Organisationsebene. Klaus Leopold weist darauf hin, dass WIP immer auf der Ebene limitiert werden muss, auf der die Effekte der Limitierung sichtbar sein sollen. Willst Du also dass Dein Team schneller wird, limitiere die parallele Arbeit im Team. Willst Du die Time-to-Market Eurer Projekte nach unten bringen, limitiere die Anzahl der parallelen Projekte.

Eine Möglichkeit, die gesamte Entwicklungsorganisation zu verbessern ist ein Lean-Portfolio-Management einzuführen, durch welches die Anzahl der gleichzeitigen Projekte begrenzt wird und neue Projekte im Pull-System über verschiedene Reifegrade in die Entwicklung „gesaugt“ werden. Eine sequentielle Abarbeitung von Projekten hat zwei große Vorteile:

  1. Deutliche Verringerung von COD: die ersten Projekte generieren deutlich früher Wert, die zurückgestellten Projekte werden auch nicht später fertig als im Modus mit hohem WIP.
  2. Vorteile des späten Starts: Wenn ein Projekt aufgrund der WIP-Limitierung später startet und kürzer läuft, werden deutlich weniger Änderungen in das laufende Projekt einwirken. Viele Änderungen werden vor dem Projektstart eintreffen und verursachen so deutlich weniger Verschwendung.

Doch die Mathematik und die Erfahrung aus der Produktion scheinen noch nicht in allen Entwicklungsorganisationen angekommen zu sein: Zu oft ist „alles und jetzt“ angesagt, ebenso wie das dadurch verursachte Ergebnis des Stillstands.

10. Der Mangel an Flexibilität

Das angesprochene Streben nach Effizienz führt auch zu einer lokalen Optimierung hinsichtlich der verfügbaren Expertisen. Viele mir bekannte Organisationen haben die letzten Jahrzehnte eine ausgeprägte Expertenkultur entwickelt: Ein Experte soll eine möglichst tiefe und schmalbandige Expertise besitzen und wird dann möglichst hoch ausgelastet. Ein zweiter Experte mit dieser Expertise wird nicht immer vorgesehen. Das sollte eigentlich schon aus Sicht des Risiko-Managements ein No-Go sein, begegnet mir jedoch relativ häufig. Übertrieben gesagt: Es gibt einen Experten für eine M5-Schraube und einen für eine M6-Schraube und diese können auf keinen Fall gegenseitig füreinander einspringen, denn es sind komplett unterschiedliche Technologien im Spiel. Begünstigt wird dies durch eine zu hohe Auslastung der Entwicklungsorganisation, welche die Experten dazu zwingt, alle Anfragen außerhalb ihrer Kernkompetenz abzulehnen.

Durch ein solches Setting ergibt sich ein Netzwerk von Experten, wobei jeder Experte eine lange Warteschlange vor sich hat. Wertstromanalysen in der Produktentwicklung ergeben oft Liegezeit-Anteile von deutlich über 90%. Hohe Auslastung, in Verbindung mit Expertenkulturen, macht Produktentwicklung zu einem „Warten auf Experten“ und „Warten auf Prüfstände“. Pull-Systeme und teambasierte Ansätze schaffen den Freiraum in dem Experten ihre Expertise verbreitern können und die Organisation flexibler werden kann. In der Regel stehen einem solchen Umdenken nicht die Befürchtungen der Experten entgegen, sondern ein fehlendes Verständnis der Organisation: Trainings und paarweises Arbeiten zur Verbreiterung der Expertisen erscheinen der Organisation als reine Kostenposition, denn es gibt ja schon die Experten.

Flexibilität bedeutet, Tätigkeiten auch dann anzugehen, wenn jemand anderes dies schneller machen könnte aber gerade keine Zeit hat. Auch hier wieder eine Zuspitzung von meiner Seite: „Ich könnte diese Aufgabe sofort beginnen und in 8 Stunden erledigen, doch unser Experte Karl würde dafür nur 4 Stunden benötigen. Karl hat schon in vier Wochen Zeit dafür, also lassen wir die Aufgabe so lange liegen.“ Die Zeitnachweise in der Organisation würden in einem solchen Fall einen Vorteil von 4 Stunden, also von ein paar hundert Euro ausweisen. Das ist das Ergebnis, das im Controlling ankommt. Würde die Organisation jedoch Verzögerungskosten berechnen, so könnte diesem Vorteil ein reduzierter Gewinn von mehreren hunderttausend Euro gegenüberstehen.

Der größte Hinderungsgrund um WIP-Limits einzuführen ist aus meiner Sicht die daraus entstehende Notwendigkeit Projekte durch das Top-Management zu priorisieren und die Entscheidung zu treffen, bestimmte Projekte erst später zu beginnen. Nur wenige Organisationskulturen ermutigen Führungskräfte solche Entscheidungen zu treffen, trotz aller Argumente und Nachweise über die Vorteile die daraus resultieren würden.

11. Das nichtwirtschaftliche Management des Flusses durch die Entwicklung

Die im vorigen Abschnitt von mir angesprochene notwendige Priorisierung sollte natürlich ebenso wie alle anderen hier erwähnten Aspekte nach betriebswirtschaftlichen Gesichtspunkten optimiert sein. „First In First Out“ (FIFO) ist hierfür ein kaum geeigneter Ansatz. Verzögerungskosten (COD) sind ein maßgeblicher Faktor bei der Bestimmung von Prioritäten in der Produktentwicklung. Beispielhaft möchte ich hier das Priorisierungsverfahren WSJF (Weighted Shortest Job First) beschreiben: Haben zwei Projekte/Aufgaben dieselbe Bearbeitungszeit, aber verschiedene COD, so sollte natürlich der Job mit den höheren Verzögerungskosten zuerst erledigt werden. Haben zwei Projekte/Aufgaben dieselben COD, aber verschiedene Bearbeitungszeiten, so sollte der Job mit der kürzeren Bearbeitungszeit zuerst erledigt werden. Da diese beiden direkt vergleichbaren Fälle in der Praxis nicht auftreten, wird COD mit der Dauer normiert. Dadurch ergibt sich ein Priorisierungsindex, mit dem die Projekte/Aufgaben priorisiert werden können. Kleine, wertvolle Projekte/Aufgaben werden also zuerst bearbeitet, große Aufgaben/Projekte eher später oder nicht. Das „erzieht“ die Organisation auch dazu in kleineren Losen zu arbeiten und somit den Fluss hinsichtlich Geschwindigkeit und Gewinn zu optimieren.

WSJF ist nur ein Beispiel, es geht darum bei allen Entscheidungen, also auch bei der Priorisierung dieselbe Währung anzulegen, also Auswirkung auf den Gewinn. Vielleicht ist eine andere Priorisierung für Dich besser? Vermutlich wird die Ermittlung von COD aber ein Bestandteil davon sein.

12. Zentrales Management

Zentrales Management ist per Definition langsamer als dezentrales Management, denn zentrales Management unterliegt auch der Warteschlangen-Mathematik: Es stauen sich Themen, die zu entscheiden sind. Hinzu kommt eine weitere Dimension: Zu vielen marktrelevanten Themen hat eine zentrale Entscheidungsinstanz nicht die benötigten Informationen, die „Peripherie“, wie Gerhard Wohland sie nennt, hingegen schon. Die Vorteile von dezentraler Entscheidung liegen auf der Hand – weiter unten, bei den Literaturtipps, gibt es auch mehr (Lese-)Futter dazu. Dennoch behält ein zentrales Management für manche Arten von Entscheidungen seine Berechtigung. Donald Reinertsen benennt beispielhaft folgende Szenarien, die weiterhin zentral entschieden werden sollten:

  • seltene Entscheidungen wie zum Beispiel Markt-oder Produktstrategien
  • Entscheidungen, die langfristige Auswirkungen haben zum Beispiel Technologien oder Plattformen
  • Entscheidungen die große wirtschaftliche Auswirkungen haben, zum Beispiel Standardisierung oder Werkzeuge

Und nun?

Mit dem Impuls von Donald Reinertsen habe ich nun zwölf Punkte vorgestellt, welche die Ursache oft beobachteter Probleme in der Produktentwicklung sind. Vermutlich hast du das Verhalten deiner Organisation in manchen Punkten, oder sogar in allen, wiedererkannt. Doch wie könntest du diese zwölf Punkte lösen?

Zunächst geht es darum, ein tieferes Verständnis für die oben dargelegten Argumentationslinien und Zusammenhänge zu bekommen, auch hier möchte ich dich auf die Literaturtipps weiter unten verweisen. Mit diesem Verständnis kannst Du dann beginnen, einzelne Aspekte in eurer Management-Kultur zu adressieren.

Dann geht es darum, die Punkte mit den größten Hebeln zu identifizieren und auch COD zu bestimmen. Dabei ist zunächst eine grobe Schätzung ausreichend, denn COD belastbar zu bestimmen ist nicht einfach. Aber wenn Du mit einer Schätzung nur die richtige Zehnerpotenz triffst, ist das schon ein Quantensprung gegenüber der bisherigen Entscheidungsgrundlagen ohne COD. Viele Punkte werden großen Widerspruch erfahren. Mathematik hin oder her, die tradierten Muster sind oft stärker. Die Forderung die Hälfte der Entwicklungsprojekte auf Eis zu legen und erst die anderen 50% schnell fertig zu machen wird alles andere als Begeisterungsstürme hervorrufen. Und solange die Mitbewerber ebenfalls in den alten Mustern verhaftet bleiben, droht ja keine unmittelbare Gefahr. ;)

Besonders interessant finde ich es, mit Donalds Brille einmal, einen Blick auf agile Ansätze, wie Scrum oder Kanban in der Produktentwicklung zu werfen. Du wirst erkennen, dass diese Ansätze viele, oder gar alle, der oben aufgeführten zwölf Probleme adressieren. Weiter unten habe ich meine Gedanken dazu aufgeschrieben.

Ich hoffe, diese Ausführungen über das Wesen der Produktentwicklung haben Dir dabei geholfen die Vorgänge und Einstellungen in einer Organisation besser verstehen zu können. Falls Du weitere Fragen dazu hast kontaktiere mich gerne per E-Mail.

Literaturtipps

Dave Gray, Thomas Vander Wal: „The Connected Company”, 2014

Klaus Leopold: „Agilität neu denken“, 2018

Dantar Oosterwal: „The Lean Machine“, 2010

Donald Reinertsen: „The Principles of Product Development Flow“, 2009

Allan Ward, Durward Sobek: „Lean Product and Process Development“, 2014

Gerhard Wohland, Matthias Wiemeyer: „Denkwerkzeuge der Höchstleister“, 2012

Das Scrum-Pflaster

Wie könnten agile Ansätze dazu beitragen, die 12 von Reinertsen angesprochenen Probleme zu beheben? Exemplarisch möchte ich dies hier in Form von ein paar ausformulierten Gedanken am Beispiel von Scrum darstellen:

  1. Scrum berechnet zwar nicht explizit Verzögerungskosten oder andere betriebswirtschaftliche Zusammenhänge, gibt jedoch alle wirtschaftliche Entscheidungsmacht in eine Rolle, den Product Owner. Nach der Definition steht dieser mit seiner Entscheidungsbefugnis als „Mini CEO“ neben der eigentlichen Organisation, bei ihm laufen Chancen und Risiken für das Vorhaben zusammen. Ob anhand von Zahlen oder mit seinem Bauchgefühl, der Product Owner optimiert das Entwicklungsvorhaben und das Produkt in betriebswirtschaftlicher Hinsicht, wohingegen in klassischen Settings Zusammenhänge zwischen Chancen und Risiken oft in der fehlenden Kommunikation zwischen Silos und Verantwortlichkeiten untergehen.
  2. Scrum greift aktiv in das Entstehen von Warteschlangen ein. Das Product Backlog ist noch keine Warteschlange denn die Reihenfolge in diesem kann sich ständig ändern. Das Sprint Backlog hingegen ist eine Warteschlange mit einer definierten Abarbeitungsreihenfolge, die aber gemäß dem Scrum-Konzept nicht als „lebende Warteschlange“ existiert, sondern in jedem Sprint leergefahren wird.
  3. Scrum reguliert die Auslastung dadurch, dass das Entwicklungsteam den Füllungsgrad für einen Sprint selbst bestimmen kann. Aus der gemachten Erfahrung heraus wird das Team die Auslastung intuitiv so wählen, dass die Chancen für eine vollständige Abarbeitung in einem guten Verhältnis zum erzielten Fortschritt stehen.
  4. Scrum fängt die in der Produktentwicklung vorhandene Variabilität durch einen offenen Umgang mit dieser an zwei Stellen explizit ab: die gesamte Dynamik der Anforderungen landet im Product Backlog, welches sich jederzeit ändern kann. Mit dem Sprint Backlog wird hingegen eine beruhigte Zone für das Entwicklungsteam geschaffen damit dieses mit einem hohen Wirkungsgrad nach vorne gehen kann. Sollte die Variabilität innerhalb eines Sprints die vorgenommene Planung angreifen, wird dies ebenfalls akzeptiert und der Inhalt des Sprints entsprechend angepasst.
  5. Eine Planeinhaltung auf lange Sicht ist bei Scrum nicht wichtig, denn in einem dynamischen Umfeld ändert sich der Plan ohnehin von Sprint zu Sprint. Natürlich versucht das Entwicklungsteam mit einer möglichst realistischen Einschätzung den Sprint-Umfang festzulegen, tut dies aber nur auf einem überschaubaren Zeithorizont um im gesamten Vorhaben flexibel zu bleiben.
  6. Scrum arbeitet in relativ kleinen Losgrößen im Vergleich zu einem phasengetriebenen Prozess. In jedem Sprint wird ein kleines Los an Anforderungen abgearbeitet entwickelt und getestet. Dadurch sind die Liegezeiten für wertvolle Kundenfunktionen oder riskante technische Konzepte minimal.
  7. Eine konsequente Kadenz ist Bestandteil von Scrum: der Sprint. An diesem Takt wird festgehalten, die Variabilität in der Produktentwicklung beeinflusst den inhaltlichen Umfang des Sprints.
  8. Über Backlog-Konzepte wird nur die Sequenz von Anforderungen und Aufgaben definiert der Zeitpunkt der Abarbeitung ergibt sich aus natürlichen Geschwindigkeit des Entwicklungsteams und den in der Produktentwicklung natürlicherweise auftretenden Problemen. Durch das Konzept, wie Scrum getaktet mit den beiden Backlogs arbeitet, werden also Warteschlangen und keine Zeitpläne gemanagt.
  9. Scrum verfolgt sehr konsequent eine Limitierung der gleichzeitigen Arbeit (WIP). Zum einen wird die Menge der Arbeit pro Sprint durch das Pull-System limitiert, zum anderen lernt das Scrum Team schnell, dass die Sprints erfolgreicher verlaufen wenn die Aufgaben im Sprint sequenziell und nicht parallel bearbeitet werden.
  10. Scrum setzt auf crossfunktionale Teams um eine maximale Flexibilität in der Abarbeitung zu erreichen. Dabei spielt es keine Rolle, ob ein Teammitglied eine Aufgabe schnell oder langsam bearbeitet, wenn eine Aufgabe an der Reihe ist, wird diese bearbeitet. Dies minimiert die Liegezeiten die damit verbundenen Verzögerungskosten enorm. Das oft postulierte Ziel, dass in einem Scrum Team jedes Teammitglied jede Tätigkeit ausführen können sollte, ist nicht zielführend. Ziel ist es, mit sogenannten T-shaped Skill Sets die Expertise hochzuhalten und gleichzeitig die Flexibilität zu erhöhen. Erreicht wird dies in dem das gesamte Team die Verantwortung für alle Aufgaben trägt und diese nicht mehr bei einzelnen Personen liegt.
  11. Der Product Owner hat die Aufgabe die Wertschöpfung des Scrum Teams zu optimieren, was er durch eine optimale Sortierung der Product Backlog Items erreicht. Die für ihn wichtigen Größen sind dabei Kundenwert der Anforderung, Kundennutzen der Anforderung, Umsetzungsaufwand, und das Risiko in der Umsetzung.
  12. Ein Scrum Team agiert autark und ist nicht von zentralen Entscheidungen abhängig. So kann schnell auf den Markt bzw. auf den Kunden reagiert werden, die Liegezeiten für Entscheidungen werden minimiert, der Kundennutzen und der Gewinn des Vorhabens werden maximiert.

Ähnliche Beiträge

Scrum im V-Modell, V-Modell in Scrum

Brauchen wir noch Projekte?

Produktentwicklung: Lean & Agile

Mein verrückter Buch-Advent