Think, Make

Kategorie: Projektmanagement

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

  • Remarks on PRINCE2’s „Product-Based Planning“

    What is Product-Based Planning?

    Product-Based Planning is a longtime hallmark of PRINCE2. It consists of four steps:

    1. Write a Project Product Description, which is a high-level description of customer expectations.
    2. Write a Product Breakdown Structure (PBS), which is a logical hierarchy of the project’s deliverables.
    3. Write a Product Description (PD), which is a concise but complete verbal definition of what has to be delivered by the project.
    4. Create a Product Flow Diagram (PFD), which identifies the order of precedence of products and their components or constituents.

    BTW, the PMI PMBoK knows something called a “Work Breakdown Structure” which comes quite close to the PBS idea, in fact, there should be a 1:1 relation between the details, i.e., for every item in the PBS there should be (at least) one task to deliver it.

    How do I implement Product-Based Planning?

    I implement PBP by implementing the four steps from above, where step 1 and step 3 effectively are boiling down to writing a word document. I know you can do it!

    How to write a Project Product Description?

    Well, write a word document. Some templates can be found on the web.

    How do I do a Product Breakdown Structure?

    By learning from examples. Well, here comes the example:  We want to move a shed from place A to place B. What would be a good PBS?

    Before we start we should define different node shapes for different classes of products (or deliverables):

    • Logical groups are shown as parallelograms.
    • External products (delivered not by the project but consumed by it) are shown as ellipsoids.
    • Management products are not filled, all other products are filled (with non-white).

    We see that our total outcome consists of three logical products groups (the parallelograms). For the sake of simplicity, we divide the complete hut into just two entities: the shed shell and its content. And we omit the management products (plans, reports, documentation, etc.)

    Moving the shed is a bit more complex, since we foresee the need of a permission to build the hut at the new location, and we do not have a truck, thus an external mover will be involved. These are thus marked with an ellipse.

    How on earth how did I create it? Well, I started my favorite text editor (sublime) and entered this:

    digraph pbs { 
    splines=ortho
    rankdir="LR"
    node [margin=0.1 fontcolor=black fontsize=12 
      shape=rect style=filled           
      arrowhead="vee" fontname="Arial" fixedsize=true 
      width=2.5 shape="rect" 
      fillcolor=deepskyblue1  ]
    edge[arrowhead="vee"]  
      
    p [label="move shed"]
    o [label="old shed removal" shape="parallelogram"]
      o1 [label="disassembled shed"]
      o2 [label="packed content"]
    m [label="move" shape="parallelogram"]
      m1 [label="loaded shed"]
      m2 [label="building permission" shape="ellipse"]
      m3 [label="moved shed" shape="ellipse"]
      m4 [label="unloaded shed"]
    n [label="new shed build" shape="parallelogram"]
      n1 [label="new home, assembled shed"]
      n2 [label="new home, goods in place"]
    p -> {o m n} 
    o -> {o1 o2}
    n -> {n1 n2}
    m -> {m1 m2 m3 m4}
}

    …and pasted this into this: https://dreampuf.github.io/GraphvizOnline/ (or http://magjac.com/graphviz-visual-editor/)

    In fact, the data seen above is written in a graph language called DOT (https://graphviz.org) and with this or a command line tool you can generate wonderful scalable vector graphics (SVGs), which can be viewed in any modern browser or may be imported into word.

    How to write a Product Description?

    Well, write a word document with a table with two columns: “product name” and “product description”, and you should be fine.

    How could I write a Product Flow Diagram?

    Easy:

    digraph pfd { 
    splines=ortho
    rankdir="TD"
    node [margin=0.1 fontcolor=black fontsize=12 
      shape=rect style=filled           
      arrowhead="vee" fontname="Arial" fixedsize=true 
      width=2.5 shape="rect" 
      fillcolor=deepskyblue1] 
    edge[arrowhead="vee"]  
     
    p [label="move shed"] 
    o [label="old shed removal" shape="parallelogram"]
    o1 [label="disassembled shed"]
    o2 [label="packed content"]
    m [label="move" shape="parallelogram"]
    m1 [label="loaded shed"]
    m2 [label="building permission" shape="ellipse"]
    m3 [label="moved shed" shape="ellipse"]
    m4 [label="unloaded shed"]
    n [label="new shed build" shape="parallelogram"]
    n1 [label="new home, assembled shed"]
    n2 [label="new home, goods in place"]

    o -> m -> n -> p
    o1 -> m3 -> m4
    o2 -> m3
    o1 -> o2 -> o 
    m1 -> m3 -> m4 -> m
    m2 -> m
    m2 -> n1 -> n2 -> n -> p
}

    What should you learn to understand the DOT language? Here is my concise list:

    1. Start with PBS digraph <NAME> {}. This will generate an empty directed graph.
    2. Insert your products into the braces, one per line. The format is 
        <PRODUCT NAME> [label = “<TEXT”]. In graph theory these products are called nodes.
    3. Insert tree relationships, e. g., product-> component 1, one per line. In graph theory these relationships are called edges. Since we have a directed graph, these edges have start and an end, marked by an arrow or the like.
    4. If you like to manipulate certain attributes, you either change them in the nodes, or you insert a node item to change the default behavior of all nodes. The same holds true for edges.
    5. RTFM.

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

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