Methoden zur Verschwendungsvermeidung (Teil 2)

Hat man eine Verschwendung in einer Organisation erkannt und möchte diese beseitigen, kann man hierfür die A3 Methode verwenden, die eine empirische Herangehensweise an ein Problem sehr einfach ermöglicht.

Wie bei vielen Methoden zu Agil und Lean kommt diese auch aus dem Lean Management und wurde im Toyota Produktionssystem entwickelt. Es haben sich auch hier bereits andere Leute schon gute Gedanken gemacht und diese niedergeschrieben, auf die ich hier verweisen möchte:

http://www.ksimons.de/2014/06/hindernisse-dauerhaft-loesen-durch-impediment-management-mit-a3-denken/

Advertisements

Methoden zur Verschwendungsvermeidung (Teil 1)

Einer der Grundpfeiler des agilen Rahmenwerk Scrum und ein essentieller Bestandteil schlanker Organisationen ist Transparenz. Aber was genau ist Transparenz und vor allem wie genau erreicht man eine angemesse Transparenz?

Man kann sicherlich so transparent wie möglich sein, nur sehen dann die Leute den Wald vor lauter Bäumen vielleicht nicht mehr? Ist Transparenz eine Hol- oder eine Bringschuld? Reicht es Informationen in irgendeinem Wiki oder Fileserver abzulegen um dann am Ende sagen zu können „Die Informationen waren ja da, ihr hätte sie euch einfach nur holen müssen“ oder andersherum „Wir wussten von nichts, uns hat niemand informiert“.

Haben Menschen keine oder zu wenig Informationen um Dinge zu entscheiden, die sie  ihren Zielen näher bringt, entsteht Verschwendung. So viel steht auf jeden Fall mal fest. Informationen richtig abzulegen und für jeden übersichtlich zu machen schafft schon mal einen großen Vorteil diese Verschwendung zumindest zu verringern.

Eine bekannte Methode aus dem Lean-Management, Produktionsprozesse zu verbessern, ist das 5S-Prinzip. Dieses Prinzip könnte man wie folgt auch auf das „Lagern“ von Informationen anwenden, z.B. von Projekt- oder Feature-Backlogs.

  • Seiri: Sortiere Benötigtes und Unbenötigtes.
  • Seiton: Ordne ordentlich was übrig geblieben ist.
  • Seiso: Säubere.
  • Seiketsu: Ständige Wiederholung der ersten drei Schritte.
  • Shitsuke: Disziplin die ersten vier Schritte durchzuführen.

Im folgenden möchte ich euch die Umsetzung des 5 S Prinzip anhand eines E-Mail-Postfaches erläutern. Hier geht es dann erst mal um die individuelle Transparenz. Man könnte diese Regeln aber auch organisationsweit einführen.

Sortiere Benötigtes und Unbenötigtes.

Im Idealfall würde man nun alle unbedeutenden E-Mails löschen um Platz zu schaffen. Will man herauszufinden was noch benötigt wird und was nicht, müsste man theoretisch alle E-Mails noch mal durchgehen und diese ordnen. Dazu hat vermutlich aber keiner Lust noch die Zeit. In der heutigen Zeit haben E-Mail-Postfächer auch so viel Speicherplatz, dass man theoretisch auch nichts löschen braucht. In manchen Unternehmen ist es aus Compliance-Gründen auch verboten E-Mails zu löschen.

Für den Rest der E-Mails erstellen wir ein Ablagesystem aus 3 Kategorien:

  1. Arbeit
  2. Referenz
  3. Archiv

Ordne ordentlich was übrig geblieben ist

Alles was alt und nutzlos ist sollte in das Archiv einsortiert werden. Zum Beispiel Einladungen vergangener Meetings, E-Mails zu abgeschlossenen Projekten, Mails von Kollegen, die bereits die Firma verlassen haben und und und.

Mails, die man gelegentlich benötigt um Informationen nachzulesen, wie Usernamen oder die man als Referenz bzw. Template für andere E-Mails benutzt, (z.B. Urlaubsantrag) kommen in den Ordner 2. Referenz.

In den Ordner Arbeit stecken wir alle E-Mails, die wir noch bearbeiten müssen oder die wir regelmäßig benutzen, wie z.B. die Agenda von wiederkehrenden Meetings.

In allen Ordner können natürlich bei Bedarf  Unterordner erstellt werden. Es macht durchaus Sinn in den Ordner Arbeit Unterordner, wie  ToDo, Doing, Done, Parkplatz (Dinge die auf etwas warten) usw. anzulegen.

Dieser Schritt, falls er doch ein wenig Zeit beansprucht, muss auch nicht am Stück ausgeführt werden. Vielleicht 20 Minuten täglich zwischendurch, bis alles sortiert ist.

Am Ende sollten dann max. 20% der E-Mails im Arbeit Ordner abgelegt sein.

Säubere

Dies ist die Aufgabe des IT Suports, die sicherstellen müssen, dass die E-Mail-Server z.B. Exchange sauber laufen und Daten gesichert werden.

Ständige Wiederholung der ersten drei Schritte und Disziplin die ersten vier Schritte durchzuführen.

Um der Entropie entgegenzuwirken sollte man sich am besten pro Tag, Woche oder Monat regelmäßig Zeit nehmen, vielleicht durch einen fest eingestellten Termin (Inbox Refinement), sein Postfach aufzuräumen und E-Mails umzusortieren, zum Beispiel von Arbeit nach Archiv. Diese Zeit sollte man sich auf jeden Fall nehmen, da man dadurch sehr viel mehr Zeit am Ende einsparen kann.

Ein weiterer Effekt der sich dabei einstellt ist ein Zufriedenheitsgefühl über das aufgeräumte Postfach und den besseren Fokus.

Bei einem Produkt-Backlog sind die Effekte der Zeitersparnis und Zufriedenheit noch viel viel größer, weil hier auch viel mehr Leute betroffen sind. Ist allerdings auch eine wirklich harte Nuss, die es sich aber lohnt zu knacken.

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