Montag, 31. Dezember 2018

Kommentierte Links (XLIV)

Bild: Pixabay / Bru-nO - Lizenz
Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" Texte aus dem letzten Jahr.

  • Garry Ridge: The Four Pillars of the Fearless Tribe

    Wenn man diesem Text glauben darf ist WD-40 eine mehr als bemerkenswerte Firma. Alleine die in diesem Text zitierten Ergebnisse einer internen Mitarbeiterbefragung sind beeindruckend:
    • 97 % der Mitarbeiter kennen die Firmenziele
    • 93 % sehen der Zukunft der Firma mit Vorfreude entgegen
    • 92 % fühlen sich ermutigt an der eigenen Weiterentwicklung zu arbeiten
    • 97 % verstehen wie ihre Tätigkeit auf die Firmenziele einzahlt
    • 97 % wissen welche Ergebnisse die Firma von ihnen erwartet
    • 98 % glauben, dass ihre Überzeugungen und Werte zu Firmenkultur passen
    • 99% erzählen Freunden gerne von ihrer Arbeit
    Der CEO Garry Ridge gibt in diesem Text einen detaillierten Überblick über die Firmenkultur die diese Ergebnisse hervorgebracht hat und über die Grundlagen und Prinzipien auf denen sie beruht. Unbedingt lesens- und nachahmenswert.

  • Joost Minnaar: The Fundamental Things People Get Wrong About Self-Management

  • Eher ein Erklär-Artikel, allerdings ein wichtiger und nötiger. Denn während nahezu jeder der in einem agilen Kontext arbeitet von Selbstorganisation spricht, kann kaum jemand definieren was genau das ist und auch nicht was es nicht ist (Spoiler: es ist nicht "jeder macht was er will"). Infolgedessen ist der Begriff häufig mit unrealistischen Erwartungen und Befürchtungen verbunden, die schnell in Enttäuschung und Widerstand umschlagen. Die hier beschriebenen negativen Definitionen (dessen was Selbstorganisation nicht ist) können dabei helfen die Erwartungen auf ein realistisches Mass herunterzuschrauben - oder empozuheben

  • Willem-Jan Ageling: #NoEstimates – The 6 Alternatives for Estimating

    Noch ein Erklär-Artikel. Während Selbstorganisation für viele Menschen etwas ist was sie zwar nicht im Detail, aber zumindest auf einer sehr abstrakten Ebene beschreiben können, sind die meisten beim Thema "No Estimates" völlig verloren. Nach dem über-vereinfachenden Erklärungsversuch, dass Aufwände einfach nicht geschätzt werden, kommt nichts Brauchbares mehr. Dass es dann nicht nur einen sondern gleich mehrere No Estimates-Ansätze gibt hat für Viele einen fast schon esoterischen Touch. Und doch - es gibt sie, aufgelistet und erklärt in diesem Blog-Eintrag. [Nachklapp: das Ganze mag auch mit dem leicht missverständlichen Begriff zu tun haben, aber der hat sich nun mal so etabliert.]

  • Gary Hamel: Busting Bureaucracy

    Ein sehr guter und lesenswerter Text, aber auch einer den man sehr zwiespältig sehen kann. Dass Bürokratie Abläufe verlangsamt, die Beteiligten frustriert, Kreativität behindert, unnötige (und häufig versteckte) Kosten verursacht und wegen dieser und weiterer Gründe schnellstmöglich beseitigt werden sollte wird kaum auf Widerspruch stossen, damit hat Gary Hamel absolut recht. Auch dass es eine Gruppe von "Bürokraten" gibt, die von der Bürokratie profitiert (in Form von Macht, Anerkennung, Arbeitsverträgen, etc.) dürfte ein unstrittig anerkannter Teil des Problems sein. Schwierig wird es aber wenn "die da oben" dämonisiert werden. Das ermöglicht zwar eine mitreissende Revolutions-Rhetorik, baut aber auch Fronten auf und reisst Gräben auf. Veränderung wird dadurch schwerer.

  • Greg Satell: The Demise of Blockbuster, and Other Failure Fairy Tales

    Der Untertitel sagt eigentlich bereits alles aus: "When big companies collapse, the story is never simple". Tatsächlich ist in den letzten Jahren der Mythos entstanden, dass im Fall von Firmen wie Blockbuster, Kodak und Xerox der Niedergang, bzw. das Verpassen neuer Märkte vermeidbar gewesen wäre, wenn deren Management nur ein "agileres Mindset" gehabt hätte. In Wirklichkeit ist es natürlich komplexer. Die Herausforderungen wurden zwar erkannt und es wurden Pläne zu ihrer Bewältigung entwickelt, letztendlich wurde sich aber gegen große (und riskante) Inverstitionen entschieden, deren Erfolg damals nicht absehbar war. Was der Autor nicht sagt: mit agilem Vorgehen (MVPs, incrementelle Lieferung, etc.) hätte man die Investitionsrisiken stark reduzieren können.

  • Edward Niedermeyer: Elon Musk Is the Henry Ford of His Age. That's Bad.

    Ein gutes Beispiel für den Unterschied zwischen Agil und Lean und dafür wo welcher Ansatz Sinn macht. Das hier beschriebene Vorgehen von Tesla kommt klar aus dem Lean Startup (trotz seines Namens ein agiles Framework). Das Wichtigste ist es dort, schnell mit validierbaren Ergebnissen am Markt, bzw. beim Kunden zu sein und Geld zu verdienen. Das Ausliefern von leicht fehlerhaften Produkten wird bewusst in Kauf genommen und später durch Updates gefixt. Das Problem: Updates einer Automobil-Hardware müssen von Reparaturteams durchgeführt werden und erfordern unverhältnismässig viel Zeit und Aufwand. An der Stelle wäre vermutlich ein Lean-Ansatz besser gewesen, bei dem die Fertigungsstrasse so optimiert wird, dass es gar nicht zu fehlerhaften Auslieferungen kommt.

  • Bob Tarne: Agile Road Trip, Lessons From a Coach at Toyota

    Passend zum letzten Thema. Bei vielen Agile Coaches hat Toyota bis heute einen nahezu mythischen Ruf, da diese Firma federführend an der Entwicklung des Lean Management beteiligt war. Dass die Softwareentwicklung dort bis vor wenigen Jahren noch nach Wasserfall strukturiert war (siehe hier) wird dabei häufig ignoriert. Um so interessanter ist es zu erfahren, in wiefern der "Toyota Way" in die mittlerweile stattfindende agile Transition einfliesst. In der nordamerikanischen Tochtergesellschaft scheint das nur in geringem Ausmass so zu sein, zumindest legt dieser Artikel von Bob Tarne das nah. Bei der international tätigen Tochtergesellschaft Toyota Connected scheint das besser zu funktionieren (siehe hier). Wie das bei der Muttergesellschaft stattfindet ist zur Zeit aus den öffentlichen Dokumenten nicht zu erkennen. Man kann auf die ersten nicht-japanischenVeröffentlichungen gespannt sein.

  • Falk Kühnel: Agile scaling is plain wrong!

    Eine unterhaltsam geschriebene Abrechnung mit dem Buzzword "Scaled Agile" oder "agile Scaling". Tatsächlich ist es so, dass je nach Kontext völlig unterschiedliche Bedeutungen mit diesem Begriff verbunden werden. Eine extrem verbreitete fehlt aber bei Falk: Agile Scaling als Synonym für ein mit agilen Teams durchgeführtes Chinesenprinzip, also dafür, dass mehr Teams mit der selben Aufgabe beauftragt werden, in der Hoffnung schneller fertigzuwerden. Das wäre nochmal ein Thema für sich.

Donnerstag, 27. Dezember 2018

Was man alleine im Büro machen kann

Bild: Pixabay / tookapic - Lizenz
Immer wieder gibt es Phasen in denen der Grossteil der Kollegen im Urlaub ist und nur einige wenige zurückbleiben um bei Bedarf den Betrieb am Laufen zu halten. Die Zeit zwischen Weihnachten und Neujahr gehört dazu, aber auch andere Ferienzeiten. An den normalen Aufgaben des eigenen Teams weiterzuarbeiten ist in solchen Situationen oft nicht möglich (oder sinnvoll), so dass sich die Frage stellt: was soll man als (letzter) Teil eines agilen Teams in dieser Zeit tun? Hier einige Ideen.

Zunächst sollte klar sein, dass es auch in dieser Situation nicht zielführend wäre nicht gebrauchsfähige Teilergebnisse zu liefern. Ein Frontend ohne Backend wird z.B. dadurch nicht besser, dass es während der Winterpause erstellt wurde. Der nachgelagerte Erklär-, Integrations- und Anpassungsaufwand ist in der Regel so gross, dass man durch Implementierungs-Vorarbeiten nicht viel gewinnen kann.

Was hingegen häufig Sinn machen kann ist eine andere Art von Vorarbeit - ein Grooming, bzw. Refinement. Es kann zwar ohne den Input der anderen an der Umsetzung Beteiligten nicht final sein, trotzdem können bereits viele Frage- und Problemstellungen identifiziert werden die noch geklärt werden müssen bevor die Implementierung beginnen kann.

Auch bestimmte Spikes, bzw. Forschungsaufgaben können alleine durchgeführt werden. Wenn beispielsweise ein in nächster Zeit neu anzuschliessendes System in der Lage sein soll mit verschiedenen Datentypen umzugehen, kann bereits im Voraus jeder davon darin eingegeben und seine Verarbeitung überprüft werden, um herauszufinden wo Probleme auftreten und wo Anpassungsbedarf besteht.

Es können Minimum Viable Products, Riskiest Assumption Tests, Proofs of Concept oder Prototypen gebaut werden, durch die belegt (oder auch widerlegt) werden kann, dass bestimmte Vorhaben überhaupt möglich sind. Da die genannten Elemente nur der Beweisführung dienen und danach weggeworfen werden ist es hinnehmbar wenn an ihnen noch nicht alle mitarbeiten.

Nicht beliebt aber immer wieder notwendig sind Nacharbeiten an Testautomatisierung oder Dokumentation. Eine höhere Testabdeckung oder eine verständlichere Strukturierung von Anleitungen oder Handbüchern können dafür sorgen, dass die Arbeit in späteren Phasen leichter oder weniger wird.

Zuletzt kann die Zeit auch für die eigene Weiterentwicklung genutzt werden. Egal ob technisch, methodisch oder fachlich, wenn auf diese Weise mehr Wissen in ein Team kommt kann es als Ganzes nur davon profitieren. Dass es später auf mehrere Köpfe verteilt werden sollte dürfte klar sein, aber das kann auch im Rahmen von Pairing oder Reviews passieren wenn alle anderen wieder da sind.

Montag, 24. Dezember 2018

Geschenke

Bild: Pixabay / Bru-nO - Lizenz
Es ist ja gerade die Zeit der Geschenke. Passend dazu gibt es hier heute ein grosses Paket: Links zu den Seiten verschiedener Personen und Firmen, die die Erkenntnisse und Werkzeuge ihres agilen Alltags allen Interessierten kostenlos zur Verfügung stellen.


Henrik Kniberg: Lean from the Trenches (eBook)
Kein "Lehrbuch" sondern eher ein Erfahrungsbericht. Selbst wenn es mittlerweile ein Jahrzehnt alt ist, ist es in seinem Inhalt noch aktuell.

Henrik Kniberg: Scrum and XP from the trenches (eBook)
Ähnlich alt, gleicher Autor, ähnlich gut. Lobend hervorzuheben ist, dass hier auch auf XP-Elemente eingegangen wird und nicht nur auf Scrum.

Spotify Labs: Spotify Retro Kit
Falls der Scrum Master mal nicht da sein sollte und sonst keiner Facilitation-Erfahrung hat kommt man mit dieser Hilfe sicher durch die nächste Retrospektive durch.

Spotify Labs: Squad Health Check
Self Assessments für agile Teams gibt es viele, das hier ist eines der bekannteren, und das zu Recht. Es kann eine grosse Hilfe zur Selbsterkenntnis sein.

Agile for all: How to Split a User Story (Poster)
Bei zahllosen Product Ownern auf der ganzen Welt hängt dieses Poster an der Wand und hilft ihnen beim Kleinschneiden ihrer Anforderungen.

Dajo Breddels and Paul Kuijten: PO Value Game
Für das spielerische Erlernen der Product Owner-Rolle. Ist nicht nur für Anfänger sondern auch für fortgeschrittene POs zu empfehlen.

Management 3.0: Delegation Poker
Für alle Fälle in denen nicht ganz klar ist wie weit Selbstorganisation gehen soll und ab wo das Management das letzte Wort haben möchte. (ausdruckbar unten auf der Seite)

Donnerstag, 20. Dezember 2018

Schicht im Schacht

Bild: Wikimedia Commons / Ludwig Wegmann - CC BY-SA 3.0 DE
Einmal werden wir noch wach, dann ist es soweit. Nein, nicht Weihnachten, das dauert noch etwas. Morgen wird unbemerkt von vielen eine Ära zu Ende gehen ohne die vieles in Deutschland nicht denkbar gewesen wäre. Industrialisierung, Weltkriege und Wirtschaftswunder hätte es in dieser Form nicht gegeben ohne die deutsche Steinkohle-Förderung. Und ab morgen wird das Geschichte sein, denn morgen schliesst in meiner Geburtsstadt Bottrop das letzte deutsche Steinkohle-Bergwerk.

Für einige Zeit werden Bergleute und Journalisten noch in Nostalgie schwelgen, werden sich erinnern, melancholische Artikel schreiben und lesen und still die Feiertage begehen. Irgendwann danach werden sie sich aber eine deprimierende Frage stellen müssen: wie konnte es dazu kommen, dass ihre Heimat, früher eine der reichsten Regionen in Deutschland, heute eine der ärmsten ist? Wie konnte es passieren, dass das einstige wirtschaftliche Herz Deutschlands heute schlechter dasteht als die von der DDR heruntergewirtschafteten neuen Bundesländer?

Die Antwort darauf könnte man auch in Lehrbücher drucken, denn die Fehler die hier gemacht wurden stehen beispielhaft für die, die in vielen absteigenden Regionen, Wirtschaftszweigen und Firmen gemacht werden. Und sie alle begannen mit einem einzigen: dem Unwillen sich darauf einzustellen, dass die Welt sich verändert und man sich mit ihr verändern muss, ob es einem gefällt oder nicht.

Dass die Förderung der deutschen Steinkohle sich irgendwann nicht mehr lohnen würde ist bereits seit etwa 150 Jahren absehbar gewesen. So lange weiss man schon, dass nur bei einem Teil der Vorkommen der Abbau wirtschaftlich ist. Der Rest ist zu tief im Boden und zu aufwändig zu gewinnen, so dass es nicht mehr möglich sein kann mit den Tagebauten in den USA, Australien, China und Kolumbien zu konkurrieren. Und doch wurde noch bis nach dem Jahr 2000 so getan, als ob das möglich wäre.

Aufbauend darauf folgte ein zweiter, genauso verhängnisvoller Fehler. Obwohl über lange Zeit genug Geld da gewesen wäre wurde nicht ausreichend in die Förderung anderer Wirtschaftszweige investiert. Die Folge: die im Bergbau wegfallenden Arbeitsplätze werden nicht durch andere ersetzt, die Menschen flohen vor der Perspektivlosigkeit in andere Gegenden. Städte wie Duisburg oder Gelsenkirchen haben dadurch jeweils mehr als 100.000 Einwohner verloren, Spitzenplätze erreichen sie nur noch bei Arbeitslosen- und Hartz IV-Quoten.

Der entscheidende Stoss erfolgte dann durch fahrlässig hohe Abgaben. Aus dem Gefühl heraus, dass man den prosperierenden Energie- und Industrieunternehmen problemlos etwas mehr Geld abnehmen könnte (angeblich war deren Zukunft ja sicher), wurden die Gewerbesteuern höher und höher geschraubt. Städte wie Duisburg, Bochum, Essen, Mühlheim und Oberhausen haben heute die höchsten Hebesätze Deutschlands und würgen damit den eigenen Firmen die Lebenskraft ab. Wie unter diesen Umständen die Wirtschaft wieder in Gang kommen soll bleibt schleierhaft.

Wie gesagt, die Fehler die hier gemacht wurden stehen beispielhaft für viele absteigende Regionen, Wirtschaftszweige und Firmen. Den Kopf in den Sand stecken, den Strukturwandel verschlafen und das was (noch) da ist als Cash Cow missbrauchen, das sind Verhaltensweisen die man durch alle Branchen immer wieder antrifft. Für alle die in einem solchen Umfeld Verantwortung tragen sollte der deutsche Steinkohlebergbau eine Warnung sein: wer glaubt sich der Veränderung verweigern zu können dem bleiben irgendwann nur noch Erinnerungen an die große Vergangenheit.

Montag, 17. Dezember 2018

Do they know this agile thing?

Ein etwas schiefer Gesang, aber dafür eine um so stärkere Botschaft. Das agile Weihnachtslied, mit parodistischer aber klarer Kritik an der kommerziellen Vermaktung von Agilität durch SAFe & Co.



Dass dieses Video zur Zeit in vielen Teams in gefühlter Dauerschleife läuft ist auch ein guter Indikator für den aktuellen "State of agile". Das wäre nochmal ein grosses Thema für sich.

Donnerstag, 13. Dezember 2018

Kamishibai

Bild: Wikimedia Commons / Adrian Grycuk - CC BY-SA 3.0 PL
Zu den Spielarten von Kanban die in der Hardware-Produktion häufiger vorkommen als in der IT gehört Kamishibai (紙芝居). Der Name ist abgeleitet von mobilen japanischen Papiertheatern gleichen Namens, bei denen eine Geschichte anhand von mit Bildern bemalten Karten erzählt wird, die nacheinander von links nach rechts durch einen Rahmen geschoben werden. Um das zu transportierende Gewicht zu verringern wurden diese Karten beidseitig bemalt, was mit der Zeit dazu führte, dass beidseitig bemalte oder bedruckte Karten jeglicher Art als Kamishibai bezeichnet werden.

In Kanban-Systemen werden Kamishibai-Karten dort verwendet wo dauerhaft gleichartige Vorgänge in gleichartigen Zeitabständen durchgeführt werden, etwa im Fall von Auditierungen, dem Reinigen von Maschinen (Hardware) oder dem Einspielen neuer Testdaten (Software). Üblicherweise werden dabei die zur jeweiligen Arbeit gehörenden Karten am Anfang eines Zeit-Zyklus mit einer (meistens roten) Seite nach oben gedreht, aus der hervorgeht, dass die Arbeit noch nicht durchgeführt wurde. Nach der Durchführung wird die andere (meistens grüne) Seite nach oben gedreht, die anzeigt, dass hier in diesem Zyklus nichts mehr zu tun ist. Ein Beispiel dafür ist dieses hier:



Während dieser Anwendungsfall relativ schlicht ist können auch erweiterte Funktionen Teil eines solchen Systems sein. Eine naheliegende Erweiterung besteht darin, während der Durchführung eine Karte mit dem Namen des Bearbeiters neben oder über die Kamishibai-Karte zu hängen. Eine ähnliche Nutzung findet statt wenn die Karte auf einem Kalender oder Zeitstrahl hängt, während der Bearbeitung auf das Kanban-Board oder Sprint Backlog eines Teams übernommen und nach Erledigung zurückgebracht wird. Gegebenenfalls können auf der Karte auch Notizen über das Arbeitsergebnis festgehalten werden.

In Scrum oder (IT-)Kanban-Teams können Kamishibai-Boards z.B. Sinn machen wenn zu den täglich zu erledigenden Tätigkeiten Kundenservice oder Betriebsaufgaben gehören. Ein anderer naheliegender Fall wären Instant Implementation Hours. Letztendlich eignet sich alles was sich regelmässig wiederholt und nicht automatisierbar ist.

Montag, 10. Dezember 2018

Schläferzellen

Bild: Pexels / Burst - Lizenz
Es ist nur ein einziger Satz aus einem Bericht vom Peter Drucker Forum 2018, aber es lohnt sich länger über ihn nachzudenken. Er steht in einem Absatz in dem die immer stärker werdende Verbreitung von "Human-Centered Management" beschrieben wird und lautet "'Sleeper cells' of the new way of managing have sprung up in many more organizations." Aber was soll uns das sagen?

Zunächst zur Begrifflichkeit. Sleeper Cell (Schläferzelle) bezieht sich in diesem Zusammenhang auf eine Frühphase revolutionärer Bewegungen. Gruppen von Menschen kommen mit neuen, radikalen oder ungewöhnlichen Ideen in Berührung, die zu diesem Zeitpunkt noch nicht anerkannt, nicht zulässig oder stigmatisiert sind. Bedingt dadurch erfolgt die Beschäftigung damit zunächst zurückgezogen im privaten oder informellen Raum.

Wenn die neuen Ideen schliesslich in der öffentlichen Diskussion oder sogar der Umsetzung ankommen werden die bis dahin ruhigen (schlafenden) Gruppen aktiv und sorgen dafür, dass (von aussen betrachtet) aus dem Nichts eine Unterstützerbasis entsteht auf die sich der entstandene Veränderungsprozess stützen kann. Beispiele dafür sind der Prager Frühling oder der Arabische Frühling1.

Auch im Rahmen von Management und Menschenführung kommen Schläferzellen vor, wenn auch mit einer sehr unterschiedlichen Dichte und Beteiligung, je nachdem um welche Denkrichtung es geht. Während prozess- und hierarchiezentrierte Ansätze von den potentiell Betroffenen eher skeptisch gesehen werden haben team- und menschenzentrierte Frameworks wie XP und Scrum aufgrund ihrer Soft Power-Faktoren eine sehr hohe Anziehungskraft.

Wenn eine Organisation sich dazu entschliesst es mit Agilität zu versuchen gibt es daher in der Regel den oben beschriebenen Effekt: scheinbar aus dem Nichts entstehen (vor allem in der IT) Gruppen die bereits Vorwissen mitbringen, sich an der Umsetzung und Gestaltung des Veränderungsprozesses beteiligen wollen und den Finger in die Wunde legen wenn er sich in die falsche Richtung entwickelt.

Für die Veränderung ist das ein doppelter Glücksfall. Zum einen ist sie von Beginn an in Teilen der Organisation verankert, wodurch sie eine ganz andere Wirkungskraft entfalten kann als ein rein von oben getriebenes Vorgehen. Zum anderen wird frei Haus eine Validierungsmöglichkeit geliefert. Ob es mit dem Veränderungswillen ernst gemeint ist kann man jetzt u.A. daran erkennen ob sich die "erwachten Schläfer" beteiligen dürfen oder nicht.

Und selbst wenn die Veränderungsbemühungen fehlschlagen oder sich festfahren sollten bleibt Positives zurück: die Zahl der Zellen die wieder zurück in den Schlafmodus gehen hatte die Chance deutlich zuzunehmen. Bei der nächsten Aktivierung ist der initiale Schwung dadurch nochmal grösser.


1Es gibt auch den Fall von destruktiven Schläferzellen, aber das wäre ein anderes Thema.

Donnerstag, 6. Dezember 2018

Delivering twice the value in half the time

Bild: Pixabay / Annca - Lizenz
Weitgehend unbemerkt von der Öffentlichkeit hat sich irgendwann in den letzten Wochen eine unscheinbare aber bedeutsame Änderung ergeben: eines der bekanntesten Versprechen von Scrum wird anscheinend nicht mehr in seiner ursprünglichen Form weiterverwendet. Die Rede ist von doing twice the work in half the time, bekannt geworden als Titel eines Buches von Scrum-Mitbegründer Jeff Sutherland. Stattdessen spricht er seit kurzem von delivering twice the value in half the time. Ein kleiner aber feiner Unterschied.

Die Aussage "Doing twice the work", die seit je her von Scrum Practitionern kritisch gesehen wird, impliziert, dass die Einführung von Scrum zu einem höheren Durchsatz führt. Egal welche Tätigkeiten ein Team durchführt, es wird in die Lage versetzt noch mehr davon zu leisten. Man spricht im Englischen in diesem Zusammenhang von der Erhöhung des Output. Was nicht klar ist (und hier setzt die Kritik an der Formulierung an) ist, ob der durch diese Tätigkeiten erzeugte Output überhaupt einen Sinn ergibt.

Wer in grossen Organisationen arbeitet kennt das Risiko - viele Teams erzeugen Arbeitsergebnisse von fragwürdigem Wert: Konzepte die an der Realität vorbeigehen, Statistiken die Offensichtliches oder Irrelevantes messen, Funktionalitäten die die Kunden nicht brauchen, etc. Davon mehr zu bekommen hilft niemandem weiter. Und selbst wenn Sutherlands Buch inhaltlich nichts derartiges fordert, der Titel verführt zu diesem Fehlschluss.

Besser ist es, bei jeder bisher durchgeführten Tätigkeit die Sinnfrage zu stellen. Je mehr an Elfenbeintürmen, Junk Charts, Bloatware, etc. weggelassen werden kann, desto mehr Zeit bleibt für die Arbeit an wirklich wichtigen Themen. Um es mit den Worten des Manifests für agile Softwareentwicklung zu sagen: Simplicity - the art of maximizing the amount of work not done - is essential. Viele der Bestandteile von Scrum (Definition of Done, Sprintziel, User Stories, etc.) zielen genau darauf ab.

Diese Art von werthaltigen und sinnstiftenden Ergebnissen nennt man im Englischen Outcome. Da für ihre Fertigstellung im Idealfall nur die nötigste Arbeit verrichtet und alles Unnötige unterlassen wurde, sind der Aufwand und die Zeit die investiert werden müssen deutlich niedriger als im Fall einer Output-orientierten Arbeitsweise. Daher macht die Aussage delivering twice the value in half the time absolut Sinn. Richtig angewandt kann Scrum dafür sorgen, dass in weniger Zeit mehr Mehrwert entsteht.

Ganz aus der Welt bekommen wird man das "Doing twice the work" zwar wohl nicht mehr, zukünftig kann man aber jedem der es falsch versteht zeigen, dass die Formulierung weiterentwickelt wurde. Ganz im Sinn von Inspect & Adapt.

Montag, 3. Dezember 2018

Just in Time vs. Just in Case

Irgendwo ist dieses Video durch meinen Twitterfeed gerauscht. Eine kurze Erklärung des Just in Time-Prinzips (Produktion nur nach Bedarf, ohne Lagerhaltung), mit netten, z.T. amüsanten, Visualisierungen. Man kann es sich gut als Einführung in das Thema anschauen.



Ein interessanter Ansatz für die Vermittlung dieser Idee ist dabei die Gegenüberstellung eines zweiten Prinzips: Just in Case. Die deutsche Übersetzung Für alle Fälle zeigt worum es geht - etwas mehr Zeit, Material und Personal als nötig hilft im Zweifel dabei, ungeplante und unvorhersehbare Aufwände zu bewältigen. Da beide Ansätze ihre Vorteile haben wird es in den meisten Fällen auf eine Abwägung herauslaufen. Und um die griffig beschreiben zu können ist das Gegensatzpaar Just in Time und Just in Case gut geeignet.