Management 3.0

Bild: Pixabay / Monfocus - CC0 1.0

Einer der kleineren, trotzdem aber immer erfolgreicher werdenden agilen Ansätze ist das so genannte Management 3.0. Was das ist und wo es herkommt wäre eine Geschichte für sich, an dieser Stelle soll es aber zuerst nur um den Namen gehen. Schon hinter ihm versteckt sich nämlich ein für das Verständnis des Frameworks zentraler Punkt. Er definiert nicht nur was Management 3.0 ist, sondern auch was es nicht ist.

Wie man sich denken kann ist es eine Differenzierung von anderen Management-Praktiken. Dabei setzt es sich zuerst ab von der "herkömmlichen" Art Menschen und Unternehmen zu führen. In diesem Kontext wird diese Management 1.0 genannt und ist geprägt durch Hierarchiedenken, Herrschaftswissen, Command & Control und ähnlichen problematischen Vorgehensweisen.

Warum diese Vorgehensweisen problematisch sind ist aus einer agilen Perspektive klar: Hierarchien verhindern, dass sich die ausführende Ebene verantwortlich fühlt (und benimmt), Herrschaftswissen hält die Mitarbeiter dumm und führt so zu unklugen Entscheidungen, Command und Control verlagert den Ziel des Arbeitens weg von der Sinnerfüllung und hin zur Vorgabenerfüllung. So weit, so bekannt.

Darüber hinaus wird davon ausgegangen, dass es noch eine zweite Art von Management Praktiken gibt, die zwar in ihren Zielen etwas weiter ist, diese aber mit den bisher üblichen Methoden umsetzen will und aus diesen Gründen zwangsläufig daran scheitert. Letztendlich ist er damit nur der bessere unter den schlechten Ansätzen. Für ihn gibt es den Namen Management 2.0.

In der Realität sieht er so aus, dass z.B. Selbstorganisation angestebt wird, die aber dadurch umgesetzt werden soll, dass die dazu (angeblich) nötigen Strukturen den Mitarbeitern ungefragt übergestülpt werden. Klassiker in diesem Bereich sind die von oben angeordneten Einführungen von SAFe oder (Pseudo-)Spotify, was meistens nichts anderes ist als die Ersetzung alter Hierarchien und Kommandostrukturen durch neue.

Auch der Versuch eine neue Unternehmenskultur von oben vorgegeben und zentral gesteuert einzuführen ist eine Ausprägung von Management 2.0. Alleine die Idee, dass man Kultur durch Anordnung verändern könnte ist ein Missverständnis. Wenn dann noch paternalistische Aspekte dazukommen ("die müssen zu ihrem Glück gezwungen werden", "die werden noch verstehen warum das gut ist", etc.) ist kaum noch ein Unterschied zu Management 1.0 erkennbar. (siehe auch: agiler Marxismus und Leninismus)

Management 3.0 ist dagegen der Versuch alle Ebenen in Veränderungen und Entscheidungen einzubeziehen, und zwar nicht nur als Betroffene sondern als Beteiligte. Um das zu erreichen gibt es eine Vielzahl von Praktiken und Techniken die in ihrer Gesamtheit das Management 3.0-Framework ausmachen (z.B. Merit Money und Delegation Poker). Ihnen allen ist gemeinsam, dass sie nicht angeordnet sondern gemeinsam durchgeführt werden sollen.

Mit der Benennung 3.0 erfolgt damit nicht nur eine Differenzierung zum "traditionellen" Management sondern ganz wesentlich auch zu denen, die zwar eigentlich das Richtige wollen, die Transition aber durch Bevormundung der Mitarbeiter und undifferenziertes Copy & Paste anderswo erfolgreicher Methoden umsetzen wollen. Ihnen die Management-Typen 1.0, 2.0 und 3.0 zu erklären kann schmerzhaft aber hilfreich sein und ist daher zu empfehlen.

Struktur, die aus Post-Its entsteht

Alberto Brandolini hat völlig recht wenn er sagt, dass das Identfizieren und Modellieren von Strukturen und Prozessen am besten mit bunten Zetteln auf einer grossen Wand stattfinden kann. Seine Art das zu tun nennt er Event Storming. Selbst wenn nicht alles davon in jeden Kontext passt, inspirieren lassen kann man sich durch seine Ideen auf jeden Fall.

Prozessverbesserung alleine ist keine Lösung

Bild: Wikimedia Commons / Johannes Martin Conrad - CC BY 3.0

Kann sich noch jemand an den Spruch "pünktlich wie die Bundesbahn" erinnern? Lange ist es her, dass das der Normalfall war. Angesichts von Verspätungsquoten von 30 % allein im Fernverkehr versucht die Bahn AG gerade gegenzusteuern. Mit dem so genannten Deutschlandtakt sollen Züge besser aufeinander abgestimmt werden, mit weiteren Massnahmen soll das Ein- und Austeigen schneller und effizienter gemacht werden. Das Ziel: mehr Pünktlichkeit.

Um die Erwartungen von Anfang an zu dämpfen: pünktlich werden die Züge auf diesem Weg nicht werden. Ein bisschen werden die Verspätungen mit Sicherheit zurückgehen, zum grössten Teil aber bestehenbleiben. Denn so gut die Prozessverbesserungen auch sein mögen, dass Hauptproblem werden sie nicht lösen können - die veralteten und immer wieder ausfallenden technischen Systeme.

Man kennt es aus den Durchsagen am Bahnsteig. Weichenstörungen unterbrechen die Fahrt, Signalstörungen verhindern die Einfahrt in die Bahnhöfe, defekte Oberleitungen bringen Züge zum Stillstand, Waggons mit ausgefallenen Klimaanlagen müssen ausgetauscht werden, defekte Schranken dürfen nur im Schrittempo passiert werden - solange das alles nicht in den Griff bekommen wird kann auch der beste Prozess nicht helfen.

Die Parallelen zu IT-Projekten und -Abteilungen sind offensichtlich. Häufig wird die Einführung von Scrum oder Kanban mit grossen Hoffnungen verbunden, die dann an der veralteten Technik und Systemlandschaft scheitern. Computer haben zuwenig Diskspace, Test- und Entwicklungsumgebungen müssen manuell eingerichtet werden, Telefonkabel aus den 70er Jahren verlangsamen die Datenübertragung, etc. etc.

Wie beim Beispiel der Bahn heisst das nicht, dass Prozessverbesserungen nichts bringen. Starre Planungen und Bürokratie zu beseitigen ist immer eine Verbesserung. Ohne die begleitenden Modernisierungen von Software und Hardware wird ihre Wirksamkeit aber deutlich eingeschränkt bleiben. Erst durch eine Kombination dieser Faktoren kann es zum befreienden grossen Sprung nach vorne kommen.

Diese Themen anzusprechen kann in vielen Unternehmen zum Offenbarungseid führen: Agilität sei als Ansatz gewählt worden weil davon ausgegangen wurde, dass die Umstellung von Meetings und Rollen mit geringem Aufwand möglich ist, für darüber hinausgehende Modernisierung wäre aber kein Geld da. Das würde doch auch bestimmt ohne gehen, oder? Derartige Aussagen sind häufiger als man denken sollte.

Die Antwort darauf kann nur eine sein: Das kann man zwar so machen, aber dann sollte man seine Erwartungshaltungen deutlich herunterfahren.

Wie technikfern darf ein Scrum Master oder Agile Coach sein? (II)

Bild: Pexels / Tim Gouw - CC0 1.0

Die agile Welt ist ein Dorf. Sobald man einige Scrum- oder Kanban-Projekte ausserhalb der IT gemacht hat wird man schnell zum gefragten Ansprechpartner zu diesem Thema. Der Grundtenor klingt dabei immer ähnlich: "Ich interessiere mich ja sehr für Agilität, Scrum Master oder Agile Coach wäre was für mich. IT ist aber nicht so mein Ding. Wie finde denn ich Jobs in anderen Bereichen?" Nun ja.

Es ist nicht so als würde es diese Jobs nicht geben (zwar nicht viele, aber es gibt sie). Ich habe bereits Teams coachen dürfen die mit Scrum oder Kanban im Vertrieb, in der Hardwarefertigung, im Kundenservice und im Change Management gearbeitet haben, dazu kommen immer mehr Beispiele aus anderen Bereichen, zum Beispiel gibt es in meiner Heimatstadt Bonn sogar Scrum im Schulunterricht.

Das letzte dieser Beispiele zeigt aber auch direkt das erste Problem auf: selbst wenn manche Anwendungsgebiete IT-fern sind, einfach zugänglich sind sie aber trotzdem nicht unbedingt. Es darf eben nicht jeder an einer Schule unterrichten, dafür muss man vorher an einer Universität gewesen sein und Lehramt studiert haben. Auch in anderen Fällen stösst man schnell an Grenzen formaler Art, die nicht einfach zu überwinden sind.

Nun engt sich damit die Zahl in Frage kommender Jobs zwar weiter ein, aber es gibt sie, oder? Die Antwort: ja, aber. Sie existieren natürlich, in sehr vielen Fällen allerdings nur temporär. Agilität in Service- oder Hardware-Bereichen findet häufig da statt, wo Innovationsarbeit geleistet wird. Für Experimente, Prototypen und MVPs lohnt sich agiles Arbeiten, sobald die Serienfertigung oder -durchführung beginnt eher nicht mehr.

Scrum Master- oder Agile Coach-Stellen sind in solchen Kontexten nur zeitweise nötig. Derartige nicht-IT-Projekte leihen sich eine solche Person daher in der Regel vorübergehend aus, und zwar von da wo es sie bereits gibt - eben aus der IT. Die Alternative, das Vorhalten eines permanenten Scrum Master- oder Coach-Pools, würde eine Nachfrage voraussetzen die es in den meisten Firmen nicht gibt.

Ist die Suche nach einer Position ausserhalb der IT also völlig hoffnungslos? Das zwar nicht, realistisch betrachtet ist die Wahrscheinlichkeit einen zu finden aber sehr gering, zumindest wenn es eine langfristige Beschäftigung sein soll. Was am ehesten sein kann ist, dass sich eine temporäre Stelle finden lässt, die man mit etwas Glück besetzen kann. Es fragt sich nur - was passiert wenn dieses Projekt vorbei ist?

Die eine Möglichkeit wäre das Entlanghangeln von einer temporären Stelle zur nächsten. Nicht unmöglich aber sehr schwierig - so viele derartige Jobs gibt es auch nicht. Die andere Möglichkeit wäre, eine Beschäftigung im agilen nicht-IT-Bereich als Vorstufe für einen Einstieg in die IT zu benutzen. Aufgrund des Fachkräftemangels ist das nicht einmal unrealistisch, allerdings kommt man dann an der Beschäftigung mit der Technik nicht mehr vorbei. Dieser Umstände sollte man sich bewusst sein.

Kommentierte Links (XXXXII)

• Tim Harford: Why Big Companies Squander Brilliant Ideas

  Ein langer Text, aber lesenswert. Mit mehr als 20.000 Zeichen führt Tim Harford aus warum sich große Organisationen mit Innovationen schwer tun: zum einen weil neue, zu Beginn noch nicht profitable Ideen sich im internen Wettbewerb um Ressourcen nicht gegen die etablierten, seit langem Gewinn abwerfenden Cash Cows durchsetzen können, zum anderen weil die bestehenden Organisationsstrukturen so stark auf die bestehenden Produkte zugeschnitten sind, dass neue Produktideen nur umgesetzt werden wenn sie ebenfalls diesen Strukturen entsprechen - was häufig nicht der Fall ist. Der dritte Grund dagegen ist wesentlich polemischer und darum mit Vorsicht zu geniessen: "Because people are idiots."
  

• Dennis Willkomm: Am Scheitern scheitern – Gefahren der Fehlerkultur

Ich freue mich ja immer wenn ich merke, dass ich nicht der erste aus der lokalen Agile-Community bin der dieses Internet vollschreibt. Dennis Willkomm hat sich hier eines selten behandelten Themas angenommen, nämlich dem, dass nicht nur die Einführung von Methoden sondern auch die Veränderung einer Unternehmenskultur im Cargo Cult enden kann. Mit Exkursen in die Psychologie unterfüttert wird eine Erkenntnis herausgearbeitet die man vielen Change Management-Abteilungen nur wünschen kann: wer glaubt seinen Mitarbeitern eine neue Kultur einfach überstülpen zu können wird damit alles mögliche erreichen, nur nicht das was er eigentlich beabsichtigt hat.

• Alice Newton Rex: Escape From the Feature Roadmap to Outcome-driven Development

  Ein Thema das ich in letzter Zeit immer wieder in Product Owner-Workshops besprochen habe findet sich auch hier wieder: gegenüber Stakeholdern/Management/Kunden/Auftraggebern sollte sich ein Product Owner nicht zur Lieferung bestimmter Funktionalitäten verpflichten sondern zur Lieferung abstrakt formulierter Kundenmehrwerte, deren bester Umsetzungsweg sich erst im Rahmen der Umsetzung selbst ergeben wird. Dieser Ansatz widerspricht zwar dem üblichen Verhalten in vielen Organisationen (Alice Newton Rex erklärt gut warum), führt aber bereits mittelfristig zu besseren Ergebnissen als die vordefinierte Roadmap, die zuverlässig zu einem Ziel führt das von der Zielgruppe mittlerweile längst verlassen worden ist. (Siehe auch: agile Roadmaps)
  

• Joe Crick: It Doesn’t Have to be Perfect

  Einige gute Gedanken zum Thema Legacy Code, nicht zuletzt deshalb weil sie nicht aus einer technischen sondern eher aus einer soziologischen Perspektive geschrieben wurden. Folgende Aspekte sind für Joe Crick im Umgang mit Legacy Code wichtig:
  
  • Respektiere das was er tut: er mag nicht den Standards entsprechen, aber die aus ihm bestehende Anwendung sichert Dein Einkommen.
  • Verstehe wie er entstanden ist: die Organisationsstruktur zur Zeit seiner Entstehung spiegelt sich im Code wieder (→ Conway's Law). Damals hat er vielleicht mehr Sinn ergeben als heute.
  • Lege realistische Standards an: die Aussage aus der Überschrift. Code muss nicht perfekt sein, es reicht wenn er gut ist. Beziehungsweise - gut genug für den Zweck den er erfüllen soll.
  • Sei massvoll in der Beurteilung: in den seltensten Fällen ist Legacy Code der unbrauchbare Mist als der er häufig beschimpft wird. Er mag buggy, kompliziert und umständlich sein, aber dann sollte man ihn auch nur so nennen.
  • Gehe gelassen mit ihm um: Kein Mensch ist perfekt, alle machen Fehler. Und umgekehrt und nicht alles ein Fehler was man selbst nicht versteht. Wer das akzeptiert kann besser mit den Hinterlassenschaften anderer umgehen.
  Gedanken wie diese sind praktisch immer hilfreich, und zwar nicht nur beim Schreiben von Software. Auch im Change- oder Prozessmanagement können sie von Nutzen sein, denn letztendlich ist auch die Struktur einer Firma nichts anderes als organisatorischer Legacy-Code.

• Steve Blank: What Your Startup Needs to Know About Regulated Markets

  Im Grunde eine Überschrift die bereits alles aussagt. Auch wenn der Focus zu Beginn sehr stark auf den USA liegt sind die hier gemachten Überlegungen auch in jedem anderen stark gesetzlich regulierten Markt von Bedeutung - selbst dann wenn man nicht in einem Startup arbeitet.

Der rotierende Scrum Master

Bild: Pixabay/MoreLight - CC0-1.0

Ein Phänomen das man in manchen Unternehmen beobachten kann ist der "rotierende Scrum Master". Die Rolle ist in diesem Fall nicht fest mit einer Person besetzt sondern wird in jedem Sprint von einem anderen Teammitglied wahrgenommen. Für die Dauer dieser Zeit arbeitet diese Person nicht an der Produktentwicklung mit sondern unterstützt das Team und beseitigt Impediments. Da eine solche Konstellation fast immer kontrovers diskutiert wird, lohnt es sich, einen genaueren Blick darauf zu werfen.

Zunächst die naheliegendste Frage: ist eine Rotation im Rahmen der Methodik überhaupt zulässig? Die Antwort: implizit ja. Der Scrum Guide definiert zwar die drei Rollen des Product Owners, des Scrum Masters und des Teams, legt aber nicht fest, dass es immer die selbe Person ist die sie besetzen muss. So lange alle Rollen besetzt sind ist den Formalien genüge getan.

Es gibt auch gute Gründe für ein Wechseln der Rolle zwischen den Teammitgliedern. Dadurch dass sie früher oder später von jedem ausgeübt wird liegt die Verantwortung für Prozess und Methodik bei allen und nicht nur bei einem. Gleichzeitig steigt auch die Ausfallsicherheit - ein Urlaub oder eine Krankheit des Scrum Masters lässt keine Lücke entstehen, da alle anderen in der Rolle geübt sind und sie übernehmen können.

In vielen Fällen kommt noch dazu, dass sich kein Teammitglied findet, das dauerhaft seinen bisherigen Job aufgeben möchte. Selbst wenn die Sinnhaftigkeit eines Scrum Masters eingesehen und hochgehalten wird finden viele Menschen in der Produktentwicklung eine wesentlich grössere Erfüllung. Muss das nur vorübergehend aufgegeben werden kann das die Besetzung deutlich einfacher machen.

Auf der anderen Seite gibt es auch Gegenargumente. Das naheliegendste ist, dass die Beschäftigung mit Methodik, Moderation, Coachimg, etc. erstaunlich viel Zeit in Anspruch nehmen kann, und zwar nicht nur in der Durchführung sondern auch im Lernen, Weiterbilden, Reflektieren und Perfektionieren. Wird das nicht auch dann vorangetrieben wenn die Rolle gerade nicht ausgeübt wird  kommt es zu kurz um wirksam zu sein (und damit stellt sich auch die Frage nach der dafür verfügbaren Zeit).

Ebenfalls nicht zu vernachlässigen ist, dass durch eine Rotation Neutralität verloren geht. Wer bestimmte Entscheidungen der Produktstrategie oder -umsetzung (mit)verantwortet hat wird sich schwer tun Konflikte zu diesen Themen unbefangen zu moderieren. Schlimmstenfalls wird er selbst als Teil einer Konfliktpartei gesehen und nicht als Vermittler akzeptiert. Um das zu vermeiden ist eine hohe Konflikt- und Meetingkultur aller Beteiligten nötig.

Zuletzt ist es in grösseren Organisationen meistens so, dass die Einheiten und Personen ausserhalb des Scrum Teams sich einen festen Ansprechpartner wünschen. Ist dieser nicht gegeben kann ggf. das Beziehungs- und Vertrauensnetzwerk nicht entstehen, das zur schnellen und unkomplizierten Beseitigung von Impediments nötig ist. Auch das oft praktizierte Geben, Nehmen und Verrechnen von Hilfen und Gefälligkeiten wird schwerer.

Eine immer richtige Entscheidung für oder gegen einen rotierenden Scrum Master kann es aus den genannten Gründen nicht geben, wohl aber eine Entscheidungshilfe: diese Konstellation wird vor allem da funktionieren wo sowohl das Scrum Team als auch die umgebende Organisation Scrum samt des dazugehörenden Mindset sehr gut verstanden haben und es aus intrinsischer Motivation heraus befolgen. Da wo das (noch) nicht gegeben ist kann eine dauerhafte Rollenbesetzung mehr Sinn machen.

Backlog-Priorisierung

Die Priorisierung noch zu erledigender Arbeit scheint auf den ersten Blick ein Thema zu sein in dem sich agile und klassische Vorgehensweisen kaum unterscheiden. Auch vor der Erfindung von Scrum und Co wurde schon überlegt welche Aufgaben wichtiger und welche unwichtiger sind. Auf den zweiten Blick tun sich dagegen Unterschiede auf, die vor allem mit einem Instrument in Verbindung stehen - dem Product Backlog.

Um zu verstehen warum diese Art der Priorisierung anders ist empfiehlt sich ein Blick darauf wie Priorisierung klassischerweise stattfindet. In den meisten Unternehmen bekommen Anforderungen entweder eine Wichtigkeitsklasse (z.B. Minor, Medium, Major, Blocker) oder eine die Bedeutung anzeigende Zahl zugewiesen (z.B. 1 = unwichtig bis 100 = extrem wichtig). Je höher diese Wichtigkeitsklasse, bzw. diese Zahl sind, desto höher die Priorität.

Was in der Theorie zunächst einfach und nachvollziehbar klingt erweist sich in der Realität in der Regel als unpraktikabel. Da jeder Stakeholder ein Interesse daran hat, dass seine Anforderungen zuerst umgesetzt werden, wird er sich um eine hohe Bewertung bemühen. Im Zweifel wird ihm diese auch zugestanden werden, da mit dieser Einstufung ja noch keine weiteren Zusagen verbunden sind. Es geht an dieser Stelle nur um die Wichtigkeit, noch nicht um die Machbarkeit.

Schon nach kurzem wird dieses Vorgehen dazu führen, dass eine hohe zwei- oder dreistellige Zahl an Anforderungen als Blocker, bzw. zwischen 90 und 100 eingeordnet wird. Ist dieser Punkt erreicht ist die Priorisierung wertlos geworden. Wenn alles super-wichtig ist, dann ist alles gleich (un)wichtig. Übliche Reflexe sind jetzt die Erweiterung der Skala (z.B. um einen Showstopper-Status oder um die Zahlen 101 bis 110), was aber bald auch wieder entwertet sein wird.

Die Einträge eines Product Backlog werden dieser Bedeutungs-Inflation normalerweise bewusst entzogen, indem auf Wichtigkeitsklassen einfach verzichtet wird. Die Priorität ergibt sich hier anders, nämlich durch die Natur des Backlogs selbst. Dieses ist keine Ansammlung von unterschiedlich wichtigen Teilmengen mehr (deren jeweilige Einzelteile unter sich gleichwertig sind), sondern etwas viel Einfacheres - eine sortierte Liste.

Was eine solche Liste besonders macht ist, dass auf ihr keine Punkte nebeneinander stehen können sondern nur untereinander. Aufgelistet eben. Es gibt also immer einen wichtigsten Eintrag, einen zweitwichtigsten, einen drittwichtigsten, etc. Und wo auch immer man eine neue Anforderung dazwischenschiebt, sie wird immer jeweils ober- und unterhalb einer anderen stehen und damit automatisch priorisiert sein.

Es bleibt die Frage - wenn es so einfach ist, warum macht es dann nicht jeder so? Die Antwort - weil ein als Liste sortiertes Backlog seinen Verwalter dazu zwingt, Konflikte sowohl früh als auch immer wieder auszutragen. Es ist mit diesem Vorgehen nicht mehr möglich, jeden wichtigen Stakeholder zufriedenzustellen indem man ihm die höchste Wichtigkeitsklasse gibt. Wenn seine Idee auf Position 43 von 120 liegt (und demnach nicht so schnell umgesetzt werden wird) dann sieht er das sofort und kann das eskalieren.

Um derartige Konflikte zu vermeiden wird häufig die klassische Art der Priorisierung bevorzugt. Die Auseinandersetzungen tauchen zwar auch hier auf, aber erst wesentlich später, wenn den Beteiligten langsam dämmert, dass die scheinbar hohe Priorität weitgehend ohne Aussagekraft ist. Manche Organisationen haben es zu erstaunlicher Meisterschaft darin gebracht, diesen Punkt immer weiter nach hinten zu verlagern, mit langen Phasen des Stillstands als Folge.

Zu lernen, dass das kein zielführender Weg ist, und dass das frühe (und konstruktive) Austragen von Konflikten zwar schmerzhaft aber letztendlich besser ist, ist Teil des zu agilen Transitionen gehörenden Kulturwandels. Der ist zwar mitunter unangenehm, bringt aber einen grossen Vorteil mit sich: man ist plötzlich in der Lage Priorisierungen durchzuführen, in einer Art die diesen Namen auch verdient.

Deine Muda: Warten

Bild: Wikimedia Commons / Siyuwj - CC BY-SA 3.0

Fünfter Teil der Deine Muda-Serie. Die vierte Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist das Warten. Ein interessanter Aspekt - auch das erzwungene Nichtstun kann demnach eine zu vermeidende Tätigkeit sein. Max Weber wäre begeistert.

Ähnlich wie in vielen anderen Zusammenhängen ist auch das Warten aus mehr als einem Grund problematisch. Zum einen weil es dazu führt, dass bestimmte Arbeiten später fertig werden, zum anderen wegen der Tätigkeiten die währdenddessen durchgeführt werden. Denn Nichtstun bedeutet in diesem Kontext nicht etwa völlige Untätigkeit, sondern lediglich die Untätigkeit in Bezug auf eine bestimmte Arbeit.

Zunächst aber zu den Verspätungen. Man kann es ohne grosse Erläuterungen verstehen: wenn ein Produktionsprozess immer wieder so lange angehalten werden muss, bis bestimmte Vor- oder Zuarbeiten erledigt sind, dann verlängert sich dadurch die Produktionsdauer. Wie im Fall fast aller anderen Mudas wird das Produktionsmaterial dadurch zeitweise dem Wirtschaftskreislauf entzogen. Es entsteht totes Kapital. Aber das ist noch nicht alles.

Als zweiter Effekt kommt es zu dem so genannten Cost of Delay, bzw. zu Verspätungskosten. Wäre der Produktionsprozess schon früher beendet gewesen, hätte man mit seinem Ergebnis bereits Geld verdienen können. Die Summe die einer Firma dadurch entgeht, dass das nicht möglich ist, ist mit dem Begriff des Cost of Delay gemeint.

Auch damit sind aber noch nicht alle negativen Effekte erwähnt. Was noch fehlt sind die weiter oben genannten Tätigkeiten die währdenddessen durchgeführt werden. Mit dem Warten ist nämlich das Warten des Produkts auf seine Fertigstellung gemeint, nicht etwa das Warten eines Angestellten auf Beschäftigung. Der beginnt in der Regel währenddessen bereits mit dem nächsten Arbeitspaket.

In der Praxis sieht das so aus, dass sobald an einer Arbeit kein Fortschritt mehr möglich ist eine zweite begonnen wird, sobald es auch an der nicht mehr weitergeht eine dritte, etc. Sobald die für das Weiterarbeiten an der ersten Aufgabe notwendige Zulieferung erfolgt ist werden die später begonnenen unterbrochen, es geht mit der ersten weiter, nach deren Abschluss wieder mit den späteren.

Wird auf diese Art und Weise vorgegangen treten aber zwangsläufig Probleme auf: zum einen das Multitasking mit seinen üblichen Begleiterscheinungen von Konzentrationsverlust und Umgewöhnungsaufwand, zum anderen Priorisierungskonflikte. Was ist jetzt wichtiger, die Wiederaufnahme der schon länger wartenden ersten Aufgabe oder das störungsfreie Weiterarbeiten an einer späteren? Auch diese Konflikte kosten Zeit und Geld.

In Summe sind die genannten Folgen von Wartephasen im Produktionsprozess so kostspielig, dass nach Möglichkeit versucht werden sollte sie zu vermeiden. Die einfachste Möglichkeit dazu ist die Bildung eines Crossfunktionales Teams. Wenn alle Tätigkeiten selbst erledigt werden können verschwindet mit der Abhängigkeit von anderen Gruppen die häufigste Ursache des Wartens.

Auch andere Ansätze sind möglich, etwa die bessere Abstimmung von Teams untereinander (Just in Time-Delivery) oder das Anhäufen von Vorarbeiten in einem ausreichenden Ausmass um später nicht in Leerlauf zu geraten (ein durchaus sinnvolles, aber häufig auf andere Art problematisches Vorgehen, das man sich gut überlegen sollte).

Was auf jeden Fall bewusst sein sollte: Bemühungen zur Vermeidung von Wartezeiten führen häufig zu anderen nicht gewinnbringenden Tätigkeiten (Transport, Lagerhaltung, etc.), deren Optimierung möglicherweise wieder zu neuen Wartezeiten führt. Der so entstehende Verbesserungsprozess ist dadurch nie abgeschlossen - was auch absolut Sinn macht.