Think, Make

Kategorie: Agile

  • 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”.

  • A reply to Michael Küster’s article on „When will the Agile Project be done?“

    https://failfastmoveon.blogspot.com/2019/07/when-will-agile-project-be-done.html

    Dear Michael, this post should serve as a reply to some of the points you made in the post found above.

    I’ve got some questions…

    Q: Is „it“ a project?

    A: A project is a time-boxed endeavor to deliver a specific ‚product‘ with a limited resources. All these three conditions have to be fulfilled. Thus, if you don’t know what you want to deliver after the time box has ended, it’s not a project.

    Remarks from the PRINCE2 Agile perspective

    PRINCE2 is driven by themes, one of their themes is the business case. This business case will be initially developed in the ‚Starting up the project‘ process and will be finalized in the ‚Initiating the project‘.

    The business case contains three scenarios (best case, average case, worst case), which are based upon a combination of expected outcome (defined by high level requirements, AKA epics), risks, quality expectations and a defined timeline.

    PRINCE2 Agile thinks about what to flex and what to fix. Scope could be fix or flex. If we consider MoSCoW as a heuristic for evaluating importance/relevance of requirements, fix means „must have“ and sometimes „should have“, flex means „could have“.

    Q: What is your definition of the project’s „Definition of ‚done’“?

    A:  If you don’t have a ruler, you cannot measure distances. If you don’t have an idea of ‚done‘-ness of your project and its required product features, you can neither define the product your project shall deliver, nor can you judge if or when the product has been delivered successfully.

  • 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?!

  • There Ain’t no Such a Thing As a Free Lunch

    Das TANSTAFL-Prinzip…

    TANSTAFL bei der Verkehrswende bedeutet, dass wir uns fragen, welche Nachteile wir in Kauf nehmen, wenn wir einfach eine „böse“ Fortbewegungsart durch eine „gute“ ersetzen. Anders gefragt: Wieviele Tote gibt es, wenn ein nennenswerter Anteil aller PKW-Fahrten nun mit dem Fahrrad erledigt wird?

    Die Ausgangslage

    2019 wurden nach Statista in Deutschland ca. 650 Mrd. km mit dem PKW gefahren. In einer Verkehrswende, die den Namen verdient, sollen nun 50% durch die Schiene, 30% durch E-Autos und 20%. durch Fahrräder erledigt werden. Das macht 130 Mrd. km pro Jahr.

    Laut ilovecycling werden in Deutschland derzeit 25 Mrd. km mit dem Fahrrad zurückgelegt. Dabei wurden ca. 450 Personen getötet.

    Die bestimmt nicht paradiesische Zukunft

    Wenn nun knapp fünfmal soviel Strecke gemacht wird, werden auch fünfmal soviel Menschen im Straßenverkehr sterben: 2.250 Personen. 2020 starben aber im Straßenverkehr nur ca. 2.700 Personen insgesamt, d.h. schon jetzt sind 16% aller Verkehrstoten Fahrradfahrer.

    In der skizzierten Zukunft werden 70% der Autototen nicht mehr anfallen, das heißt aber, im E-Auto werden dann nur noch 810 Menschen sterben. Dafür werden allerdings 2.250 auf dem Fahrrad zu Tode kommen, so dass insgesamt 3.060 sterben werden, was heißt, dass ziemlich genau 73% aller Verkehrstoten dann auf dem Fahrrad sterben werden…

    Volvos Zero Death Policy wird damit unerreichbar.

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