Scrum in der Hardware: Agile Hochleistungsflugzeuge

Saab Gripen – by Peter Gronemann, CC BY 2.0


Der Nachbrenner röhrt und zeichnet die Spur der Hochtechnologiemaschine im Himmel nach. Mit neunfacher Erdbeschleunigung fliegt das Düsenflugzeug in einer engen Kurve über das Feld. Der Pilot spannt seine Oberschenkelmuskeln an und kämpft verbissen gegen die extrem hohen Kräfte, die ihn in den Sitz pressen. Er reißt das Kampfflugzeug plötzlich senkrecht nach oben, reduziert den Schub, rollt es mit einer leichten Handbewegung auf den Rücken und vollendet das Manöver mit einem halben Looping. Zufrieden lächelt er und bestätigt den Funkspruch aus dem Tower, der ihn zurück zur Landebahn lotst.
Was manchen bei Flugshows ein freudiges Lächeln ins Gesicht zaubert, würde bei einem Flug in den Urlaub maßlos verärgern oder verängstigen. Normale Passagiermaschinen sind auf Sicherheit und Treibstoffeffizienz ausgelegt, und das erfordert eine sogenannte „stabile Auslegung“. Das bedeutet, dass das Flugzeug zum Beispiel bei Windböen oder kurzen Ausschlägen der Steuerflächen von selbst wieder in die Ausgangslage zurückkehrt. Für militärische Hochleistungsflugzeuge ist es hingegen wichtig, schnell und wendig zu sein, damit sie ihre Missionen erfüllen können. Um im Luftkampf überlegen zu sein, werden moderne Modelle deshalb häufig instabil ausgelegt: eine kleine Böe genügt um die Maschine in Bruchteilen von Sekunden senkrecht nach oben auszulenken. Agilität ist für den Erfolg eines Hochleistungsflugzeugs ausschlaggebend. Aber auch dessen Entwicklung kann agil sein.

Agile Entwicklung anno 1943

Erste Anzeichen von agilen Methoden in der Luftfahrt findet man schon ab 1943 in den Lockheed Advanced Development Programs, den geheimnisumwitterten Skunk Works, der Entwicklungsabteilung für Geheimprojekte des Rüstungs- und Technologiekonzerns Lockheed. Innerhalb von 180 Tagen sollte das Projektteam eine Antwort auf die übermächtige Me-262 der Deutschen entwickeln. Deshalb stahl sich Kelly Johnson alle notwendigen Mitarbeiter – Techniker, Ingenieure, Piloten – zusammen und sammelte sie in einem Zelt. Sie konnten sich voll und ganz auf die Entwicklung ihres Flugzeugs, die P-80, konzentrieren und nutzten andere agile Methoden – auch, wenn sie es damals nicht so genannt hätten. Ihr Ziel konnten Sie tatsächlich schon nach 143 Tagen erreichen.
In jüngerer Zeit hat der schwedische Automobil- und Rüstungskonzern Saab mit seinem neuesten Flugzeugmodell, dem Gripen (Greif) E Multirole Fighter, ein neues Vorgehen für die in der Luftfahrt traditionell langen Entwicklungszyklen genutzt. Sie haben jedoch nicht nur die Software, sondern gleich das gesamte Flugzeug mit dem agilen Framework Scrum entwickelt. Bei Saab sind auf allen Ebenen und in jeder Domäne agile Methoden implementiert. Egal, ob Software, Hardware oder im Rumpf-Design: Saab nutzt unter anderem Praktiken aus Scrum, Kanban, XP und dem Lean Management. Das führt im Vergleich zu klassischen Luftfahrt-Entwicklungsprojekten zu zahlreichen Unterschieden in der Art, wie die Menschen zusammenarbeiten und Entscheidungen treffen.

Entschieden wird dort, wo die Information ist

Die Teams haben Klarheit über das Ziel, haben aber gleichzeitig die Freiheit, eigene Innovationslösungen zu schaffen. Sie haben die Freiheit, die beste Implementierung für ihren jeweiligen lokalen Kontext zu wählen und weiterzuentwickeln. Dadurch ergeben sich, je nach Team, auch Unterschiede im Reifegrad ihrer Agilität. Sie werden prozessual und technisch weitestgehend ermächtigt und auch Entscheidungen werden so weit wie möglich auf der Teamebene gefällt. Das setzt voraus, dass die technische Verantwortung ebenfalls dort liegen muss. Der Fokus von Saab auf autonome Teams reduziert die Bürokratie und ermutigt die Entscheidungsfindung auf der niedrigstmöglichen Ebene in der Projektorganisation. Dafür können Entscheidungsregeln genutzt werden, um ökonomische Fragen möglichst dezentral zu beantworten.
Ein Beispiel aus der Entwicklung der B-777 bei Boeing liefert Donald Reinertsen in seinem Buch „The Principles of Product Development Flow“. Der Product Owner arbeitet mit allen Stakeholdern auf den verschiedenen Managementebenen zusammen. Er ist verantwortlich für die Ermittlung des Wertes von Features und priorisiert sie in regelmäßigen Abständen neu. Die herausfordernde Aufgabe des Product Owners ist es, als Schnittstelle zwischen den oberen Managementfunktionen und der Teamebene zu fungieren, da ein so großes Projekt sehr viel Koordination benötigt. Es ist wichtig, dass zum Zeitpunkt der Sprint-Planung der Teams, zu Beginn jedes Sprints, der Backlog bereit ist und vom Team bearbeitet werden kann. Dem Team ist klar, was geliefert werden muss, welche Abhängigkeiten vorhanden sind, und kann den Sprint mit gutem Gewissen beginnen. Die Product Owner der einzelnen Teams sind dafür verantwortlich zu klären, was die internen Kunden wollen und kommunizieren diese Erkenntnisse in die Teams. Gleichzeitig schaffen sie Klarheit in Phasen, die von Rauschen und anderen Störungen gekennzeichnet sind, damit den Teams klar ist, was getan werden muss. Dafür ist die Visualisierung der Backlogs, Pläne und Abhängigkeiten ein wichtiges Kommunikationsinstrument zwischen den Product Ownern. Allerdings müssen strategische Pläne als lebende Dokumente gesehen werden, die aufgrund von Feedback ständig angepasst werden.

Systematische und regelmäßige Integration als Erfolgsfaktor

In einem Projekt, das so groß und komplex ist wie die Entwicklung eines Hochleistungsflugzeugs, benötigt man regelmäßige Treffen mit dem Fokus auf den Integrationsproblemen. Die ständige Prüfung und Verbesserung der Kommunikation ist entscheidend für die Entstehung von Klarheit in der gesamten Organisation. Dafür haben die Teams einen gemeinsamen Rhythmus und einen stabilen Puls. Die Sprints dauern drei Wochen und beginnen und enden am selben Tag. Saab erkannte auch die Notwendigkeit der Synchronisation über einzelne Sprints hinaus und entwickelte eine Methode für Iterationen in vierteljährlichen Zyklen, den Development Step (Entwicklungsschritt). Das ist ein klar definiertes Funktionsziel für eine größere Freigabe, typischerweise für ein bestimmtes Versuchsflugzeug. Ein Entwicklungsschritt ist wiederum in mehrere Inkremente mit kleineren, besser handhabbaren Funktions- und Produktlieferungen unterteilt. Das Inkrement hat eine Timebox von drei Monaten, was zu einer Taktung von vier Drei-Wochen-Sprints führt.
Innerhalb dieser Timeboxen gibt es ein strukturiertes System von Meetings, um Abhängigkeiten auf Teamebene zu identifizieren und sie über das Projekt sichtbar zu machen. So hat Saab Retrospektiven entwickelt, die nicht nur die Teamperspektive umfassen, sondern auch teamübergreifend stattfinden, um größere Themen zu besprechen. Jeder Development Step schließt mit einem Release ab. Aber auch schon während der quartalsweisen Inkremente werden kleinere Versionen veröffentlicht, um häufiges Feedback zur Produktintegration und -gestaltung sicherzustellen. Die meisten Probleme, die bei einer großen Produktentwicklung auftreten, treten dabei während der Integration verschiedener Module auf. Durch Zyklen der Integrationstests, die sogar kürzer als ein einziger Sprint sein können, ist Saab in der Lage, diese Probleme frühzeitig sichtbar zu machen und schnell Korrekturmaßnahmen zu ergreifen. Durch das kontinuierliche Zusammenspiel von Praxis- und Lernerfahrung werden Meilensteine im Laufe der Zeit detaillierter und weniger anfällig für Veränderungen, sobald sie den richtigen Development Step erreichen und umgesetzt werden.

Modulare Architektur und konsequentes Sammeln von Feedback

Schon zu Beginn des Gripen E-Programms war eine modulare Architektur und damit Flexibilität für zukünftige Updates ein wichtiger Schwerpunkt. Nach dem Gesetz von Conway ermöglicht Modularität des Designs auch eine Modularität der Organisation – und damit mehr Geschwindigkeit durch entkoppelte Entwicklungsteams. Saab konzentriert sich dafür auch auf den Aufbau hochmoderner Simulatoren. Diese erlauben kurze Rückkopplungszyklen und damit schnelleres Feedback. Die Teams können zum Beispiel sofort Designentscheidungen in Desktop-Simulatoren überprüfen. Um Feedbackzyklen noch weiter zu verkürzen, stationiert Saab die Testpiloten und Entwicklungsteams auf dem gleichen Gelände in Linkoping in Südschweden. Dies ermöglicht eine enge Interaktion zwischen den Entwicklungsteams und den Piloten, und Feedback wird in jedem Sprint zur Verfügung gestellt. Die Validierung erfolgt auch mit den Piloten der Kunden. Durch agile Praktiken kann Saab Variabilität effektiv managen und die Leistung mit Klarheit und Engagement steigern. Das Ergebnis ist ein Flugzeug, das schneller, mit niedrigeren Kosten und höherer Qualität entwickelt werden konnte.
Dieser Artikel basiert auf einem Erfahrungsbericht von Scrum Inc. bei Saab.
Furuhjelm, Jörgen; Segertoft, Johan; Justice, Joe; Sutherland, Jeff: Owning the Sky with Agile Building a Jet Fighter Faster, Cheaper, Better with Scrum.
 

Scrum ist KANBAN – aber spielt das eine Rolle?

In den letzten Wochen, haben wir uns viel mit den Ideen zu Second Generation Lean Product Development von Don Reinertsen beschäftigt. Seine Ideen sind u.a. die Grundlage, um KANBAN, die von David Anderson ins Leben gerufene Methode, die sich derzeit als Gegenentwurf zu Scrum verkaufen lässt, zu verstehen. Nachdem wir uns intensiv mit den Gedanken von Don Reinertsen auseinandergesetzt hatten und ich im letzten Jahr das Seminar von Anderson besucht hatte, war mir immer weniger klar, wieso Leute der Meinung sind, dass Scrum und KANBAN etwas Unterschiedliches seien. Klar – es gibt ein paar unterschiedliche Best-Practices, aber spätestens, wenn man die Kadenzen in KANBAN-Teams einführt oder auf einem Scrumboard ein zweite Zeile, in der man zwei Projekte voneinander trennt, einführt (Swim-Lanes), heben sich die Unterschiede schnell auf.
 
Wieso also diese Unterschiedlichkeit und der teilweise heftig geführte Schlagabtausch, ob nun “Scrum revolutionär” und “KANBAN evolutionär” sei (David Anderson) und wieso war ich selbst anfangs so sehr von KANBAN enttäuscht? Denn ich hatte in KANBAN, mit Ausnahme der Idee der besseren Metriken und der Möglichkeit, nun erklären zu können, wieso Scrum funktioniert, nichts Neues gesehen. Und ich hatte den Nachteil gesehen, dass KANBAN Teams die Möglichkeit lässt, den Wasserfall als Verhinderer von Agilität im Team zu belassen.

Zwei Seiten des U

Unser Teammitglied Sven Winkler, der u.a. die Agile User Group Nürnberg (Agile Monday) mit veranstaltet, hatte dann eine Eingebung: Nachdem er von der Theorie U gehört hatte, einem Themenschwerpunkt in unserer ScrumMaster Pro Ausbildung, zog er den Vergleich, dass KANBAN auf dem linken Ast liegt und Scrum auf dem rechten. Heureka!
 
Na klar! KANBANs Stärke liegt darin  die Arbeit und die Bottlenecks aufzuzeigen. Bevor diese Probleme nicht klar und deutlich vor Augen liegen, verändert man erst einmal nichts. KANBAN beginnt mit der Aufnahme des existierenden Prozesses, zeigt die Value Chain auf und zeigt dann die Bottlenecks. Dadurch entsteht so etwas wie ein Bewusstsein über die Verhältnisse und es werden keinerlei Veränderungen von einem Team verlangt. Erst wenn es selbst merkt, dass ein Prozessschritt nicht weitergeht, dann wird gehandelt. Dann führt man ein Work in Progress Limit ein, dann die Kadenzen und schließlich noch die Retrospektiven.
 
Demgegenüber liegt auf der rechten Seite des Us: die Lösung, die Synthese und die Epiphanie. Scrum geht von der Tatsache aus, zu wissen, welcher Prozess (nämlich der Deming Cycle) zur kontinuierlichen Verbesserung führt und macht von Anfang an klar, dass es gewisse Verantwortungen zu erfüllen gibt. Ausgehend von einem in den 1980ern wissenschaftlich evaluierten und durch Case Studies abgesicherten Bild, wie das Management von Produkten laufen sollten, hatte sich ja eine Methode etabliert, die genau wusste, wie es geht und was es braucht, damit Teams hyper-erfolgreich werden können.
Scrum nutzt Aspekte aus, die selbstverständlich auch klar werden, wenn man lange genug KANBAN macht. Don Reinertsen erwähnte übrigens in unserem Seminar, dass Scrum im Grunde Second Generation Lean Product Development ist.
 
Scrum liefert quasi bereits die Lösung:
Teamzentriertheit, Sichtbarkeit, Best Practises wie z.B. das Taskboard, Kadenzen, regelmäßige Meetings und Lieferungen, Work in Progress Limits on the fly = WIP/pro Sprint = Commitment und ein Backlog.
 
Also die Idee, in Lieferungen anstatt in Aufgaben zu denken.
 

Scrum führt zu Widerstand

Aber, all das liegt auf der Lösungsseite und nicht wie KANBAN auf der Analyseseite. Nimmt man nun das SCARF-Modell von David Rock (Brain@Work), wird sofort klar, wieso Scrum bei vielen Teams und Managern zu Widerstand führt, während KANBAN sich leichter integrieren lässt und anpasst:
 

  1. Scrum Evangelisten gehen zu Teams und sagen: “Ihr müsst anders arbeiten.” Das führt zu Widerstand, weil man das Team in seinem Status herabsetzt.
  2. Scrum Evangelisten sagen oft: “Ihr seid das Team! Findet heraus, wie ihr arbeiten wollt.” Das führt zu Unsicherheiten beim Team. KANBAN sagt: “Ändert mal nichts. Wir wertschätzen, was ihr bis jetzt gemacht habt. Findet dann SELBST heraus, was ihr ändern wollt.”
  3. Damit haben sie das Prinzip der Autonomy besser als Scrum Evangelisten geachtet. Denn wieder überlässt man es dem Team zu entscheiden, was zu tun ist.
  4. David Rock behauptet weiter, dass Verbundenheit für Menschen wichtig ist. Mit Scrum stellt man sich zunächst in die “wir sind anders und ihr müsst euch ändern”-Ecke. Das ist nicht gerade ein Thema der Verbundenheit. KANBAN macht auch hier wieder genau das Gegenteil: “Wir sind wie ihr. Wir fragen mal nach, welchen Prozess ihr habt.” (In der deutschen Organisationsentwicklungsszene nennt man das “Macht Betroffene zu Beteiligten”).
  5. Last but not least: Scrum Evangelisten verletzen das Thema Fairness. Sie zeigten auf, dass die Arbeitsprozesse, die bisher geleistet wurden, nicht gerade perfekt sind, und dass zum Beispiel Manager daran “schuld” sind. Menschen nehmen das nicht gerade gut auf, wenn sie so “vorgeführt” werden. Auch hier hat KANBAN, da es sich auf der linken Seite der U-Kurve befindet, noch keinen “Angriff” gestartet. Es sensibilisiert zunächst und durch den expliziten Satz “Die Betroffenen wissen immer am besten, wie man arbeitet”, macht KANBAN zunächst klar: Ihr seid ok!

 
Gerade für das mittlere Management, die Quelle der Veränderungsresistenz, ist auf den ersten Blick KANBAN zu Anfang die weniger gefährlichere Variante. Viele Consultants nutzen das. Sie machen die Tatsache, dass Scrum den Ruf hat, Dinge zu verändern zu ihrem Verkaufsargument, Indem sie sich gegen Scrum und nicht gegen den Wasserfall aufstellen. Also nicht mehr sagen, wir wollen das traditionelle Management verändern, sondern agile ohne Scrum werden. Sie nutzen eine rhetorisch sehr geschickte Variante der Überzeugung. Sie zeigen auf, dass es ein Schreckensszenario gibt: “Mit Scrum verändert man etwas, da ist auch nicht klar, was mit Ihnen als Manager wird. Bei Scrum, da verändert man zuerst die Rollen und deshalb muss das Management mitziehen.[1]
 
Jetzt werden einige sagen (meine Frau, der ich diese Zeilen vorgelesen habe, hat es sofort gesagt): “Er schreibt gerade gegen Scrum, also gegen das eigene Business.” Naja, auf den ersten Blick schon. Zumindest wissen jetzt die Leser, wie man KANBAN effektiv gegen Scrum pitcht. Aber eines muss ich an dieser Stelle einfach loswerden: Scrum ist auf der rechten Seite des Us. Scrum ist das Zielmindset: Jurgen Appelos Management 3.0 oder Gary Hamels Management 2.0 [https://www.phoenix.edu/lectures/gary-hamel/management-2.html] sind in Scrum bereits inkludiert. Scrum hat die Ideen von IDEO zur Produktentwicklung aufgenommen und heute reden wir von der Discovery-Phase. Die fundamental anders abläuft, als der damals von einigen eingeforderte Zero Sprint. Sie ist notwendig, weil wir heute verstanden haben, dass man mehr als ein Backlog braucht. Scrum hat aufgedeckt, dass wir in vielen Firmen fundamentale Kenntnis-Defizite haben. Das fängt bei den Entwicklern an, die nicht über agile Entwicklungspraktiken verfügen, geht bei Produktmanagern weiter, die nur Anforderungsmanager sind, und zeigt auf, dass das Management in den Unternehmen nicht damit klar kommt, Umgebungen herzustellen, die für Teams geeignet sind. Scrum hat gemeinsam mit den neuen Entwicklungsmethoden die Zukunft, die Vision aufgezeigt.
 
Don Reinertsens Second Generation Lean Product Development ist, so wie er es sowohl in seinem Buch, als auch in seinem Training darstellt, in KANBAN noch lange nicht aufgegangen. Er spricht davon, Ideen der deutschen Kriegsführung (der Auftragstaktik und des Maneuver Warfare (Bewegungskriegs)) in das Managen der Produktentwicklung aufzunehmen und die Ideen der US Marine Doctrine einzubauen, also: “Less Detailed Planning, Little Status Reporting, React to the Battle, Decentralized Control”, uvm. Damit erzeugt er ein Modell der agilen Organisation, wie wir es bereits von Peter Drucker und Tom Petersen kennen und wie es heute von Gary Hamel vertreten wird. Spannend zu sehen, dass wieder der Krieg der Vater aller Dinge ist: Scrum wurde von US Militär Alumnis entworfen, Second Generation Lean Product Development von einem Ex-Marineoffizier. Könnte es sein, dass Ideen aus Situationen, in denen es darum geht, schnell zu sein und Territorium zu gewinnen, genau die Rezepte an Bord haben, um neue Märkte und neue Produkte zu entwickeln? Es ging immer um das NEW NEW PRODUCT DEVELOPMENT GAME. Lasst uns gemeinsam Unternehmen erschaffen, in denen Menschen sich optimal entfalten können.
 

Second Generation Lean Product Development
Applying the Principles of Flow

am  10. und 11. September 2012 in München

—————
[1] Übrigens denke ich mir solche Argumentationsstrategien nicht aus. Auf der OOP 2011 kam tatsächlich ein Consultant auf mich zu und hat mir genau diese Argumentationskette als seinen Verkaufspitch erklärt. Damals war ich einfach nur betroffen. Ich dachte immer, wir in der agilen Community wollten zusammen den Wasserfall, das Management des 19. Jahrunderts “bekämpfen”. Die Idee, eine Methode, die erwiesenermaßen das Gute will, schlecht zu machen, nur um die eigene Methode zu verkaufen, war mir bis dahin vollkommen fremd. Klar hatte ich gegen KANBAN geschrieben, aber nur weil wir mit Scrum schon um vieles weiter waren als KANBAN. KANBAN war und ist für mich ein Rückschritt.

Wie kann man Selbstorganisation steuern?

Jeder Executive Manager hat das gleiche Problem: “Wie stelle ich sicher, dass meine Mitarbeiter die richtigen Dinge tun?” In kleinen Firmen, in denen der Eigentümer noch omnipräsent ist, wird das oft durch die Einzelentscheidung des Unternehmers geregelt. Aber wie macht man das in einem Großkonzern, zum Beispiel bei Boeing, wo 5000 Ingenieure am Dreamliner arbeiten? Wie stellt man als CEO einer brasilianischen Eisenbahn mit wenig Geld und einem maroden Schienennetz sicher, dass die richtigen Entscheidungen getroffen werden?
Schauen wir uns das aus zwei Perspektiven an: 1. Aus der Perspektive eines Change Managers und 2. aus der Sicht eines Ökonomen.

  1. Im wirklich lesenswerten Buch “Switch” erklären die Autoren Chip & Dan Heath,  dass wir – wollen wir Wandel bewirken – den Menschen helfen müssen, im Wandel die richtigen Entscheidungen zu treffen, indem wir klare Entscheidungsvorgaben machen. Am Beispiel der brasilianischen Eisenbahngesellschaft America Latina Logistica ALL erzählen sie, dass der CEO, Alexandre Behring, seinen Mitarbeitern ein klares Set an Regeln vorgab, anhand derer sie Entscheidungen zu fällen hatten:
    • Geld wird nur in Projekte investiert, die es ALL erlaubt kurzfristig Umsatz zu generieren.
    • Die beste Lösung ist die, die kurzfristig die geringsten Kosten verursacht, selbst wenn das auf lange Sicht teurer wird.
    • Problemlösungen, die schnell durchzuführen sind, sind jenen vorzuziehen, die besser sind, aber in der Umsetzung länger dauern.
    • Wiederverwendung oder Recycling ist besser als Neukauf.

Der Grund für seine Strategie war, dass er keine großen Barreserven hatte und mit dem auskommen musste, was er hatte. Und er musste dafür sorgen, dass die Menschen sich sofort bewegen können. Er musste ihnen Handlungsanweisungen geben, die von jedem sofort umsetzbar waren.
2. Don Reinertsen erzählt in seinem Buch “The Principles of Product Development Flow – Second Generation Lean Product Development” und in seinem Training, wie Boeing es geschafft hat, dass 5000 Ingenieure wussten, wie sie zu entscheiden hatten. Boeing hatte einen Vertrag mit einem seiner Kunden ausgehandelt: Würde die 777 schwerer werden als vertraglich vereinbart, würde Boeing für jedes Pfund mehr als vereinbart über die gesamte Lebensdauer des Flugzeugs 300 Dollar pro Monat an den Kunden als Vertragsstrafe zahlen müssen. Dieser finanzielle Rahmen erlaubte es nun jedem einzelnen Ingenieur, während der Arbeit am Flugzeug selbst über den Trade-off zwischen gewichtsmäßig unterschiedlichen Materialien zu entscheiden. Bis zu einem Preis von 300 Dollar mehr pro Pfund konnten Ingenieure Materialien einplanen, ohne dass sie jemanden anderen fragen mussten.
Also: Wenn wir wollen, dass Teams selbst Entscheidungen treffen, müssen wir ihnen Leitplanken für ihre Entscheidungen bauen.
Über dieses und andere Beispiele dafür, wie Unternehmen mit Scrum erfolgreicher sein können, könnt ihr mit Don Reinertsen persönlich diskutieren! Er hält für bor!sgloger wieder sein Training:

Second Generation Lean Product Development
Applying the Principles of Flow

am  10. und 11. September 2012 in München

 
Alle Informationen findet ihr hier.

Warum ist das Denken in Auslastung – blödsinnig!

Da geht man zu einem Seminar und denkt  “Was kann der einem schon erklären?” Und das Erste, was man lernt, ist dann Folgendes: Es gibt einen mathematischen Grund dafür, dass es unsinnig ist, ein Team zu 100% auszulasten. Don Reinertsen zeigt in seinem Seminar “Second Generation Lean Product Development. Applying the Principles of Flow” mit Hilfe einer einfachen mathematischen Formel auf, dass zu hohe Auslastungsquoten zu Unproduktiviät führen.

Wenn man jedoch eine Führungskraft fragt, ob er oder sie bereit ist, zu akzeptieren, dass ein Team nur zu 80% ausgelastet ist: Was wird wohl die Antwort sein? „Auf keinen Fall! Jeder soll vollkommen und am besten zu 100% ausgelastet sein.”
Tom DeMarco schrieb ein ganzes Buch darüber, um zu zeigen, dass diese Idee falsch ist. In “Slack” (deutsch für “Spielräume”) schreibt er, dass es notwendig ist, Spielräume einzubauen und Menschen nicht komplett auszulasten. Er hat Recht. Und sogar aus einer produktionstechnischen Sicht heraus, wie diese Grafik zeigt: Bis zu einer Auslastung von 80% liegt die durchschnittliche Anzahl an Aktivitäten, die warten müssen, unter 5 Aktivitäten. Bei über 90% Auslastung steigt die Anzahl der wartenden Aktivitäten sprunghaft an. Bei Auslastungen von nahe 100% wird die Anzahl der Dinge, die warten müssen, riesig.Eine Team-Auslastung von über 80% führt also zu einer sehr langen Aufgabenliste, die zu bearbeiten ist. Lange Aufgabenlisten erzeugen aber eine längere Durchlaufzeit für jede Aufgabe. Sie erhöhen das Risiko, dass man an etwas arbeitet, das bereits obsolet ist. Sie erzeugen höheren Veränderungsdruck, mehr Overhead, geringere Qualität und geringere Motivation. Wir kennen das alle: Wenn man eine lange Liste von Dingen zu tun hat, mag man gar nicht so richtig anfangen.
Also lasst uns endlich damit aufhören, Menschen zuzumuten, immer komplett ausgelastet sein zu müssen. Es ist einfach unproduktiv und macht keinen Sinn. Reduzierung der Arbeitsbelastung führt zu Effektivität. Komisch aber wahr.
Die nächste Chance auf Don Reinertsen live: 

Second Generation Lean Product Development
Applying the Principles of Flow

am  10. und 11. September 2012 in München