Planview Blog

Ihr Weg zu geschäftlicher Agilität

Work-Management für Teams

Über die WIP-Grenzen hinausgehen, um die organisatorische Leistung zu steigern

Veröffentlicht Von Michael Hannan

Sie haben wahrscheinlich schon die große Neuigkeit gehört: Multitasking ist ein Mythos. Und doch macht sich praktisch jeder schuldig, zwischen mehreren Projekten gleichzeitig hin und her zu wechseln - und gleichzeitig E-Mails, Gespräche im Vorbeifahren, Telefonanrufe und vieles mehr zu beantworten. Wenn wir unter dem Druck stehen, schneller arbeiten zu müssen, überfordern wir uns oft, indem wir versuchen, mehr Aufgaben zu übernehmen, wodurch unser Fokus ungewollt verwässert wird und wir langsamer werden - sehr viel langsamer.

Bei Fortezza Consulting helfe ich Teams, ihre Leistung dramatisch zu verbessern - manchmal um 3x oder mehr. Der wichtigste Baustein ist Single-Tasking: Konzentrieren Sie sich voll und ganz auf die Lieferung von Qualitätsarbeit, ein Stück nach dem anderen. Die Auswirkungen von Single-Tasking sind auf individueller Ebene dramatisch und auf organisatorischer Ebene umwälzend.

In komplexen, schnelllebigen Unternehmen ist es unmöglich, ohne einen disziplinierten Ansatz eine einzige Aufgabe zu erledigen. An dieser Stelle kommen die WIP-Ziele (Work-in-Process) ins Spiel. Lesen Sie weiter und sehen Sie sich die Aufzeichnung dieses Webinars an, um die Lean- und Kanban-Gründe zu erfahren, warum WIP-Ziele funktionieren und wie Sie sie auf Unternehmensebene anwenden können.

Lean, Kanban und WIP

Ein Schlüsselprinzip von Lean und Kanban ist die Visualisierung des tatsächlichen Arbeitsflusses. Durch die Visualisierung ihrer Arbeit sind die Teams in der Lage, kontinuierlich Verbesserungsmöglichkeiten zu erkennen. Kanban-Tafeln helfen Teams dabei, die Priorität, den Status, die zugewiesenen Teammitglieder, die Fälligkeitstermine und vieles mehr für jede Arbeit zu visualisieren. Sie können auch Probleme erkennen, die den Arbeitsfluss behindern - wie Engpässe und Blockierer - und können daran arbeiten, ihren Prozess zu verbessern, um einen kontinuierlichen Fluss zu erreichen. Durch diesen Prozess der kontinuierlichen Verbesserung können die Teams ihre Leistungsziele erreichen.

Ein weiteres wichtiges Element der Kanban-Praxis ist die Verwendung eines Pull-Systems. Das bedeutet, dass die Teams die Arbeit in ihr System ziehen, wenn sie Kapazität haben (und nicht, dass ihnen die Arbeit ohne Rücksicht auf ihre Arbeitsbelastung "aufgedrückt" wird). Um ein Pull-System zu haben, müssen Teams ein priorisiertes Backlog und einen klaren Prozess für die Priorisierung haben. Auf diese Weise kann jedes Teammitglied die priorisierte Arbeit in das System einbringen, wenn es über die entsprechenden Kapazitäten verfügt.

Es ermöglicht dem Team auch, WIP-Limits - oder idealerweise WIP-Ziele - einzuführen. Die Begrenzung des WIP ermöglicht es den Teams, sich auf die Verbesserung der Qualität und Geschwindigkeit ihrer Arbeit zu konzentrieren. WIP-Ziele erschließen ein neues Leistungsniveau durch die Kraft der Einzelarbeit und fördern eine Kultur des Experimentierens und der Zusammenarbeit, die ein Katalysator für das Erreichen immer höherer Leistungsziele sein kann.

Was Sie lernen werden

In diesem Webinar führe ich in das Konzept der WIP-Ziele und ihre Anwendung auf Unternehmensebene ein und gehe auf wichtige Fragen ein, wie z.B.:

  • Wie können wir erkennen, wann es an der Zeit ist, den WIP zu optimieren?
  • Woher wissen wir, was das richtige WIP-Ziel ist?
  • Wie können wir WIP-Ziele nutzen, um die Autonomie und das Selbstmanagement des Teams zu stärken?
  • Wie können wir sowohl den Führungskräften als auch den Wissensarbeitern dabei helfen, den notwendigen Sinneswandel zu vollziehen?
  • Wie können wir die Anwendung von WIP-Zielen im gesamten Unternehmen skalieren?

Sie lernen, wie Sie das Experimentieren und die Zusammenarbeit fördern und mit Ihrem Team ein noch nie dagewesenes Leistungsniveau erreichen können.

Sehen Sie sich die Aufnahme an

Blättern Sie durch mein Slide Deck hier.

10 Häufige Fragen zu WIP-Zielen

F: Meinen Sie, dass ein Team mit 20 gepaarten Programmierern einfach ein Team-WIP-Ziel von 10 wählen sollte?

A: Ja! Für diejenigen, die mit der gekoppelten Programmierung vielleicht nicht vertraut sind, bedeutet es einfach, dass zwei Softwareentwickler (Programmierer) für jede Aufgabe zusammenarbeiten. Es macht also Sinn, dass ein Team von 20 ein Team-WIP-Ziel von 10 haben würde.

Wenn jedoch ein oder zwei Mitglieder dieses Teams von 10 erfahrene Experten sind, die besser zur Verbesserung des Teamflusses beitragen können, indem sie sich zu denjenigen Programmierern "schweben" lassen, die Hilfe bei der Beschleunigung der Dinge benötigen, dann könnte es für dieses Team von Vorteil sein, ein Team-WIP-Ziel von 9 oder vielleicht sogar 8 zu erkunden.

F: Wie würden Sie das in einer großen Organisation mit einem gewissen Maß an Konsistenz skalieren, wenn jedes Team so viel Autonomie hat?

A: Der Aspekt, der nicht verhandelbar ist, ist die "Wie könnten wir...?"-Kultur, die auf der Grundlage der Einzeldisziplin beruht - und alles, was getan werden kann, um diese Kultur zu fördern und zu stärken.

Wenn jedes einzelne Team völlig unterschiedliche Team-WIP-Ziele hat, die aber alle auf einer starken Disziplin für eine einzelne Aufgabe beruhen, dann haben Sie wahrscheinlich gerade etwas wirklich Erstaunliches erreicht.

Der nächste Schritt für projektzentrierte Umgebungen besteht darin, das Konzept der Team-WIP-Ziele auf die Ebene des Projektportfolios (WIP auf Projektebene) zu übertragen. Die Anpassung des WIP auf Aufgaben- und Projektebene an die Kapazität ist das beste Rezept, das ich kenne, um den Durchsatz bei der Fertigstellung von Projekten drastisch zu erhöhen.

F: Wie kann ich die Zustimmung meiner Teams gewinnen?

A: Ich beginne gerne damit, dass ich die Teilnehmer einlade, das auf der unten gezeigten Folie beschriebene Einzelspiel zu spielen - das Spiel dauert nur etwa 10 Minuten, und vielleicht 10-15 Minuten, um die Erfahrungen und Erkenntnisse zu besprechen, also insgesamt weniger als 30 Minuten.

In der Regel sind die Leute ziemlich erstaunt über den Unterschied bei Geschwindigkeit und Zuverlässigkeit. Erzählen Sie ihnen dann meine Geschichte über die Rubik's Cube-Rätsel und fragen Sie sie, ob sie der Meinung sind, dass der Geschwindigkeitsunterschied bei komplexen Wissensaufgaben wahrscheinlich noch größer ist. Dann fragen Sie sich: "Was wäre, wenn wir nur halbwegs in der Lage wären, eine ideale Umgebung für die Konzentration auf eine einzige Aufgabe zu erreichen?" und "Was wäre, wenn wir dies nur für unsere ranghöchsten, fachkundigsten "Engpass"-Ressourcen tun könnten, die die komplexesten Aufgaben erledigen?"

Seien Sie auf unterschiedliche Reaktionen gefasst - von hochgradig fasziniert bis hin zu großer Skepsis. Es geht bei diesem ersten Gespräch nicht unbedingt darum, jemanden von etwas zu überzeugen, sondern nur darum, das Gespräch in Gang zu bringen.  Bitten Sie dann darum, das Gespräch fortzusetzen, indem Sie das Spiel vielleicht auf die Tagesordnung einer bevorstehenden Teamsitzung setzen oder fragen, ob jemand die neueste Studie über Single-Tasking gesehen hat.  Der Schlüssel dazu ist, dass Sie es nicht als einen "Buy-in"-Prozess betrachten, bei dem Sie etwas "verkaufen" oder anpreisen, sondern als einen echten Beginn eines Gesprächs in der Art "Wie könnten wir...?  Vielleicht erhalten Sie einige interessante und kreative Vorschläge, die nichts mit Single-Tasking zu tun haben, aber dennoch einen Versuch wert sein könnten.

F: Wie können wir unsere Mitarbeiter motivieren, sich an mehr funktionsübergreifenden Projekten und Teams zu beteiligen? (d.h.. Vertriebsmitarbeiter, die an Materialhandhabungsprojekten beteiligt sind, Produktionsingenieure, die an Qualitätsprojekten beteiligt sind, Qualitätsmitarbeiter, die an Verkaufsprojekten beteiligt sind, usw.)

A: Wann immer es möglich ist, setze ich das gesamte funktionsübergreifende Team auf eine einzige, einfache ToDo/Doing/Done-Tafel und verwende dann Kartentypen, um das gesamte Spektrum der erforderlichen Fähigkeiten widerzuspiegeln.  Selbst wenn Sie sich in einer stark segmentierten, phasengesteuerten Umgebung befinden, kann es für die Leute in den verschiedenen Funktionen ein echter Augenöffner sein, die Arbeit zu sehen, die jeder vor sich hat.  Und mit Planview AgilePlace ist es einfach, nach Kartentyp zu filtern, wenn Sie sich nur auf die Funktion Ihres Teams konzentrieren möchten.  Es ist auch einfach, eine Analyse darüber durchzuführen, wo die größten Engpässe im End-to-End-Prozess liegen.

Wenn ein solches funktionsübergreifendes Board nicht machbar ist, dann finde ich es toll, dass Planview AgilePlace Card Connections anbietet, um die Verbindung zwischen den Karten zu zeigen - egal ob auf demselben Board oder auf vielen verschiedenen Boards. Es kann einen gewissen Mehraufwand bedeuten, wenn die Leute solche Verbindungen explizit machen, aber nachdem ein paar Leute damit angefangen haben, wird es ein wenig ansteckend.

Ein weiterer sehr wichtiger Punkt in diesem Zusammenhang - die Advanced und Enterprise Editionen von Planview AgilePlace bieten auch großartige Analysen für eine boardübergreifende Berichterstattung.  So können wir für diejenigen, die mehrere Boards betreuen, Berichte über einzelne Aufgaben erstellen, um zu sehen, wie viele Aufgaben sie gleichzeitig bewältigen müssen, und dann fragen: "Wie können wir dazu beitragen, diese Zahl auf eine Aufgabe zu reduzieren?"  Ohne diese Berichtsfunktion müssten Sie die Aufgaben jedes Benutzers mit mehreren Boards in jedem der ihm zugewiesenen Boards überprüfen.

F: Die erste Frage, die mir Teams stellen, lautet: "Wie hoch sollte unser WIP-Limit sein?" Was ist ein guter Ratschlag jenseits von "so niedrig, dass es irgendwie schmerzhaft ist"?

A: Ich möchte Sie ermutigen, mit dem Gedanken zu beginnen, dass das Streben nach einer auf eine einzige Aufgabe konzentrierten Umgebung wünschenswert ist - und wenn Sie damit nicht einverstanden sind, lesen Sie meine Antwort auf die dritte Frage (über die Einbindung Ihrer Teams).

Wenn die Leute erst einmal erkannt haben, dass dies wirklich ein wichtiger Faktor für Geschwindigkeit und Zuverlässigkeit ist, müssen Sie nur noch dafür sorgen, dass das WIP-Ziel nicht höher ist als die Anzahl der Mitarbeiter. Wenn sich das Team immer mehr dem echten Single-Task-Verhalten annähert, können Sie das Team auffordern, mit seinen eigenen WIP-Zielen zu experimentieren, die immer niedriger sein sollten als die Anzahl der Arbeiter.

Entscheidend ist, dass jeder weiß, dass es in Ordnung ist, so weit das Team heute auch vom Ziel entfernt sein mag, wenn sich der WIP auftürmt, solange die Tafel die Realität genau widerspiegelt und wir uns wirklich fragen: "Wie können wir den WIP-Level näher an unser Ziel für die Einzelaufgabe heranbringen?"

Widerstehen Sie als Führungskraft der Versuchung zu sagen: "Hey, wieso haben Sie 5 Aufgaben offen - ich habe Ihnen doch gesagt, dass wir nur eine Aufgabe erledigen müssen! Wenn Sie das tun, werden Sie plötzlich ein Brett mit künstlicher Harmonie sehen: Das Brett wird auf magische Weise über Nacht perfekte Disziplin für eine einzige Aufgabe zeigen, obwohl das wahrscheinlich überhaupt nicht der Realität entspricht... wenn das passiert, haben Sie einen riesigen Schritt zurück gemacht und müssen vielleicht von vorne anfangen.

F: Wir haben ein hohes Volumen an Produkten, die durch unser System fließen. Wir haben Lean eingeführt, aber wir tun uns schwer mit der Verarbeitung von Einzelteilen.

A: Wenn ich das Problem hier richtig verstehe, geht es darum, dass hohe Volumina die WIP-Werte ständig weit über die Kapazität hinaus treiben und dass "Kapazität" in diesem Zusammenhang am besten durch die Verarbeitung von Einzelteilen erreicht wird, in Übereinstimmung mit dem Lean-Konzept des Einzelteilflusses.

Wenn eine solche Einzelteilverarbeitung in diesem Beispiel hauptsächlich von Menschen ausgeführt wird, dann wissen wir, dass unser WIP-Ziel das Verhalten bei Einzelaufgaben widerspiegeln sollte. Daher gilt mein Rat, das Team mit verschiedenen WIP-Zielen experimentieren zu lassen. Wenn eine solche Einzelteilverarbeitung größtenteils automatisiert oder maschinell ausgeführt wird, ist es wichtig zu verstehen, ob die Einzelteilverarbeitung wirklich das ist, was einen maximalen Durchsatz erzielen würde. Bei einer einspurigen Autobahn beispielsweise ist in der Regel jeweils ein Auto optimal, aber bei einer 12-spurigen Autobahn haben wir die Kapazität, 12 Autos parallel zu behandeln.

F: Kann dies auch für die Entwicklung von physischen Produkten gelten?

A: Solange es sich um eine menschenzentrierte oder wissensbasierte Umgebung handelt (im Gegensatz zu einer maschinenzentrierten oder größtenteils automatisierten Umgebung), funktioniert dies bei physischen Produkten genauso gut wie bei Software oder anderen "unsichtbaren" Endprodukten. Bei physischen Produkten funktioniert das wahrscheinlich sogar besser, da es oft einfacher ist zu erkennen, wo der Engpass bei physischen Produkten liegt. Schauen Sie sich einfach an, bei welchem Verarbeitungsschritt sich die physischen Arbeitsprodukte (d.h. der "Bestand") am meisten auftürmen, und dort liegt in der Regel auch der Engpass von Ende zu Ende.

F: Benötigen WIP-Limitberechnungen Zykluszeit? Und wie viele Daten benötigen Sie?

A: Technisch gesehen ja, aber manche Organisationen machen es sich zu einfach.  Um die Dinge einfach zu halten, verwende ich gerne kumulative Flussdiagramme wie das auf dieser Folie:

Es zeigt die Zykluszeiten an - es ist nur die horizontale oder X-Achsen-Dimension, die Planview AgilePlace für Sie berechnet. Es gibt auch andere Planview AgilePlace-Berichte, die sich explizit auf die Zykluszeiten beziehen. Solange das Board also die Realität widerspiegelt, sind die Zykluszeiten gut erfasst. Der Schlüssel dazu ist, dass die Steigung des CFD immer steiler wird, was nur möglich ist, wenn die Zykluszeiten sinken (vorausgesetzt, die Gesamtkapazität bleibt stabil).

Ich habe viele Beispiele von Teams gesehen, die eine Reduzierung der Zykluszeit um X% anstreben und vielleicht sogar behaupten, dass sie bei einer gewissen Zielreduzierung erfolgreich waren, aber der Gesamtfluss sieht in etwa gleich aus - ein deutlicher Hinweis darauf, dass das "lokale Optimum" nur auf Kosten des Gesamtflusses erreicht wurde.

F: Wie können wir den WIP verwalten und skalieren?

A: Ich hoffe, dass ich das Thema "Größenordnung" auf der Folie unten ausreichend behandelt habe, aber falls nicht, hier eine kurze Zusammenfassung.

Erstens: Verbreiten Sie die Kultur des "Wie könnten wir...?" durch "Kopieren und Einfügen" über mehrere Teams hinweg, wobei die Führungskräfte die Kultur des "Wie könnten wir...?" bei jeder sich bietenden Gelegenheit verstärken. Außerdem sollten Sie, wie in meiner Antwort auf die dritte Frage oben (über die Einbindung Ihrer Teams) erwähnt, eine Konsolidierung in immer weniger Gremien in Betracht ziehen, um einer echten End-to-End-Prozessansicht für jeden wichtigen Prozess in Ihrem Unternehmen immer näher zu kommen.

Zweitens sollten Sie in projektorientierten Umgebungen den Begriff der WIP-Ziele auf die Projektebene übertragen und prüfen, ob ein geringeres Volumen an gleichzeitigen Projekten zu einem höheren Durchsatz bei der Fertigstellung von Projekten führt (Hinweis: Es ist äußerst selten, dass ein geringerer Projekt-WIP nicht zu einem höheren Durchsatz führt - ich habe das nur einmal erlebt, und das war nach einer aggressiven Reduzierung des Projekt-WIP, die einfach ein bisschen zu weit ging).

Drittens sollten Sie die Anwendung von Konzepten aus dem Critical Chain Project Management in Betracht ziehen, um die optimale Höhe des Projekt-WIP zu ermitteln (mehr über Critical Chain Project Management erfahren Sie in meinem neuen Buch The CIO's Guide to Breakthrough Project Portfolio Management).

F: Wie messen Sie den WIP in der Phase vor der Entwicklungsarbeit?

A: Ich bezeichne die Arbeit in der "vorangehenden Phase" gerne als verschiedene Kartentypen auf ein und demselben Brett, mit einem einfachen ToDo/Doing/Done-Konstrukt. Auf diese Weise erhalten wir ein genaues Bild des gesamten WIP-Niveaus des Teams und können sogar herausfinden, welche Funktionen oder Unterteams näher an der Einzelaufgabendisziplin sind als andere, und sie dann dazu bringen, den anderen Funktionen oder Unterteams mitzuteilen, wie sie dies erreicht haben.

Außerdem ist es für übergreifend geschulte Teammitglieder einfacher zu erkennen, wo jemand, z.B. aus dem Testteam, unter einem Hindernis leidet, bei dem ein Mitglied des Entwicklungsteams im Namen der Verbesserung des gesamten Teamflusses vielleicht helfen kann. Dies steht im Einklang mit den Scrum-Prinzipien eines integrierten Teams, das durch effektive Zusammenarbeit und Cross-Training immer besser wird, während die einzelnen Mitarbeiter ihre primären Rollen und Spezialgebiete beibehalten.

Ähnliche Beiträge

Geschrieben von Michael Hannan

Michael ist der Gründer und Hauptberater von Fortezza Consulting. Er ist ein professioneller Keynote-Speaker, Bestsellerautor und Innovator von hochwirksamen Techniken zur Steigerung der Leistung von Projektportfolios. Außerdem ist er im Vorstand der gemeinnützigen Organisation Project Management for Change, die die größte Pro-Bono-Projektmanagement-Veranstaltung in der Geschichte der Menschheit organisiert. Kontaktieren Sie ihn auf LinkedIn hier.