Think, Make

Schlagwort: Agile

  • „Home Office“ vs. Agile

    Exec Summary

    Das Home Office wird gerne als der wünschenswerte Zielzustand des durchdigitalisierten modernen mobilen Arbeitsplatzes gesehen.

    Im Folgenden werde ich „Home Office“ ohne Anführungszeichen schreiben, obwohl der Begriff für Native English Speakers eher mit dem Innenministerium verbunden ist.

    Die Corona-Pandemie hat bewiesen, dass erhebliche Anteile der Dienstleistungsarbeitsplätze im Home Office möglich sind.

    In diesem Text zeigen wir, dass dieser Home-Office-Arbeitsplatz agilen Kernwerten widerspricht.

    Home Office ist eben grundsätzlich von teamweise an einem Ort arbeitender Beschäftiger zu unterscheiden. Diese Form wird Verteiltes Arbeiten genannt.

    Dieser Art des Verteilten Arbeitens wird hohe Agilität und damit eine erhebliche Wertgenerierung unterstellt. Zudem erzeugt diese Form des Verteilen Arbeitens noch andere (in einem anderen Text betrachteten) Effekte:

    • Drastische Reduktion des Pendelverkehrs.
    • Reduktion des Bürobedarfs in Hochpreis-Arealen.
    • Wiederbelebung der Unterzentren.
    • Work-Life-Balance insbesondere für junge Familien.

    Arbeitshypothesen

    Individuals and Interactions over processes and tools

    https://agilemanifesto.org

    Meine Arbeitshypothesen aus Satz 1 des Agile Manifestes sind:

    • Computer sind Tools. Menschen sind Individuen.
    • Dass Menschen miteinander interagieren ist wichtiger als einen guten Jira-Workflow zu haben.
    • Seiner Kollegin wortlos etwas in den (elektronischen) Eingangskorb zu legen, ist keine Interaktion.
    • Interaktion ist Kommunikation. Computer als Interaktionspartner sind prinzipiell rückkopplungsarm, daher ist eine zweifach indirekte Interaktion (auf Senderseite und dann noch einmal auf Empfängerseite) über Computer prinzipiell der direkten Interaktion von Individuen unterlegen.

    Zusammengefasst gilt:

    Die beste Interaktion ist eine direkte Interaktion.

    Working software over comprehensive documentation

    https://agilemanifesto.org

    Meine Arbeitshypothesen aus Satz 2 des Agile Manifestes sind:

    • Umfangreiche Dokumentationen werden in isolierter Einzelarbeit erstellt.
    • Dass Software funktioniert, erkennt man am besten, indem man sie ausprobiert, testet, mit ihr interagiert.
    • Das etwas funktioniert, findet man am besten in einem Team von Fachleuten heraus, nicht, indem man das dem einzelnen (sic!) Entwickler überlässt.

    Zusammengefasst gilt:

    Funktionierende Software existiert erst dann, wenn die Funktionstüchtigkeit (jemandem, durch jemanden) gezeigt wurde.

    Customer collaboration over contract negotiation

    https://agilemanifesto.org

    Meine Arbeitshypothesen aus Satz 3 des Agile Manifestes sind:

    • Jeder Abnehmer eines Produktes/Artefaktes ist in diesem Sinne Kunde.
    • Ein Vertrag verschriftlicht Anforderungen aneinander. Vertragsverhandlungen sind Interaktionen über den Inhalt gegenseitiger Anforderungen. D.h. es wird mit einem Vertrag „über Bande“ gespielt.
    • Der direkte Austausch ist oft besser als eine ausgehandelte Verschriftlichung.

    Zusammengefasst gilt:

    Verträge liefern oft notwendige Leitplanken für gute Zusammenarbeit. Gute Zusammenarbeit geschieht aber am besten über möglichst unmittelbaren Austausch.

    Responding to change over following a plan

    https://agilemanifesto.org

    Meine Arbeitshypothesen aus Satz 4 des Agile Manifestes sind:

    • Veränderungen sind Teil der Realität.
    • Ein Plan ist ein statisches Zielmodell über die Zukunft.
    • Je schneller und je besser ich auf Veränderungen reagiere, umso besser wird mein Produkt.
    • Veränderungen bekomme ich nur mit, wenn ich permanent und schnell interagieren kann.
    • Aus Veränderungen resultieren sofort Planänderungen. Aus Planänderungen resultieren sofort Änderungen der Arbeitspakete, d.h. der Aufgaben jedes Teammitgliedes.
    • Nur die direkte Interaktion stellt sicher, dass die Betroffenen die Veränderung registriert und verstanden haben. Nur die direkte Interaktion stellt sicher, dass die betroffenen eine Planänderung registriert und verstanden haben.

    Zusammengefasst gilt:

    Auf Veränderung reagiere ich am besten schnell. Direkte Interaktion liefert die schnellste Reaktion. Planänderungen sind Veränderungen.

    Argumente gegen das Home Office

    Home Office erfüllt die Voraussetzungen für agile Zusammenarbeit aus den folgenden Gründen nur schlecht:

    • Direkte Kommunikation, d.h. Interaktion ist im Home Office prinzipiell nicht möglich.
    • Die Interaktionsqualität wird maßgeblich von den eingesetzten Werkzeugen bestimmt und nicht durch die Qualifikation der Beschäftigten.
    • Veränderung wird immer gefiltert und verzögert registriert, womit auch die Antwort auf Veränderung gefiltert und verzögert eintritt.

    Argumente für Verteiltes Arbeiten

    Verteiltes Arbeiten als Arbeiten in einem Team am gemeinsamen Ort erfüllt alle Voraussetzungen für agile Zusammenarbeit aus den folgenden Gründen perfekt:

    • Team-Interaktion ist jederzeit von Angesicht zu Angesicht möglich.
    • Die Qualität der Interaktion ist nicht mehr werkzeugabhängig.
    • Über Werkzeuge besteht immer noch die Möglichkeit der Fernkommunikation.
    • Veränderung wird sofort registriert, womit auch die Antwort auf Veränderung so schnell wie möglich eintreten kann.
    • Mit Heimarbeit auftretende arbeitsrechtliche Probleme gibt es nicht.
    • Neben diesen unmittelbaren Vorteilen für agiles Arbeiten gibt es noch viele weitere Vorteile:
      • Wegfall von Pendelzeit, wenn die Teams wohnortbezogen entwickelt und aufgestellt werden.
      • Wiederbelebung von Unterzentren.
      • Weniger Bürokosten in den hochpreisigen Oberzentren.
      • CO2-Einsparung.
      • Work-Live-Balance durch Möglichkeit, zwischendurch für Kind oder Freizeit die Arbeit zu unterbrechen.

  • Was heißt eigentlich Lean?

    Lean heißt wörtlich knapp, mager, manchmal sogar arm, es könnte auch mit schlank übersetzt werden. Aber Lean in diesem Sinne meint es im Sinne von Lean Production, also im Sinne von John F. Krafcik, der den Begriff Lean als Gegensatz zu Buffered positionierte – und auch im Sinne des Toyota Production Systems (TPS) nach Taiichi Ohno und Kiichiro Toyoda.

    Krafcik sah, dass die westlichen Produktionssysteme Puffer für alles und nichts vorhielten. Sie konnten Fertigungsschwankungen durch einen hohen Personalüberhang ausgleichen, sie konnten Fertigungsmängel mit Lagerhaltung kompensieren, sie hatten riesige Reparaturwerkstätten, um die hohen Fehlerrraten zu kompensieren, sie konnten zeitliche Schwankungen durch Verlangsamung ausgleichen. Kurz: Sie waren fett.

    Lean im Gegensatz dazu war schlank, mit wenigen Gütern in den Lägern, mit kurzen Fehlererkenungs- und -reaktionszeiten, mit weniger Personal, mit einem Fokus auf Qualität, um Reparaturzyklen zu minimieren. Kurz: Lean (Production) ist nichts anders als das Toyota Production System, verbessert, vervollständigt, verändert und übersetzt in die heutige Zeit.

    Und das Toyota-Production System könnte wie folgt umrissen werden:

    Das Toyota Production System

    Das Toyota-Production System basiert im wesentlichen auf zwei Prinzipien:

    • Just-In-Time
    • Jidōka

    Just-In-Time

    Just-In-Time ist nichts anderes als

    • das Benötigte
    • in richtiger Qualität und Menge
    • zum richtigen Zeitpunkt zu produzieren
    • so dass es zum richten Zeitpunkt verfügbar ist.

    Alles andere sei zu beseitigende Verschwendung. Das Toyota Production System sieht drei Arten von Verschwendung:

    • Muda: Aufgaben verbrauchen Ressourcen, liefern aber keinen Wert.
    • Mura: Prozesse sind mit Schwankungen behaftet.
    • Muri: Prozesse sind überlastet.

    Jidōka

    Das Toyota Production System möchte als zweites Grundprinzip Jidōka realisiert sehen. Jidōka wird von Toyota auch als Automation mit menschlichem Antlitz gesehen und hat im wesentlich folgende Komponenten:

    1. (Automatisches oder manuelles) Feststellen von Anomalien
    2. Stopp der Produktionsmaschinen
    3. Entscheider behebt Grund für das Problem
    4. Verbesserung finden und implementieren.

    Kaizen

    Das Toyota Production System und insbesondere Ohno kämpfen für Kaizen, was in der Regel als kontinuierliche Verbesserung verstanden und damit oft gründlich missverstanden wird. So klärt uns Jun Nakamuro darüber auf, dass Kaizen zwar auch kontinuierliche Verbesserung bedeutet, dass Ohno aber mit diesem Begriff eher die kontinuierliche Verbesserung der Persönlichkeit verband und die rein mechanistisch-technische kontinuierliche Verbesserung mit dem Begriff Kairyo belegte.

    Kaizen steht nach Ohno für das „A“ („Act!“, „Handele!“) in W. E. Demmings PDCA-Zyklus.

    Wir sollten uns also fragen, wie wir in einem geschäftlichen Kontext, zyklisch bei uns selbst und im betreffenden Produktionsprozess erkannte Fehler verhindern, vermeiden und beseitigen und uns und den Produktionsprozess insgesamt laufend verbessern.

    Quellen

    John F. Krafciks Artikel über Lean Production, Fordism und TPS:https://www.lean.org/downloads/MITSloan.pdf
    Ein Kurzüberblick von der Quelle:https://global.toyota/en/company/vision-and-philosophy/production-system/
    Jun Nakamuros Artikel über die sprachlichen Feinheiten des Japanischen im Allgemeinen und Ohnos Verwendung im Speziellen:https://www.linkedin.com/pulse/re-translating-lean-from-its-origin-jun-nakamuro/