Wo man in Einem Pull System Seine Nächste Aufgabe Findet

Wo findet man seine nächste Aufgabe in einem Pull-System? Die Antwort auf diese Frage erscheint auf den ersten Blick einfach. Häufig wird sie von Mitgliedern agiler Teams jedoch so beantwortet, dass sie sich die Aufgabe auf dem Task Board aussuchen, welche den größten Spaßfaktor mit sich bringt. Dieses Vorgehen ist aus menschlicher Sicht durchaus nachvollziehbar, verletzt aber einige agile Prinzipien und Werte. Dieser Artikel zeigt weshalb es sinnvoll ist sich bei der Auswahl der nächsten Arbeitsaufgabe, nicht auf eine beliebige Aufgabe zu stürzen, sondern diese nach konkreten Kriterien auszuwählen.

Das Pull Prinzip

Produktionssysteme Damals …

Bereits zu beginn des 20ten Jahrhunderts führte Toyoda Sakichi in seiner Firma das heute berühmte Toyota-Produktionssystem ein. Es wurde über Jahrzehnte weiterentwickelt. Einer der treibenden Ingenieure hinter dieser Entwicklung war Ohno Taiichi. Er veröffentlichte 1978 sein Buch „Toyota Production System“ und revolutionierte damit zunächst das produzierende Gewerbe, und bis heute auch die Art und Weise wie zahlreiche andere Branchen ihre Produkte entwickeln, herstellen und ausliefern.

Der zentrale Aspekt der Toyota-Produktionssystems ist die Eliminierung aller Arten von Verschwendung. Eine Produktion solle nichts tun, was nicht der Wertschöpfung dient. Hierzu zählt unter anderem die überflüssig lange Lagerung von Zwischenprodukten, Vorratsproduktion oder unnötige Produktion von Auss chuss. Die Kernelmente des TPS sind heute allgegenwärtig: Kanban, Just-In-Time-Produktion und das Kaizen-Prinzip.

Ein zentrales Prinzip in der Anwendung dieser Elemente ist das Pull-Prinzip. Bis zur Einführung des TPS produzierten viele Betriebe in einem Push-System. Hierbei wurden technische Innovationen die Wertschöpfungskette hinunter geschoben, unabhängig davon ob es dort tatsächlichen Bedarf gab oder nicht.

… und Heute

Heute funktionieren Produktionsketten nach dem umgekehrten Prinzip. Es wird nichts mehr produziert was nicht vorher am Ende der Wertschöpfungskette, vom Kunden (wer auch immer das sein mag) bestellt wurde. Dies resultiert nicht nur in hocheffizienten Wertschöpfsungströmen, sondern auch im Just-in-Time-Prinzip. Wenn der nicht-wertschöpfende Anteil an der Fertigungszeit reduziert werden soll, dann darf es keine Zwischenlager mehr geben und jedes Bauteil muss genau zum Zeitpunkt seines Bedarfes am Arbeitsplatz eintreffen. (Dieses Prinzip haben heutige Automobilbauer bis auf ihre Lieferketten ausgedehnt, und so befinden sich die Zwischenlager heute in Form rollender LKW auf den Autobahnen.)

Mit Einführung agiler Entwicklungsmethoden in der Produkt- und insbesondere der Softwareentwicklung gegen Ende der 1990er Jahre rückten auch die Methoden der Lean Production in den Fokus des Interesses. Besonders Kanban findet, in mehr oder weniger ausgeprägter Form, Anwendung in der Umsetzung von Entwicklungsprozessen. Der Entwicklungsprozess wird hierbei als Value Stream interpretiert welchen Arbeitspakete durchlaufen müssen um, nach ihrer Veröffentlichung, zum Kunden zu gelangen.

Intransparente Task Boards

Teams verwenden häufig Kanban Boards zur Visiualisierung ihrer Arbeitspakete und ihres Workflows. Dies ist eine hervorragende Möglichkeit um Transparenz zu schaffen. Es stellt sich nun aber die Frage wie ein Teammitglied erkennen kann, welche Work Items bereit sind den Value Stream hinab propagiert zu werden, denn in der Praxis sehen die Boards häufig so aus wie im folgenden Bild dargestellt.

 

 

Die einzelnen Zustände der Arbeitspakete werden als Spalten dargestellt. Die Arbeitspakete werden auf Post-Its oder Magnetkarten geschrieben. Im Anschluss werden diese auf der Tafel den jeweiligen Zuständen zugeordnet, sodass man auf den ersten Blick erkennen kann wie weit ein Arbeitspaket in seiner Bearbeitung fortgeschritten ist.

Unglücklicherweise kann man das auf einem derart gestalteten Task Board aber gar nicht erkennen. Was bedeutet denn „in Review“? Ist der Entwicklungsteil abgeschlossen und das Review kann beginnen? Ist das Review gerade im Gange? Ist das Review eventuell sogar schon abgeschlossen und die Qualitätssicherung kann mit ihrer Arbeit beginnen? Wer weiß …

Abrbeitspakete Werden Gepusht, und Nicht Gepullt

Da sich nicht erkennen lässt wie der Bearbeitungszustand der einzelnen Arbeitspakete ist, ist es für die Teammitglieder auch unmöglich Arbeit den Value Stream hinab zu ziehen. Die einzige Möglichkeit wie ein Paket auf einem solchen Task Board propagiert werden kann ist das Push Prinzip. Der Entwickler zieht sich die Arbeitspakete zwar noch aus dem „ToDo“ nach „in Development“, aber nach Abschluss seiner Arbeit drückt er dieses den Value Stream hinab nach „in Review“. Hierdurch setzt er die nachfolgende Prozesskette unter Druck, denn gegebenfalls kann diese die Pakete gar nicht schnell genug weiter verarbeiten.

Es mangelt hier also an der Transparenz bezüglich des Bearbeitungszustandes der einzelnen Pakete. Dieser Mangel an Transparenz macht es unmöglich das Pull System effizient einzuführen oder zu bedienen. Damit wird das System automatisch zu einem Push-System. Nun werden einzelne Arbeitsstationen tendentiell überlastet, das Sytem verstopft, die Fertigungszeiten steigen und damit auch der nicht-wertschöpfende Anteil an der Zykluszeit eines Arbeitspaketes. Das Team hat sich damit selbst der Möglichkeit beraubt den Arbeitsfluss im Sinne des Lean Development umzusetzen und zu optimieren.

Transparenz Erhöhen Durch Geteilte Spalten

Es gibt aber eine einfache Lösung für das dargestellte Problem. Diese erhöht nicht nur die Transparenz im Entwicklungsprozess deutlich, sondern erlaubt die Umsetzung der Entwicklungsarbeit als echtes Pull-System. Die Lösung liegt in einer transparenteren Visualisierung des Bearbeitungsstandes der einzelnen Arbeitspakete. Hierzu teilen wir die Spalten auf dem Task Board so auf, dass ersichtlich wird welche Arbeitspakete sich tatsächlich in aktiver Abarbeitung befinden („Doing“), und welche Pakete bereits abgeschlossen sind („Finished“). Hierbei wird absichtlich der Begriff „Finished“ verwendet, denn der Begriff „Done“ bezieht sich besonders in Scrum-Teams nur auf den abschließenden Bearbeitungsschritt.

 

 

Diese Aufteilung der Spalten erlaubt nun eine konkrete, transparente Aussage über den Zustand der einzelnen Arbeitspakete. Ein Paket in der Spalte „Development Finished“ zu finden ist, ist nun bereit für das Review. Ein Paket in „Review Doing“ wird aktuell einem Review unterzogen. Wenn dieses Review abgeschlossen ist wandert dieses Paket nach „Review Finished“ und ist damit bereit für die Qualitätssicherung.

Da nun erkennbar ist, welche Pakete für die Bearbeitung durch eine nachfolgende Station bereit sind, müssen diese auch nicht mehr von ihren Bearbeitern den Value Stream hinab geschoben werden. Nun ist es möglich, dass sich eine Arbeitsstation die Pakete aus dem Vorrat der bereit stehenden Pakete selbst zieht.

Wo man in Einem Pull System Seine Nächste Aufgabe Findet

In einem Produktionsbetrieb beantwortet sich die Frage woher eine Arbeitsstation ihr nächstes Paket findet meist von selbst. Im Normalfall kommen diese nacheinander über das Fließband gefahren und jegliches Nachdenken über Prioritäten und Bearbeitungsreihenfolgen entfällt.

In cross-funktionalen Entwicklungsteams stellt sich diese Situation allerdings anders dar. Hier übernehmen Entwickler oftmals mehrere Aufgaben in einem Team. Nach Abschluss einer Aufgabe stehen sie also vor der Frage welche Aufgabe sie als nächstes bearbeiten sollten.

 

 

Wie bereits beschrieben ist es die zentrale Absicht des Lean Management die nicht-wertschöpfende Zeit aus der Produktionskette zu eliminieren. Dies gilt auch für Systeme des Lean Development. Um diese Zeit zu reduzieren ist es notwendig, dass Arbeitspakete möglichst schnell nach Abschluss eines Arbeitsschrittes den Value Stream hinab gezogen werden um weiter bearbeitet zu werden. Damit ergbit sich ein simples, aber effiktives Vorgehen bei der Suche nach der nächsten Arbeitsaufgabe. Ein Teammitglied sucht sich seine nächste Aufgabe vom Ende des Value Streams an stromaufwärts. Die erste Aufgabe für welche er über die notwendigen Kenntnisse verfügt ist dann sein nächstes Arbeitspaket. Dies reduziert nicht nur die Zykluszeit des Arbeitspaketes, sondern liefert auch schnelle Ergebnisse und damit schnelles Feedback.

Ein Einfaches Beispiel

Bezogen auf unseren exemplarischen Value Stream ergeben sich also die folgenden Ansatzpunkte für die verschiedenen Teammitglieder:

 

 

 

• der Product Owner: prüft ob neue Arbeitspakete die QA durchlaufen haben und abgenommen werden können
• der QA Ingenieur: prüft ob neue Arbeitspakete das Review durchlaufen haben und getestet werden können
• der Entwickler: prüft zunächst ob neue Pakete bereit für das Review sind und führt dies dann ggf. durch. Ist dies nicht der Fall prüft er ob neue Pakete bereit für die Entwicklung sind

 

Dieses Vorgehen führt nicht nur zu verkürzten Fertigungszeiten für die verschiedenen Arbeitspakete, sondern verhindert im Idealfall auch das Verstopfen des Systems aufgrund von persönlichen Vorlieben der Teammitglieder. Sollte das Sytem jetzt noch verstopfen, so liegt dies an einem Flaschenhals in der Bearbeitung an der entsprechenden Stell im Value Stream.

Abschließende Gedanken

In der Praxis werden viele agile Entwicklungsumgebungen als Pull-System geplant, aber faktisch als Push-System implementiert. Die Erhöhung der Transparenz im Workflow selbst, aber auch in seiner Visualisierung können hier Abhilfe schaffen. Das erleichtert die Auswahl der „richtigen“ Arbeitspakete durch die Teammitglieder.

Hierdurch wird der nicht-wertschöpfende Anteil an der Fertigungszeit eines Arbeitspaketes reduziert und diese damit ebenfalls gesenkt. Es ermöglicht ebenso ein schnelleres Feedback von stromabwärts liegenden Arbeitsschritten an die Lieferanten stromaufwärts. Die oftmals vorherrschenden Push-Syteme können damit in echte Pull-Systeme transformiert werden. Dies führt zu Reduktion von Druck und Fehlern entlang der Wertschöpfungskette.