Schlaues Zitat #7

„Ich fürchte nicht den Mann, der 10.000 Kicks einmal übte, sondern den Mann der einen Kick 10.000 mal übte.“

~Bruce Lee

Advertisements

Lean Prinzip 5: Perfektion anstreben

Der Duden definiert „Perfektion“ wie folgt: „…höchste Vollendung in der [technischen] Beherrschung, Ausführung von etwas; vollkommene Meisterschaft“. Dieses „etwas“ ist bei Lean die Schaffung eines vollkommenen Wertes für den Kunden ohne jegliche Verschwendung. Dies ist sicherlich eine Vision, die man nie erreichen wird und deshalb sagt dieses Prinzip, dass man zumindest danach streben sollte.

Das Modell zur Kompetenzstufenentwicklung¹ erläutert wie man diese Perfektion erreichen kann. Dieses Modell beschreibt vier Stufen der Kompetenzentwicklung. Diese vier Stufen sind kurz zusammengefast:

  1. Unbewusste Inkompetenz
    Man erkennt seine eigene Inkompetenz nicht. Wenn man beispielsweise noch nie etwas von agiler Softwareentwicklung gehört hat, vielleicht auch weil es sie noch nicht gab, weiß man auch nicht, dass man hier Defizite hat.
  2. Bewusste Inkompetenz
    Man hat von etwas gehört und weiß, dass man es nicht kann und wie es erreicht wird. Man hatte also mal von Agilität gehört, weiß aber, dass man es mit dem vorhandenen Nichtwissen nicht umsetzten kann.
  3. Bewusste Kompetenz
    Man weiß, dass man es kann, man muss sich aber sehr konzentrieren und hohen Aufwand und Energie reinstecken. Man hat also mal eine Scrum Master Zertifizierung gemacht und einige Sprints agil gearbeitet oder z.B. den Führerschein gerade erworben.
    Viele hören dann auf dieser Stufe mit dem Lernen auf. Man hat es grundsätzlich verstanden, aber zum Können fehlt dann noch der letzte Schritt. Im schlimmsten Fall entsteht dann der Duning-Kruger-Effekt bei dem Personen unter anderem dazu neigen, ihre eigenen Fähigkeiten zu überschätzen.²
  4. Unbewusste Kompetenz
    Man hat auf dieser Stufe so viel praktische Erfahrung gesammelt, dass es einem keine Mühe bereitet und die Handlungen unbewusst aus einem heraus kommen. Man handelt quasi automatisch ohne nachzudenken, wie wenn man schon jahrelang Auto oder auch Fahrrad fäht.

Perfektion geht dann noch einen weiteren Schritt über die vierte Stufe hinaus. Man ist quasi das Wissen. Man ist Meister seines Faches. Man hat u.U. sein eigens agiles Framework erschaffen oder wie Bruce Lee seinen eigenen Kampfkunststil.

Das Durchlaufen dieser 4 Stufen ist schon für Individuen beim Thema Agilität nicht gerade einfach. Umso schwerer ist dies bei einer Organisation, die meist mehr ist als die Summe ihrer Individuen.
Hier empfiehlt es sich nach dem PDCA Zyklus (Plan-Do-Check-Act) nach Deming vorzugehen um eine Lernkultur im Unternehmen zu etablieren. Das heißt eine Inkompetenz wird aufgedeckt und ein Vorgehen erarbeitet. Das Vorgehen wird dann überprüft und geschaut ob weitere Schritte nötig sind eine Kompetenzstufe höher zu kommen.

Hat die Organisation mit allen Individuen dann irgendwann die 4. Stufe hinsichtlich lean und agil erreicht, sollte sich eine Lösungskultur (Kaizen Kultur) einstellen, in der, wenn ein Fehler von jemandem entdeckt wird, dieser Fehler direkt gelöst oder zumindest adressiert wird ohne groß nachzudenken.


  1. Komptenzstufenentwicklung: https://de.wikipedia.org/wiki/Kompetenzstufenentwicklung
  2. Dunning-Kruger-Effekt: https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt

Lean Prinzip 4: Das Pull-Prinzip einführen

„Pull“, zu Deutsch „ziehen“, bedeutet im Sinne von Lean, dass Aufgaben in einem wertschöpfenden Prozess von einem Schritt in den nächsten gezogen werden. Das heißt ein nachgelagerter Schritt zieht sich die Aufgaben/Materialien/Informationen aus dem vorherigen.
Im Gegensatz dazu werden beim „Push“-Prinzip Aufgaben durch Planungsvorgaben in den Prozess hineingedrückt.

Das Pull-Prinzip orientiert sich somit vielmehr an einem „Outcome“ als an einem „Output“. Diese zwei Wörter hören sich sehr ähnlich an, meinen aber was ganz unterschiedliches.
„Output“, die „Ausbringung“, richtet sich auf die erbrachte Leistung und misst das Projekt rein an den Dingen, die in das Projekt eingebracht wurden. Dies sind meist Ressourcen, Zeit und Budget.
„Outcome“, also „Ergebnis“, misst demgegenüber den direkten Nutzen des Produktes bzw. Projektergebnisses und befasst sich nicht primär mit der Steigerung der Produktivität, noch werden hier Ressourcen bis ins Kleinste geplant.
Das heißt das Push-Prinzip fordert eine 100% Auslastung der Maschinen bzw. Menschen. Das Pull-Prinzip fordert einen ganzheitlichen Nutzen des Ergebnisses bzw. des hergestellten Produktes. Hier muss man seinen Blick also einmal um 180 Grad drehen und von hinten auf den Prozess schauen.

Des Weiteren lehnt sich das Pull-Prinzip vor allem bei agilen Methoden an der Theorie Y an und das Push Prinzip an der Theorie X. Diese Theorien wurden in den 60er Jahren von Douglas McGregor formuliert.¹
Bei der Theroy X wird davon ausgegangen, dass Menschen versuchen Arbeit aus dem Weg zu gehen und alles tun um sie zu vermeiden und dazu keine Verantwortung übernehmen wollen. Die meisten Führungskräfte reagieren darauf mit einem autoritären Führungsstil im Command-and-Control-Modus. In dieser Theorie kann man Menschen eigentlich nur mit finanziellen Anreizen motivieren, z.B. Boni. Dies führt meist im Umkehrschluss dazu, dass Leute unmotiviert sind und keine Verantwortung übernehmen wollen, was die Theorie X weiter bestätigt.
Die Theorie Y geht genau den anderen Weg. Hier werden Menschen als arbeitsam angesehen, für die Arbeit etwas Grundsätzliches ist und darin aufgehen wollen und können. Sie übernehmen dazu Verantwortung für ihr Handeln und wollen kreativ arbeiten. Anerkennung und Selbstverwirklichung sind hier die Motivatoren.
Hier gilt es also auch, einmal komplett anderes herum auf die Dinge zu schauen.
Diese Beschreibung ist natürlich eine vereinfachte Welt in schwarz-weiß. Oft liegt die Wahrheit wohl genau dazwischen. Trotzdem zeigt es die unterschiedliche Weltanschauung verschiedenster Managementmethoden sehr gut auf.

Mit welchen Methoden schafft man es das Pull-Prinzip einzuführen? Neben Mitteln wie Kanban Boards und Work-in-Progress-Limits, bzw. einiger anderer agiler Methodiken, ist hier das Management gefragt. Es sollte ein Arbeitsumfeld herrschen, in dem Respekt, Kollaboration, Lernkultur, Fokus auf Wertschaffung, Anpassung auf Veränderung und Verantwortungsübernahme gelebt werden.
Ein guter Führungsansatz ist der Facilitative Leadership Approach. Dieser beinhaltet sehr kurz gefasst folgende Eckelemente, um eine wirkliche Selbstorganisation zu etablieren, die essentiell für eine agile und leane Arbeitsweise ist:

  • Eine Vision als Richtung vorgeben
  • Werte als Rahmen stecken
  • Moderierend führen
  • Rolle eines Mentors einnehmen
  • Demotivatoren beseitigen, z.B. langsame Computer und Internetleitung, sinnlose Meetings abschaffen usw.
  • Freien Zugang zu Informationen und Materialien

„If you are going to do TPS you must do it all the way. You also need to change the way you think. You need to change how you look at things.“ ~Taiichi Ohno (Erfinder des Toyota Productions System (TPS), dem Vorreiter von Lean)


  1. X-Y-Theorie: https://de.wikipedia.org/wiki/X-Y-Theorie 

 

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

Lean Prinzip 2: Den Wertstrom identifizieren (Teil 2)

Wie im letzten Blogpost Lean Prinzip 2: Den Wertstrom identifizieren (Teil 1) angekündigt, möchte ich mich nun dem Spaghetti Digramm widmen. Dieses Diagramm stammt wie auch das Value-Stream-Mapping / Wertstromanalyse aus dem Produktionsbereich. Es dient auch der Visualisierung des Prozesses / Arbeitsablaufes, nur aus einem anderen Blickwinkel. Hier geht es nicht darum, welches Schritte, mit welchen Zeiten durchlaufen werden, um Informationen bzw. Produkte anzufertigen, zu veredeln und auszuliefern. Es geht darum wohin diese transportiert werden und wie oft.

Ich möchte dies wieder an dem Beispiel Urlaubsantrag verdeutlichen. Wir werfen nochmal eine Blick auf den finalen Wertstrom vom letzten mal:

IMG_20170526_114748

Hier habe ich extra unterschiedliche Post-it-Farben für die unterschiedlichen Bearbeiter verwendet. Dies sind 4 verschiedene (Kann man auf dem Bild leider nicht so gut erkennen). Ich nehme nun die gleichen Farben und schreibe jeweils das Team / Abteilung / Person usw. drauf. Diese sind:

  • Die Person die Urlaub beantragen möcht
  • Die Team-Kollegen
  • Der Vorgesetzte
  • Die Personalabteilung

Diese Post-its klebe ich wieder auf ein Whiteboard. Dies kann man im Idealfall so machen, wie die Abteilungen auch räumlich verteilt sind. Weiter entfernte Abteilungen/Kollegen klebe ich auch etwas weiter auf. Dann zeichne ich für jede Interaktion zwischen den Beteiligten einen Strich. Dies sieht dann wie folgt aus:

IMG_20170623_150316

Die Interaktion zwischen der Urlaub nehmenden Person und den Teamkollegen beinhaltet z.B. mehrere Striche, da hier mehrere Kollegen befragt werden, ob sie als Vertretung in Frage kommen können.

Das Spaghetti Diagramm entfaltet seine ganze Kraft aber eher bei komplexen Vorgängen mit z.B. mehreren Abnahmerunden, Delegationen, mehrere Standorte/Länder usw. Es ist also ein mächtiges Werkzeug um den Fluß von Informationen und Gütern zu verbessern. Dies könnte dann so ausehen:

IMG_20170623_150501.jpg

Dies ähnelt dann schon mehr einem Teller Spaghetti.

Wie man nun diese Ergebisse der beiden Blogposts zum Theme Identifizierung des Wertstroms nutzen kann, um Arbeit zu minimieren, die keinen Wert für den Kunden schafft, werde ich in einem zukünftigen Blogpost zum 3. Prinzip von Lean „Das Fluss-Prinzip umsetzen“ erläutern.

D.h. wir wollen versuchen die 57 Minuten aus der 3-57 Regel wesentlich zu minimieren (siehe Lean Prinzip 2: Den Wertstrom identifizieren (Teil 1)). Hier gilt die Faustformel: Für alle 15 Minuten die wir die nicht wertschöpfende Arbeit von einer Stunde minimieren, verdoppelt sich die Produktivität und dies führt zu 20% Steigerung der Gewinnmarge  (15-2-20 Regel).

Mahlzeit! und bis zum nächsten mal.