Kategorie: Lean

  • The Purpose of Being Agile

    Introduction

    Why, would you think, are we (oh!) so agile? Why do we do Kanban or Scrum?

    a) To have more fun?
    b) To become a better team?
    c) To follow industry standards?

    „Take a wild guess!“

    Laury Anderson

    It is neither of it. To give you a hint, I quote the very first Google hits for „purpose of agile“:

    To me, agile is all about embracing change to make our customers awesome.

    Jezza Sutton in https://www.quora.com/What-is-the-purpose-of-Agile-and-why-are-so-many-companies-using-it

    It puts more emphasis on creativity and innovation that is needed to maximize the business value of the solution

    Chuck Cobb in https://www.quora.com/What-is-the-purpose-of-Agile-and-why-are-so-many-companies-using-it

    Go down the list of all the most successful companies. They are all delivering products faster, better, and cheaper than the competition because they are Agile…

    Jeff Sutherland in https://www.quora.com/What-is-the-purpose-of-Agile-and-why-are-so-many-companies-using-it

    Got it? Good. So, let me summarize it. In the software industry we are Agile, because we want to
    a) deliver products the customers benefit from and thus are willing to buy,
    b) be more efficient (AKA faster, better, cheaper) to gather higher profits (AKA business value),
    c) to stay in the market, because everybody else does it and proves it right.

    Everything else comes second. To be precise about what comes second, third, fourth, or even fifth:
    a) your fun, happiness,
    b) team building,
    c) Good parentship,
    d) work-life ballance,
    e) becoming a better person,
    f) work from home,
    g) healthy snacks.

    All of these points are nice, but basically they are just a means of the primary purposes found above. They are contributing to the primary purposes, or will become obsolete, when management finds out it is not contributing.

    Efficiency vs. Effectiveness

    Efficiency

    Efficiency can be summarized as minimizing waste or „to do things well“. Oh. Waste = Muda, which is a central Kanban term for a good reason.

    Applied to requirements management, the founders of Scrum have found out, it may be less wasteful to replace fixed requirements specifications documents by a volatile and continuously reprioritized, hence more efficient product backlog.

    Applied to team building, intense and immediate collaboration of all required skilled workers seem to be more efficient than silo organizations.

    The push principle puts pressure on your people. Often this leads to errors, stress, unnecessary task switches, low throughput, unpredictable processing times. The promise of the pull principle in conjunction with a limitation of work in progress (WIP-limit) is the exact opposite: Happier workers produce better output more predictable.

    Effectiveness

    Effectiveness can be summarized as „getting the right thing done„.

    This is especially tricky in volatile environments. But one thing should be immediately clear: Long cycle times lengthen the periods of feedback points, which is the main reason why a lot (not all..) of waterfall projects fail to produce good marketable products, especially compared to those with short cycle times, AKA Scrum sprints.

    BTW: in our context efficacy = effectiveness.

    To be continued.

  • A reply on Michael Küster’s agile anti-patterns

    https://failfastmoveon.blogspot.com/2019/07/how-agilists-betray-very-nature-of.html

    While I agree upon the „badness“ of Michael’s anti-patterns, I would like to add some remarks on my reasons, why he is right.

    On Agile projects

    Anti-Pattern

    There’s no such thing as Agile Projects! You must do Product Development!“ – can you even smell how dogmatic and close-minded this is? You’re not inviting a discussion, you’re ending it!

    https://failfastmoveon.blogspot.com/2019/07/how-agilists-betray-very-nature-of.html

    Remark

    Since Scrum is Agile and Jeff Sutherland’s wife Arline is using Scrum for projects in church (cf. https://www.pmi.org/learning/library/agile-project-management-scrum-6269) I don’t care, if some people get angry about “agile projects”.

    For the sad few for whom this is not enough, I would like to add that the PRINCE2 Agile world distinguishes between projects and business as usual (or BAU). While BAU is for ongoing activities with steady teams and more predictable outcome (and PRINCE2 Agile is not applicable), PRINCE2 Agile deals with projects, which in turn deal with uncertainty, complexity, and time boxes.

    On Fixed scope

    Anti-Pattern

    We’re Agile! That’s Big Upfront Design, Waterfall!“ Proposing to make the scope known upfront is met with arrogance and disdain. You wouldn’t even bother to ask,  „what do you mean by fixed scope„, because fixed scope indicates that this person just doesn’t get it.

    https://failfastmoveon.blogspot.com/2019/07/how-agilists-betray-very-nature-of.html

    Remark

    PRINCE2 Agile uses the “fix and flex” concept on six dimensions, and scope is one of them. For scope prioritization it uses the MoSCow technique (Must, Should, Could, Won’t have), meaning that you may flex the should haves and could haves, but should not flex = fix the must haves).

    https://publications.axelos.com/prince2agile2015/content.aspx?page=cros_37&showNav=true&expandNav=true

    A car without an engine is not a car, a car without a sat-nav maybe is not up-to-date (should? could?) but still marketable.

    See also https://cms.vp-consulting.de/prince2-agile/#whattofixandflex

    On Milestone dates & product roadmap

    Anti-Pattern

    We can’t know what or when!“ – calling the request unreasonable and insisting on a free pass for the team. 

    Our stakeholders want to know our product roadmap – what they can expect in the next year or two. A roadmap instills confidence that you know what you’re doing and aren’t getting tossed about by every wind.
     „That’s not Agile„, I hear you scream!

    https://failfastmoveon.blogspot.com/2019/07/how-agilists-betray-very-nature-of.html

    Remark

    Exhibitions typically are fixed and planned events, aligned with different streams and external parties, e.g. presenting at IFA Berlin or CES is very resource intensive, expensive and will affect share prices if you don’t deliver, so deliver the best you can. 

    Which means, keep your core product requirements fixed and flex on the should/could haves.

    In SAFe lingo: continuously re-prioritize your product backlog, having your product roadmap towards the exhibition in mind.

    Progress report

    Anti-Pattern

    We have Reviews, and thus, progress reports are a waste„. The mere suggestion of a progress report obviously means that the individual doesn’t understand agility and the organization wants to preserve status quo.

    https://failfastmoveon.blogspot.com/2019/07/how-agilists-betray-very-nature-of.html

    Remark

    cf. https://scrumguides.org/scrum-guide.html#artifacts-productbacklog and look for “managing progress toward goal”.

    This gives a quite nice hint on what to do: First you have to have a goal. Second: “Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows.”

    As Tom DeMarco once said: “Bad metrics are better than no metrics”.

  • Weighted Shortest Job First (WSJF) and Climate Change.

    Based upon a total distance of 200,000 km, an eGolf driven by electrical energy as of today’s German production situation will produce 142 g/km CO2, a Diesel Golf will product 140 g/km CO2. If an eGolf is „fueled“ by wind energy only, it produces 59 g/km CO2. 

    https://www.welt.de/wirtschaft/article192405223/Klimabilanz-Erst-nach-100-000-Kilometern-ist-der-E-Golf-wirklich-gruen.html

    This is a complete disaster, because no smart person would invest 50 k€ to basically deteriorate his/her carbon footprint. And the 59 g/km are just based on hope, since green energy will just not be available in amounts needed to significantly transform western economy.

    What would a SAFe consultant do? My guess is: a SAFe consultant (I am one…) would apply the WSJF principle: 

    https://www.scaledagileframework.com/wsjf/

    In SAFe the weight is calculated by dividing the Cost of Delay (CoD) by the Duration:

    Weight = CoD / Duration

    The CoD is the sum of user-business value, time-criticality and risk reduction and/or opportunity enablement:

    CoD = user-business value + time-criticality + risk reduction

    where each parameter has a value of 1, 2, 3, 5, 8, 13, or 20.

    WSJF Applied to the eGolf and Possible Alternatives 

    Now, how would a carpool with two people who currently both own a Diesel Golf (solution 1, leading to weight 1) compare to the acquisition of two eGolfs (solution 2)?

    I actually do not know the CoD, but CoD1 should be roughly twice the value of CoD2, since CO2 production of the cars is quite identical and thus are halved in case 1.

    What is not identical is the time to market: The carpool can go live tomorrow, the eGolf has to be ordered and produced in let’s say three month, thus w2/w1 = 90.

    Now, my question is: Why on earth don’t we focus our efforts on carpools instead of electrical cars?!

  • „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/