Lean Prinzip 3: Das Fluss-Prinzip umsetzen

In den beiden vorherigen Blogbeiträgen zur Identifizierung des Wertstroms (Teil 1 und Teil 2) habe ich versucht aufzuzeigen, wie man den Strom der wertschöpfenden Arbeit in einer Organisation identifizieren kann. Wie man quasi eine Landschaftskarte rund um einen Fluß, der sich durch die organisatorische Landschaft schlängelt, aufzeichnet.

Nun geht es darum die Landschaft so anzupassen, dass der Fluß möglichst schnell fließt. Dies ist oft eine schwierige und mühselige Aufgabe, aber wie schon Konfuzius sagte „Der Mann, der den Berg abtrug, war derselbe, der anfing, kleine Steine wegzutragen.“ Nur so wird es gelingen.
Ich möchte euch in diesem Blogbeitrag einige Hilfsmittel aufzeigen, wie diese Steine, Kurven und Wasserfälle im Flussverlauf abzutragen sind.

Batch / Inkrement-Größe

Zunächst gilt es wie bei dem Berg, Arbeitspakete, Projekte, Produktteile und so weiter, so klein wie möglich einzuteilen und dabei möglichst gleich große Einheiten zu bekommen. Ein Scrum Team z.B. wird irgendwann ein Gefühl dafür entwickeln, wann eine User Story/Anforderung zu groß ist und kann dies in ihre Definition of Ready aufnehmen. Dies kann z.B. der Fall sein, wenn eine Story mehr als 8 Story Points hat.

Stories kleiner zu schneiden ist für Scrum Team gerade am Anfang oft nicht sehr einfach. Ich möchte euch hier einige Links zu Methoden zur Verfügung stellen, von Kollegen, die sich dazu bereits gute Gedanken gemacht haben.

  • Dimensional Planning
  • Eine andere Art der Dimension, die ich persönlich besser finde ist folgendes Schaubild:

MVPDas „zerschneiden“ der Anforderung vom Auto hin zum Skateboard könnte man auch gut als eigenen Schitt auf einem Scrum oder Kanban Board einbauen.

Fazit: Das Ziel sollte sein, Arbeitspakete möglichst klein zu bekommen, da diese schneller fließen. Dies macht man aber natürlich auch mit dem Hintergrund, Komplextät rauszunehmen.

Es existieren auch Berechnungsmethoden, ab wann eine Anfoderung klein genug ist, mit Werten wie Transactional Cost, Total Coasts usw. Ich empfehle hier aber das kollektive Bauchgefühl und Menschenverstand. Irgendwann sagt sich ein Team, dass die Anforderungen zu klein sind und der Aufwand sie klein zu kriegen, viel zu groß ist, als dass es ein Gewinn wäre.

Wissensinseln

Ein weiterer wichtiger Schritt den Fluß zu beschleunigen sind Wissensinseln bzw. Kompetenzzentren, die oft bei nur einer Person liegen, aufzulösen. Ist diese Person z.B. gerade nicht da, staut sich der Fluß und man wartet bis es weiter geht.

Wissensinsel aufzudecken und zu beseitigen kann man mit einem „Market of Skills“. Mehr dazu unter: https://blog.crisp.se/2012/11/06/anderslaestadius/team-liftoff-with-market-of-skills-and-competence-matrix
Desweiteren lassen sich in einem Software-Entwicklungsteam durch Pair oder Mob Programming Wissensinsel abbauen und Wissen verteilen. Dazu ergeben sich noch viele weitere Vorteile, mit denen sich Verschwendungen vermeiden lassen. Zum Beispiel werden weniger Fehler gemacht und Bugs produziert.

WIP-Limits

Einer der wichtigsten Booster für die Verkürzung der Durchlaufzeit ist ein Limit der angefangen Arbeit, kurz WIP Limit (WIP = Work in progress). Die Kanban Methode beinhaltet diese bereits als Kernpraktik. Bei Scrum wird diese Methode häufig genutzt, ist aber kein grundsätzlicher Bestandteil.

Oft fehlt es den Beteiligten an Verständnis, warum einen Limitierung der angefangenen Arbeit zu schnelleren Ergebnissen führt, da es einseitig betrachtet, ineffizient wirkt. Als Beispiel nenne ich oft das Verschicken von Rechnungen auf Papier. Als Student habe ich selbst in einem Team mehrere Tausend Rechnugen für ein Unternehmen manuell eingetütet, mit Briefmarken versehen und verschickt.
Hier empfiehlt sich wider Erwarten der Single-Piece-Flow. D.h. eine Rechnung nach der anderen. Sprich, eine Rechnung falten, in einen Briefumschlag stecken, zukleben, wiegen und mit der richtigen Briefmarke versehen.
Eine andere Methode wäre: Erst alle fallten, dann in eine Briefumschlag stecken und so weiter, da man ja unter anderem bei jedem Schritt, wenn man in ständig hintereinander ausführt, effizienter wird. Dies ist ein Fallstrick, da Fehler oft nicht bercksichtigt werden. Zudem könnte jede fertige Rechnung schon rausgeschickt und bezahlt werden. Nicht aber, wenn erst alle Rechnungen gefaltet werden.
Ein Video was dies verdeutlich ist auf Youtube zu finden: https://www.youtube.com/watch?v=Dr67i5SdXi

Single Piece Flow, also z.B. eine User Story nach der nächsten, ist natürlich eher eine Vision und ausser beim Mob Programming kaum zu erreichen. Es macht auch oft keinen Sinn. Man sollte aber trotzdem versuchen sein WIP Limit immer weiter zu minimieren. Ein weitere Grund dafür ist auch die Vermeidung von Task Switching, was zu Verschwendung führt.

Vermeidung von Verschwendung ist ein weiterer sehr wichtiger Punkt das Fluss Prinzip umzusetzen. Bei der Software Entwicklung existieren 7 Verschwendungsarten, wobei Task Switching explizit eine eigene ist. Dieser Sache möchte ich einen seperaten Blogartikel widmen, da dieser Teil sehr umfänglich ist.

Große Skepsis gegenüber WIP-Limits kommt auch oft von Projektleitern und Managern. Die Ursache ist, dass man oft noch versucht auf einen Auslastung von 100% zu optimieren. Menschen kann man aber nicht wie Maschinen behandeln. Menschlichkeit ist bei agilen Methoden ein zentraler Aspekt.

Gehen wir mal von dem Fall aus, dass ein WIP-Limt erreicht ist und Team-Mitglieder nun blockiert sind. Was passiert jetzt. Im Gegensatz zu den Verfechtern der Theory X die jetzt davon ausgehen würden, dass Leute nur noch Youtube-Videos schauen oder Nickerchen machen, gibt es Menschen und ich bin der Meinung, dass das die Mehrheit ist, die sich nun darum kümmern das Problem, welches für den aufgetretenen Arbeitsstau verantwortlich ist, zu lösen. Des weiteren können sie sich fortbilden, ihre Arbeit ggf. durch Automatisierungen optimieren, mal mit anderen Menschen ausserhalb des Teams sprechen, sich mit dem Kunden beschäftigen und und und. So viele Sachen die einen Wert schaffen können. Dieses „über den Tellerand hinausschauen“ würde mit einer 100%-Auslastung nicht passieren.

Automatisierung

Jegliche wiederkehrende, manuelle Arbeit gilt es bei Lean zu automatisieren. Automatiserung beschleunigt den wertschöpfenden Prozess ungemein. Ein Nebeneffekt dabei, den man nicht vernachlässigen sollte, ist die Erhöhung der Qualität. Je weniger menschlicher Einfluss vorhanden ist, desto höher die Qualität. Menschen machen nun mal Fehler.

Automatisierung, auch von kleinen Dingen, wirkt kurzfristig erst mal langsam und klingt nach mehr Aufwand. Langfristig gesehen ist dies der Raketentreibstoff jeglicher Produktentwicklung.

Automatisierung, vor allem Continuous Delivery/Deployment, ist ein weiteres umfassendes Thema zu dem es viele Bücher und Meinungen gibt. Ich möchte es hier erst mal dabei belassen, dass es ein wichtiger Teil ist lean und agil zu werden.

Poka Yoke

Der japanische Ausdruck Poka Yoke (jap. ポカヨケ, dt. „unglückliche Fehler vermeiden“) bezeichnet ein aus mehreren Elementen bestehendes Prinzip, welches technische Vorkehrungen bzw. Einrichtungen zur sofortigen Fehleraufdeckung und -verhinderung umfasst.1

Für Poka Yoke muss man sicherlich schon wirklich ein sehr tiefes Verständnis von Lean besitzen. Eine Umsetzung bei Software Entwicklung könnte ich mir in den folgenden Berichen vorstellen:

  • Das Produkt selbst schon so designen, dass der Kunde möglichst wenig Fehler machen kann. Beispiel Bankautomat: Hier muss man erst die Karte rausziehen, bevor das Geld ausgegeben wird.
  • Einsatz von Sonar Qube um Flüchtigkeitsfehler im Code zu vermeiden
  • Unittests
  • Automatisierte (Regressions-)Tests

Queues und Backlogs verkleinern

Wo immer sich Informationen aufstauen und nicht fließen, sollte man sofort Maßnahmen ergreifen, diese zu lösen. Nehmen wir das Beispiel E-Mail Inbox. In manchen Firmen gilt die Anzahl der E-Mails, die man während seines Urlaubs bekommt, schon als eine Art Statussymbol. Eigentlich sollte dies genau anders rum sein.

Ich bin nicht unbedingt ein Fan der InboxZero Methode, finde aber, dass es in die richtige Richtung geht. Mit dem richtigen Mailprogramm kann man dazu sehr viel automatisieren.

Für firmeninterne Kommunikation sollte man eher andere Tools benutzen wie Slack, welches ich sehr empfehlen kann (slack.com).

Geht man in den Urlaub, kann man in seiner Abwesenheitsmail auch einfach reinschreiben, dass man die E-Mails nicht beantworten wird und in dringenden Notfällen einen Kollegen informiert oder nach dem Urlaub noch mal schreiben sollte, da die E-Mails ungelesen verschoben werden. Wenn man dies freundlich schreibt, haben bestimmt die meisten Verständnis, da sie es selber kennen und man glaubt nicht wie viel sich tatsächlich dann selbst erledigt.

Backlog von Features sollte man regelmäßig pflegen und aufräumen. Dies kann man auch automatisieren. Man schließt z.B. alle Tickets, die länger als 6 Monate nicht angefast wurden. Seien wir mal ehrlich: Alles was so alt geworden ist, hatte niemals eine hohe Wichtigkeit und Dringlichkeit und wird diese vermutlich auch nie bekommen. Falls doch, sollte ein neues Ticket erstellt werden. Meist sind die Informationen in dem ursprünglichen Tickets sowieso veraltet. Am Anfang ist das natürlich nicht einfach, gerade für diejeniegen, die diese Tickets geschrieben und viel Zeit drauf verwendet haben. Aber es wird sich einspielen, wenn man die positiven Erfolge sieht, dass andere Aufgaben viel besser durch den Wertschöpfungsprozess fließen.

Verschwendung minimieren

Muri, Mura und Muda sind 3 (japanische) Begriffe aus dem Toyota-Produktions-System die sich dem Thema Verschwendung und Verursachung von Verschwendung widmen. Dieses Thema ist durchaus ein wichtiges Thema um den Fluss zu beschleunigen und Ich schreibe deshalb, wie schon erwähnt ,seprarat in einem zukünfitgen Blogpost darüber.

 


  1. https://de.wikipedia.org/wiki/Poka_Yoke

Cynefin-Framework – Mit Komplexität im Projektmanagement umgehen

Pflanzt man einen Baum und versucht vorherzusehen und aufzuzeichnen wo jeder Ast und jedes Blatt wachsen wird, wird man scheitern.

Die Faktoren die man kennt oder auch noch nicht kennt, die dazu führen wie der Baum wächst, sind einfach zu komplex um sie zu verstehen. Erst im Nachhinein kann man vielleicht den ein oder anderen Rückschluss ziehen. Pflanzt man aber eine gleiche Art Baum, wird dieser aber wieder anderes wachsen und die Rückschlusse, die man gezogen hat, sind unbrauchbar.

Und so verhält sich das auch mit vielen Projekten, vor allem im IT-Bereich. Aber nicht nur dort. Viele Bereiche im heutigen Leben werden immer komplexer.

Ein Framework und weitere Tools die dabei helfen sich können sich in komplexen Projekten zurecht zu finden, findet ihr in der folgenden Präsentation von mir, die ihr gerne weiter verwenden dürft.

https://prezi.com/view/tg7nFMT5Eo1PfeKKd9KS/embed