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.

Freitag, 30. November 2018

Kommentierte Links (XLIII)

Bild: Pixabay / Bru-nO - Lizenz

  • Mark Schwartz: Your First Four Steps in Transforming Enterprise IT Governance

  • Ein Blick aus der Adlerperspektive. Was Mark Schwartz beschreibt ist letzten Endes nichts anderes als Kanban. Reduziere die Anzahl der Initiativen (bzw. des Work in Progress), verkürze die Durchlaufzeiten, schliesse Vorhaben so schnell wie möglich ab, fokussiere Dich bei den Ergebnissen auf die Erzeugung von Geschäftswert und die Validierung von Annahmen. Dass das auch der Ebene ganzer Konzerne möglich ist zeigt eine der Stärken von Kanban auf - es lässt sich auf jede Ebene skalieren.

  • Tobbe Gyllebring: What if demonizing “waterfall” pulled the rug out from under our Agile?

    Ein interessanter Denkansatz. Tobbe Gyllebring geht davon aus, dass agile Vorgehensweisen vor allem dann wirksam und verständlich sind wenn man das klassische Wasserfallmodell als Kontrast parat hat, weil man dieses noch erleben musste, bzw. durfte. Das ist zwar nicht völlig falsch, die Frage ist aber was die Konsequenz wäre. Dysfunktionale Strukturen (wieder)einzuführen nur um Kontextwissen zu erzeugen wäre sicher über das Ziel hinausgeschossen. Vielleicht sollte man bewusst eine Karrierestation dort einlegen wo man noch nicht so weit ist und man deshalb lernen kann wie es nicht geht? Eine gewagte Idee.

  • Heidi Araya: Why Agile Works

    Einmal mehr ein klassischer Erklär-Artikel. Angereichert um einige gute weiterführende Links fasst Heidi Araya ein "Best of" aus Agile, Kanban, Lean Startup, technischer Exzellenz und Kundenorientierung zu einer verständlichen Storyline zusammen. Falls wieder jemand nach einer schriftlichen Zusammenfassung fragt ist das hier ein guter Kandidat. Jetzt müsste ich nur noch die Motivation und die Zeit finden das ins Deutsche zu übersetzen ....

Dienstag, 27. November 2018

Gesetz der Penetranz der negativen Reste

Bild: Public Domain Pictures / Ian Bunyan - CC0 1.0
Alleine der Name ist so schräg, dass man versucht ist herauszufinden was sich dahinter verbirgt. Das "Gesetz der Penetranz der negativen Reste" setzt sich mit dem Phänomen auseinander, dass die Lösung von Problemen bei vielen Menschen nicht dazu führt, dass sie mit ihrer Gesamtsituation zufriedener sind. Im Gegenteil bleibt der Grad der Unzufriedenheit durchgehend gleich, er konzentriert sich lediglich auf einen immer kleineren Problem-Restbestand.

Der Philosoph Odo Marquard, Schöpfer des Begriffs, definiert ihn so: Wo Fortschritte … wirklich erfolgreich sind und Übel wirklich abschaffen, da wecken sie selten Begeisterung. Sie werden vielmehr selbstverständlich, und die Aufmerksamkeit konzentriert sich dann ganz und gar auf jene Übel, die übrigbleiben. Da wirkt das Gesetz der zunehmenden Penetranz der Reste: ... Wer – fortschrittsbedingt – unter immer weniger zu leiden hat, leidet unter diesem Wenigen immer mehr.

Ursprünglich stammt dieses "Gesetz" aus Beobachtungen im Bereich der Medizin, wo sich trotz immer besserer Gesundheit der Gesamtbevölkerung die Sorgen um die eigene Gesundheit halten und auf immer nachrangigere Aspekte konzentrieren. Zum Teil kann es dort sogar in Extreme wie Medikalisierung und Pathologisierung umschlagen. Übertragen lässt es sich aber auch auf die Organisationsentwicklung, bzw. die zu dieser gehörenden Optimierungsprozesse.

Geht man davon aus, dass auch hier Fortschritte dazu führen, dass die verbleibenden Probleme pathologisiert und mit dauerhaft gleichbleibender Energie bekämpft werden, hat man eine Erklärung für den in vielen Organisationen anzutreffenden Drang zur "Über-Optimierung". Die scheinbare Irrationalität, mit der selbst kleinste Einspar- und Effizienzpotentiale hartnäckig verfolgt werden, wird plötzlich erklärbar.

Das Problem ist, dass es hier anders als beim Gesundheitsempfinden nicht bei Übersensibilität und Hypochondrie bleibt. Das Gesetz der Penetranz der negativen Reste kann schwerwiegende wirtschaftliche Folgen haben: nicht nur wegen des immer unverhältnismässiger werdenden Verhältnisses zwischen Optimierungs-Aufwand und Ertrag, sondern auch wegen der früher oder später fast zwangsläufig auftretenden Beeinträchigung elementarer Funktionen.

Getrieben von dem Drang auch kleinste Dysfunktionen aufzuspüren ist in vielen Organisationen ein derart engmaschiges und aufwändiges Reporting und Controlling entstanden, dass die Erfüllung der damit verbundenen Vorgaben einen Grossteil der Arbeitsleistung bindet. Die wertschöpfenden Tätigkeiten gehen dagegen immer weiter zurück, mitunter soweit, dass die erwirtschafteten Gewinne die entstandene Bürokratie nicht mehr finanzieren können.

Um die damit verbundenen Folgen (die im schlimmsten Fall bis zur Insolvenz reichen können) abzufedern empfiehlt sich eine regelmässige Überprüfung aller zur Zeit laufenden Optimierungsmassnahmen. Welches Ziel sollen sie erfüllen, welcher wirtschaftliche Effekt soll damit erreicht werden und wie hoch sind die dem gegenüberstehenden Verwaltungs- und Bürokratiekosten? Und bei lokalen Optimierungen: was sind deren Auswirkungen auf das Gesamtsystem?

Wenn es gelingt durch solche Evaluierungen die Stellen zu identifizieren, an denen das Gesetz der Penetranz der negativen Reste zu Überoptimierungen geführt hat, kann deren Abschaffung befreiend wirken. Je nach Kontext kann die dadurch mögliche (Wieder)Zunahme an Effektivität und Flexibilität sogar so gross sein, dass ihre Rücknahme bereits die Effekte einer agilen Transition hat, ganz ohne Scrum Master, Standup Meetings & Co.

Donnerstag, 22. November 2018

DoD Memory

Bild: Pxhere / Rawpixel - CC0 1.0
When life gives you lemons - make lemonade. Gemäss diesem englischen Sprichwort haben wir (ich und ein von mir gecoachter Scrum Master) diese Woche eine neue Übung für die nächste Retrospektive entwickelt. Angelehnt an das Memory-Spiel ist der vorläufige Name DoD Memory, denn auch hier geht es um einen Test des Erinnerungsvermögens.

Zu den Hintergründen: das Team um das es geht leidet unter einer Sonderform der agilen Demenz - die eigene Definition of Done (DOD) gerät regelmässig in Vergessenheit. Selbst wenn sie in Retrospektiven oder gesonderten Workshops neu erstellt oder überarbeitet wird ist es nur eine Frage der Zeit bis sich niemand mehr an sie erinnern kann und demzufolge auch niemand mehr an sie hält. Aus den Augen, aus dem Sinn, wie man in einem anderen Sprichwort so schön sagt.

DoD Memory funktioniert jetzt so: der Scrum Master (oder jeder andere der sich berufen fühlt) kann in einer Retrospektive darum bitten, dass jedes Teammitglied alle Teile der DoD an die es sich erinnern kann aufschreibt - am besten in Stillarbeit. Die Ergebnisse werden gesammelt und dann mit der tatsächlichen DoD verglichen (die zu diesem Zweck verfügbar sein sollte).

Sollte es jetzt der Fall sein, dass Teile der Definition of Done keinem einzigen Teammitglied eingefallen sind stellt sich die Frage was das für das Team bedeutet. Da davon ausgegangen werden kann, dass nicht präsente Teile der DoD nicht angewendet werden, kann zur Debatte gestellt werden ob sie nicht gestrichen werden sollten. Gewissermassen wäre das die Anpassung der Regeln an die Realität. Alternativ kann überlegt werden wie die DoD präsenter gemacht werden kann.

Geschieht das gibt es zwei mögliche Endszenarien. Entweder gelingt es durch die Thematisierung in Retrospektiven und durch abgeleitete Massnahmen die DoD zu verinnerlichen oder sie schrumpft nach und nach zusammen bis nur noch der Rest übrig ist an den sich jeder erinnern kann. Beides hat Vorteile. Bei Bedarf kann natürlich auch wieder eine Erweiterung stattfinden, die dann aber irgendwann auf die selbe Art validiert werden sollte.

Letztendlich können vergleichbare Übungen auch mit anderen Vereinbarungen durchgeführt werden, etwa der Definition of Ready oder der Teamcharta. Auch in diesen Fällen ist es ein guter Weg um der agilen Demenz entgegenzuteten, die auch in den besten Teams um sich greifen kann.

Montag, 19. November 2018

Ein Bild sagt mehr als 1000 Worte (XXIII)

Bild: Geek & Poke - CC BY 3.0
Und falls das eine Bild doch nicht reichen sollte um zu erkennen worum es hier geht - hier gibt es Kontext.

Donnerstag, 15. November 2018

Wie Angst lähmen kann

Bild: Wikimedia Commons / J. M. Garg - CC BY-SA 4.0
Zu den deprimierendsten Erfahrungen als Agile Coach gehört es, mit dem Auftrag zur Veränderungsbegleitung bei einem Team zu erscheinen, ihm das theoretische und methodische Rüstzeug mitzugeben, erste Verbesserungspotentiale aufzuzeigen und dann zu hören "Nein, das machen wir nicht, das werden die uns nie erlauben." Gegen diese Stimmung anzukämpfen ist schwierig aber notwendig, denn wenn sie nicht verschwindet sind echte Veränderungen unwahrscheinlich.

Das Problem ist, dass es sich bei einem Grossteil dieser scheinbaren Verbote um keine offiziellen Regeln handelt sondern um inoffizielle. Es ist also nirgendwo festgehalten, dass man eine bestimmte Handlung (Überstunden ablehnen, selbst Entscheidungen treffen, Anforderung hinterfragen, etc.) nicht durchführen darf. Trotzdem wird oft angenommen, dass ein Verbot besteht und allein das in Erwägung ziehen eines nicht konformen Verhaltens wird vehement negiert.

Dort wo derartige Verhaltensweisen an den Tag gelegt werden kann mit hoher Wahrscheinlichkeit davon ausgegangen werden, dass das als verboten angenommene Verhalten irgendwann in der Vergangenheit bestraft worden ist. Alleine die Erinnerung daran (und die Angst vor einer neuen Bestrafung) kann dann dafür sorgen, dass mit allen Kräften versucht wird eine Wiederholung dieser Ereignisse zu verhindern. Für den psychologisch Interessierten: es ist die Übertragung des berühmten Rhesusaffen-Experiments von Gordon R. Stephenson auf den Menschen.

In einer solchen Situation ist es mit einem gut gemeinten Versuch es doch einfach nicht mehr getan. Was nötig ist, ist die Schaffung eines Safe Space, also einer Umgebung in der es sichergestellt ist, dass es nicht zu einer Bestrafung kommen wird - und zwar auch dann nicht (genauer gesagt gerade dann nicht!) wenn das Ergebnis nicht den Erwartungen entspricht oder ungeplante Seitenauswirkungen auf andere Bereiche hat. Nur wenn das gelingt kann es zu Verhaltensänderungen kommen.

Was ist für die Schaffung eines solchen Safe Space nötig? Zuerst das Ansprechen des Root Cause, also der in der Vergangenheit stattgefundenen Bestrafung1.Wenn sie aufgrund einer damals noch gültigen Regel stattgefunden hat muss klar gemacht werden, dass diese Regel nicht mehr in Kraft ist, wenn sie ohne derartige Grundlage stattgefunden hat muss das als Fehler eingestanden werden. Und diese Aussage muss von der Hierarchiebene kommen von der aus die Bestrafung stattgefunden hat oder von einer höheren.

Als nächstes macht es Sinn festzuhalten, dass die aktuellen Regeln ein bestimmtes Verhalten nicht nur zulassen sondern sogar ermutigen. Idealerweise findet das nicht nur durch eine Anpassung des dritten Absatzes der vierten Seite des achten Kapitels des Prozesshandbuches statt sondern durch plakatives Aufhängen an einer zentralen Stelle, etwa als Banner mit der Aufschrift "Wir dürfen und sollen Nein sagen."

Falls nötig kann auch vereinbart werden was der Rahmen ist innerhalb dessen ohne Sorgen gehandelt werden kann. Dass Selbstorganisation nicht grenzenlos sein kann sollte eigentlich offensichtlich sein, und dass diese Grenzen nicht festgelegt wurden ist oft ein Grund für unbewusste Überschreitungen und ein als Strafe empfundenes nachträgliches Festsetzen. Was an dieser Stelle wichtig ist: ist der Rahmen zu eng gesetzt wird er im Zweifel als einengend und einschüchternd empfunden werden.

Zuletzt kann es helfen wenn die Respektierung der gewährten Freiheiten (und das Nicht-Stattfinden von Bestrafungen) regelmässig validiert wird. Wie das vor sich gehen kann wird von Fall zu Fall unterschiedlich sein müssen, möglich ist z.B. das Durchführen von Experimenten in einem iterativ immer grösser werdenden Rahmen oder ein anlassgetriebener Lessons Learned-Prozess. In jedem Fall sollten aber positive Beispiele hervorgehoben und erörtert werden.

Klar sollte sein, dass all diese Massnahmen in den meisten Fällen nicht nötig sein sollten. Sie machen vor allem dort Sinn wo in einem Unternehmen eine Angstkultur herrscht, die es abzuschaffen gilt, und die man erkennt an Sätzen wie "Nein, das machen wir nicht, das werden die uns nie erlauben."


1Es gibt auch Fälle in denen das Management bestreitet, dass es eine Bestrafung gab, bzw. eine stattgefundene Handlung nicht als Bestrafung sehen will. Das sind dann nochmal ganz eigene Probleme.

Montag, 12. November 2018

Management 3.0

Bild: Pixabay / Monfocus - Lizenz
Einer der kleineren, trotzdem aber immer erfolgreicher werdenden agilen Ansätze ist das so genannte Management 3.0. Was das ist und wo es herkommt wäre eine Geschichte für sich, an dieser Stelle soll es aber zuerst nur um den Namen gehen. Schon hinter ihm versteckt sich nämlich ein für das Verständnis des Frameworks zentraler Punkt. Er definiert nicht nur was Management 3.0 ist, sondern auch was es nicht ist.

Wie man sich denken kann ist es eine Differenzierung von anderen Management-Praktiken. Dabei setzt es sich zuerst ab von der "herkömmlichen" Art Menschen und Unternehmen zu führen. In diesem Kontext wird diese Management 1.0 genannt und ist geprägt durch Hierarchiedenken, Herrschaftswissen, Command & Control und ähnlichen problematischen Vorgehensweisen.

Warum diese Vorgehensweisen problematisch sind ist aus einer agilen Perspektive klar: Hierarchien verhindern, dass sich die ausführende Ebene verantwortlich fühlt (und benimmt), Herrschaftswissen hält die Mitarbeiter dumm und führt so zu unklugen Entscheidungen, Command und Control verlagert den Ziel des Arbeitens weg von der Sinnerfüllung und hin zur Vorgabenerfüllung. So weit, so bekannt.

Darüber hinaus wird davon ausgegangen, dass es noch eine zweite Art von Management Praktiken gibt, die zwar in ihren Zielen etwas weiter ist, diese aber mit den bisher üblichen Methoden umsetzen will und aus diesen Gründen zwangsläufig daran scheitert. Letztendlich ist er damit nur der bessere unter den schlechten Ansätzen. Für ihn gibt es den Namen Management 2.0.

In der Realität sieht er so aus, dass z.B. Selbstorganisation angestebt wird, die aber dadurch umgesetzt werden soll, dass die dazu (angeblich) nötigen Strukturen den Mitarbeitern ungefragt übergestülpt werden. Klassiker in diesem Bereich sind die von oben angeordneten Einführungen von SAFe oder (Pseudo-)Spotify, was meistens nichts anderes ist als die Ersetzung alter Hierarchien und Kommandostrukturen durch neue.

Auch der Versuch eine neue Unternehmenskultur von oben vorgegeben und zentral gesteuert einzuführen ist eine Ausprägung von Management 2.0. Alleine die Idee, dass man Kultur durch Anordnung verändern könnte ist ein Missverständnis. Wenn dann noch paternalistische Aspekte dazukommen ("die müssen zu ihrem Glück gezwungen werden", "die werden noch verstehen warum das gut ist", etc.) ist kaum noch ein Unterschied zu Management 1.0 erkennbar. (siehe auch: agiler Marxismus und Leninismus)

Management 3.0 ist dagegen der Versuch alle Ebenen in Veränderungen und Entscheidungen einzubeziehen, und zwar nicht nur als Betroffene sondern als Beteiligte. Um das zu erreichen gibt es eine Vielzahl von Praktiken und Techniken die in ihrer Gesamtheit das Management 3.0-Framework ausmachen (z.B. Merit Money und Delegation Poker). Ihnen allen ist gemeinsam, dass sie nicht angeordnet sondern gemeinsam durchgeführt werden sollen.

Mit der Benennung 3.0 erfolgt damit nicht nur eine Differenzierung zum "traditionellen" Management sondern ganz wesentlich auch zu denen, die zwar eigentlich das Richtige wollen, die Transition aber durch Bevormundung der Mitarbeiter und undifferenziertes Copy & Paste anderswo erfolgreicher Methoden umsetzen wollen. Ihnen die Management-Typen 1.0, 2.0 und 3.0 zu erklären kann schmerzhaft aber hilfreich sein und ist daher zu empfehlen.

Freitag, 9. November 2018

Struktur, die aus Post-Its entsteht

Alberto Brandolini hat völlig recht wenn er sagt, dass das Identfizieren und Modellieren von Strukturen und Prozessen am besten mit bunten Zetteln auf einer grossen Wand stattfinden kann. Seine Art das zu tun nennt er Event Storming. Selbst wenn nicht alles davon in jeden Kontext passt, inspirieren lassen kann man sich durch seine Ideen auf jeden Fall.


Dienstag, 6. November 2018

Prozessverbesserung alleine ist keine Lösung

Bild: Wikimedia Commons / Johannes Martin Conrad - CC BY 3.0
Kann sich noch jemand an den Spruch "pünktlich wie die Bundesbahn" erinnern? Lange ist es her, dass das der Normalfall war. Angesichts von Verspätungsquoten von 30 % allein im Fernverkehr versucht die Bahn AG gerade gegenzusteuern. Mit dem so genannten Deutschlandtakt sollen Züge besser aufeinander abgestimmt werden, mit weiteren Massnahmen soll das Ein- und Austeigen schneller und effizienter gemacht werden. Das Ziel: mehr Pünktlichkeit.

Um die Erwartungen von Anfang an zu dämpfen: pünktlich werden die Züge auf diesem Weg nicht werden. Ein bisschen werden die Verspätungen mit Sicherheit zurückgehen, zum grössten Teil aber bestehenbleiben. Denn so gut die Prozessverbesserungen auch sein mögen, dass Hauptproblem werden sie nicht lösen können - die veralteten und immer wieder ausfallenden technischen Systeme.

Man kennt es aus den Durchsagen am Bahnsteig. Weichenstörungen unterbrechen die Fahrt, Signalstörungen verhindern die Einfahrt in die Bahnhöfe, defekte Oberleitungen bringen Züge zum Stillstand, Waggons mit ausgefallenen Klimaanlagen müssen ausgetauscht werden, defekte Schranken dürfen nur im Schrittempo passiert werden - solange das alles nicht in den Griff bekommen wird kann auch der beste Prozess nicht helfen.

Die Parallelen zu IT-Projekten und -Abteilungen sind offensichtlich. Häufig wird die Einführung von Scrum oder Kanban mit grossen Hoffnungen verbunden, die dann an der veralteten Technik und Systemlandschaft scheitern. Computer haben zuwenig Diskspace, Test- und Entwicklungsumgebungen müssen manuell eingerichtet werden, Telefonkabel aus den 70er Jahren verlangsamen die Datenübertragung, etc. etc.

Wie beim Beispiel der Bahn heisst das nicht, dass Prozessverbesserungen nichts bringen. Starre Planungen und Bürokratie zu beseitigen ist immer eine Verbesserung. Ohne die begleitenden Modernisierungen von Software und Hardware wird ihre Wirksamkeit aber deutlich eingeschränkt bleiben. Erst durch eine Kombination dieser Faktoren kann es zum befreienden grossen Sprung nach vorne kommen.

Diese Themen anzusprechen kann in vielen Unternehmen zum Offenbarungseid führen: Agilität sei als Ansatz gewählt worden weil davon ausgegangen wurde, dass die Umstellung von Meetings und Rollen mit geringem Aufwand möglich ist, für darüber hinausgehende Modernisierung wäre aber kein Geld da. Das würde doch auch bestimmt ohne gehen, oder? Derartige Aussagen sind häufiger als man denken sollte.

Die Antwort darauf kann nur eine sein: Das kann man zwar so machen, aber dann sollte man seine Erwartungshaltungen deutlich herunterfahren.

Samstag, 3. November 2018

Wie technikfern darf ein Scrum Master oder Agile Coach sein? (II)

Bild: Pexels / Tim Gouw - Lizenz
Die agile Welt ist ein Dorf. Sobald man einige Scrum- oder Kanban-Projekte ausserhalb der IT gemacht hat wird man schnell zum gefragten Ansprechpartner zu diesem Thema. Der Grundtenor klingt dabei immer ähnlich: "Ich interessiere mich ja sehr für Agilität, Scrum Master oder Agile Coach wäre was für mich. IT ist aber nicht so mein Ding. Wie finde denn ich Jobs in anderen Bereichen?" Nun ja.

Es ist nicht so als würde es diese Jobs nicht geben (zwar nicht viele, aber es gibt sie). Ich habe bereits Teams coachen dürfen die mit Scrum oder Kanban im Vertrieb, in der Hardwarefertigung, im Kundenservice und im Change Management gearbeitet haben, dazu kommen immer mehr Beispiele aus anderen Bereichen, zum Beispiel gibt es in meiner Heimatstadt Bonn sogar Scrum im Schulunterricht.

Das letzte dieser Beispiele zeigt aber auch direkt das erste Problem auf: selbst wenn manche Anwendungsgebiete IT-fern sind, einfach zugänglich sind sie aber trotzdem nicht unbedingt. Es darf eben nicht jeder an einer Schule unterrichten, dafür muss man vorher an einer Universität gewesen sein und Lehramt studiert haben. Auch in anderen Fällen stösst man schnell an Grenzen formaler Art, die nicht einfach zu überwinden sind.

Nun engt sich damit die Zahl in Frage kommender Jobs zwar weiter ein, aber es gibt sie, oder? Die Antwort: ja, aber. Sie existieren natürlich, in sehr vielen Fällen allerdings nur temporär. Agilität in Service- oder Hardware-Bereichen findet häufig da statt, wo Innovationsarbeit geleistet wird. Für Experimente, Prototypen und MVPs lohnt sich agiles Arbeiten, sobald die Serienfertigung oder -durchführung beginnt eher nicht mehr.

Scrum Master- oder Agile Coach-Stellen sind in solchen Kontexten nur zeitweise nötig. Derartige nicht-IT-Projekte leihen sich eine solche Person daher in der Regel vorübergehend aus, und zwar von da wo es sie bereits gibt - eben aus der IT. Die Alternative, das Vorhalten eines permanenten Scrum Master- oder Coach-Pools, würde eine Nachfrage voraussetzen die es in den meisten Firmen nicht gibt.

Ist die Suche nach einer Position ausserhalb der IT also völlig hoffnungslos? Das zwar nicht, realistisch betrachtet ist die Wahrscheinlichkeit einen zu finden aber sehr gering, zumindest wenn es eine langfristige Beschäftigung sein soll. Was am ehesten sein kann ist, dass sich eine temporäre Stelle finden lässt, die man mit etwas Glück besetzen kann. Es fragt sich nur - was passiert wenn dieses Projekt vorbei ist?

Die eine Möglichkeit wäre das Entlanghangeln von einer temporären Stelle zur nächsten. Nicht unmöglich aber sehr schwierig - so viele derartige Jobs gibt es auch nicht. Die andere Möglichkeit wäre, eine Beschäftigung im agilen nicht-IT-Bereich als Vorstufe für einen Einstieg in die IT zu benutzen. Aufgrund des Fachkräftemangels ist das nicht einmal unrealistisch, allerdings kommt man dann an der Beschäftigung mit der Technik nicht mehr vorbei. Dieser Umstände sollte man sich bewusst sein.

Mittwoch, 31. Oktober 2018

Kommentierte Links (XLII)

Bild: Pixabay / Bru-nO - Lizenz
  • Tim Harford: Why Big Companies Squander Brilliant Ideas

    Ein langer Text, aber lesenswert. Mit mehr als 20.000 Zeichen führt Tim Harford aus warum sich große Organisationen mit Innovationen schwer tun: zum einen weil neue, zu Beginn noch nicht profitable Ideen sich im internen Wettbewerb um Ressourcen nicht gegen die etablierten, seit langem Gewinn abwerfenden Cash Cows durchsetzen können, zum anderen weil die bestehenden Organisationsstrukturen so stark auf die bestehenden Produkte zugeschnitten sind, dass neue Produktideen nur umgesetzt werden wenn sie ebenfalls diesen Strukturen entsprechen - was häufig nicht der Fall ist. Der dritte Grund dagegen ist wesentlich polemischer und darum mit Vorsicht zu geniessen: "Because people are idiots."

  • Dennis Willkomm: Am Scheitern scheitern – Gefahren der Fehlerkultur

  • Ich freue mich ja immer wenn ich merke, dass ich nicht der erste aus der lokalen Agile-Community bin der dieses Internet vollschreibt. Dennis Willkomm hat sich hier eines selten behandelten Themas angenommen, nämlich dem, dass nicht nur die Einführung von Methoden sondern auch die Veränderung einer Unternehmenskultur im Cargo Cult enden kann. Mit Exkursen in die Psychologie unterfüttert wird eine Erkenntnis herausgearbeitet die man vielen Change Management-Abteilungen nur wünschen kann: wer glaubt seinen Mitarbeitern eine neue Kultur einfach überstülpen zu können wird damit alles mögliche erreichen, nur nicht das was er eigentlich beabsichtigt hat.

  • Alice Newton Rex: Escape From the Feature Roadmap to Outcome-driven Development

    Ein Thema das ich in letzter Zeit immer wieder in Product Owner-Workshops besprochen habe findet sich auch hier wieder: gegenüber Stakeholdern/Management/Kunden/Auftraggebern sollte sich ein Product Owner nicht zur Lieferung bestimmter Funktionalitäten verpflichten sondern zur Lieferung abstrakt formulierter Kundenmehrwerte, deren bester Umsetzungsweg sich erst im Rahmen der Umsetzung selbst ergeben wird. Dieser Ansatz widerspricht zwar dem üblichen Verhalten in vielen Organisationen (Alice Newton Rex erklärt gut warum), führt aber bereits mittelfristig zu besseren Ergebnissen als die vordefinierte Roadmap, die zuverlässig zu einem Ziel führt das von der Zielgruppe mittlerweile längst verlassen worden ist. (Siehe auch: agile Roadmaps)

  • Joe Crick: It Doesn’t Have to be Perfect

    Einige gute Gedanken zum Thema Legacy Code, nicht zuletzt deshalb weil sie nicht aus einer technischen sondern eher aus einer soziologischen Perspektive geschrieben wurden. Folgende Aspekte sind für Joe Crick im Umgang mit Legacy Code wichtig:
    • Respektiere das was er tut: er mag nicht den Standards entsprechen, aber die aus ihm bestehende Anwendung sichert Dein Einkommen.
    • Verstehe wie er entstanden ist: die Organisationsstruktur zur Zeit seiner Entstehung spiegelt sich im Code wieder (→ Conway's Law). Damals hat er vielleicht mehr Sinn ergeben als heute.
    • Lege realistische Standards an: die Aussage aus der Überschrift. Code muss nicht perfekt sein, es reicht wenn er gut ist. Beziehungsweise - gut genug für den Zweck den er erfüllen soll.
    • Sei massvoll in der Beurteilung: in den seltensten Fällen ist Legacy Code der unbrauchbare Mist als der er häufig beschimpft wird. Er mag buggy, kompliziert und umständlich sein, aber dann sollte man ihn auch nur so nennen.
    • Gehe gelassen mit ihm um: Kein Mensch ist perfekt, alle machen Fehler. Und umgekehrt und nicht alles ein Fehler was man selbst nicht versteht. Wer das akzeptiert kann besser mit den Hinterlassenschaften anderer umgehen.
    Gedanken wie diese sind praktisch immer hilfreich, und zwar nicht nur beim Schreiben von Software. Auch im Change- oder Prozessmanagement können sie von Nutzen sein, denn letztendlich ist auch die Struktur einer Firma nichts anderes als organisatorischer Legacy-Code.

  • Department of Defense, Defense Innovation Board: Detecting Agile BS

    Unter allen möglichen Orten an denen man nach einem Leitfaden zur Überprüfung von Agilität suchen würde ist eine Behörde so ziemlich einer der letzten. Und doch - wenn man es wagt wird man überrascht. Das amerikanische Verteidigungsministerium hat ein nicht nur brauchbares sondern sogar wirklich gutes Dokument entwickelt, das sich auch quer durch alle Branchen anwenden lässt. Statt Formalien abzufragen konzentriert es sich auf das Wesentliche - wird in kurzen Zyklen Mehrwert geliefert? Wird Feedback von den Anwendern (den echten, nicht deren Vorgesetzten) eingeholt? Sind wiederkehrende Tätigkeiten automatisiert? Etc. Besonders schön: um den in der Überschrift genannten "Agile Bullshit" auszufiltern sind auch typische falsche und ausweichende Antworten auf die Überprüfungsfragen vorhanden. Und jedem der in grossen Organisationen gearbeitet hat werden die sehr bekannt vorkommen.

Montag, 29. Oktober 2018

Der rotierende Scrum Master

Bild: Pixabay/MoreLight - Lizenz
Ein Phänomen das man in manchen Unternehmen beobachten kann ist der "rotierende Scrum Master". Die Rolle ist in diesem Fall nicht fest mit einer Person besetzt sondern wird in jedem Sprint von einem anderen Teammitglied wahrgenommen. Für die Dauer dieser Zeit arbeitet diese Person nicht an der Produktentwicklung mit sondern unterstützt das Team und beseitigt Impediments. Da eine solche Konstellation fast immer kontrovers diskutiert wird, lohnt es sich, einen genaueren Blick darauf zu werfen.

Zunächst die naheliegendste Frage: ist eine Rotation im Rahmen der Methodik überhaupt zulässig? Die Antwort: implizit ja. Der Scrum Guide definiert zwar die drei Rollen des Product Owners, des Scrum Masters und des Teams, legt aber nicht fest, dass es immer die selbe Person ist die sie besetzen muss. So lange alle Rollen besetzt sind ist den Formalien genüge getan.

Es gibt auch gute Gründe für ein Wechseln der Rolle zwischen den Teammitgliedern. Dadurch dass sie früher oder später von jedem ausgeübt wird liegt die Verantwortung für Prozess und Methodik bei allen und nicht nur bei einem. Gleichzeitig steigt auch die Ausfallsicherheit - ein Urlaub oder eine Krankheit des Scrum Masters lässt keine Lücke entstehen, da alle anderen in der Rolle geübt sind und sie übernehmen können.

In vielen Fällen kommt noch dazu, dass sich kein Teammitglied findet, das dauerhaft seinen bisherigen Job aufgeben möchte. Selbst wenn die Sinnhaftigkeit eines Scrum Masters eingesehen und hochgehalten wird finden viele Menschen in der Produktentwicklung eine wesentlich grössere Erfüllung. Muss das nur vorübergehend aufgegeben werden kann das die Besetzung deutlich einfacher machen.

Auf der anderen Seite gibt es auch Gegenargumente. Das naheliegendste ist, dass die Beschäftigung mit Methodik, Moderation, Coaching, etc. erstaunlich viel Zeit in Anspruch nehmen kann, und zwar nicht nur in der Durchführung sondern auch im Lernen, Weiterbilden, Reflektieren und Perfektionieren. Wird das nicht auch dann vorangetrieben wenn die Rolle gerade nicht ausgeübt wird  kommt es zu kurz um wirksam zu sein (und damit stellt sich auch die Frage nach der dafür verfügbaren Zeit).

Ebenfalls nicht zu vernachlässigen ist, dass durch eine Rotation Neutralität verloren geht. Wer bestimmte Entscheidungen der Produktstrategie oder -umsetzung (mit)verantwortet hat wird sich schwer tun Konflikte zu diesen Themen unbefangen zu moderieren. Schlimmstenfalls wird er selbst als Teil einer Konfliktpartei gesehen und nicht als Vermittler akzeptiert. Um das zu vermeiden ist eine hohe Konflikt- und Meetingkultur aller Beteiligten nötig.

Zuletzt ist es in grösseren Organisationen meistens so, dass die Einheiten und Personen ausserhalb des Scrum Teams sich einen festen Ansprechpartner wünschen. Ist dieser nicht gegeben kann ggf. das Beziehungs- und Vertrauensnetzwerk nicht entstehen, das zur schnellen und unkomplizierten Beseitigung von Impediments nötig ist. Auch das oft praktizierte Geben, Nehmen und Verrechnen von Hilfen und Gefälligkeiten wird schwerer.

Eine immer richtige Entscheidung für oder gegen einen rotierenden Scrum Master kann es aus den genannten Gründen nicht geben, wohl aber eine Entscheidungshilfe: diese Konstellation wird vor allem da funktionieren wo sowohl das Scrum Team als auch die umgebende Organisation Scrum samt des dazugehörenden Mindset sehr gut verstanden haben und es aus intrinsischer Motivation heraus befolgen. Da wo das (noch) nicht gegeben ist kann eine dauerhafte Rollenbesetzung mehr Sinn machen.

Donnerstag, 25. Oktober 2018

Backlog-Priorisierung


Die Priorisierung noch zu erledigender Arbeit scheint auf den ersten Blick ein Thema zu sein in dem sich agile und klassische Vorgehensweisen kaum unterscheiden. Auch vor der Erfindung von Scrum und Co wurde schon überlegt welche Aufgaben wichtiger und welche unwichtiger sind. Auf den zweiten Blick tun sich dagegen Unterschiede auf, die vor allem mit einem Instrument in Verbindung stehen - dem Product Backlog.

Um zu verstehen warum diese Art der Priorisierung anders ist empfiehlt sich ein Blick darauf wie Priorisierung klassischerweise stattfindet. In den meisten Unternehmen bekommen Anforderungen entweder eine Wichtigkeitsklasse (z.B. Minor, Medium, Major, Blocker) oder eine die Bedeutung anzeigende Zahl zugewiesen (z.B. 1 = unwichtig bis 100 = extrem wichtig). Je höher diese Wichtigkeitsklasse, bzw. diese Zahl sind, desto höher die Priorität.

Was in der Theorie zunächst einfach und nachvollziehbar klingt erweist sich in der Realität in der Regel als unpraktikabel. Da jeder Stakeholder ein Interesse daran hat, dass seine Anforderungen zuerst umgesetzt werden, wird er sich um eine hohe Bewertung bemühen. Im Zweifel wird ihm diese auch zugestanden werden, da mit dieser Einstufung ja noch keine weiteren Zusagen verbunden sind. Es geht an dieser Stelle nur um die Wichtigkeit, noch nicht um die Machbarkeit.

Schon nach kurzem wird dieses Vorgehen dazu führen, dass eine hohe zwei- oder dreistellige Zahl an Anforderungen als Blocker, bzw. zwischen 90 und 100 eingeordnet wird. Ist dieser Punkt erreicht ist die Priorisierung wertlos geworden. Wenn alles super-wichtig ist, dann ist alles gleich (un)wichtig. Übliche Reflexe sind jetzt die Erweiterung der Skala (z.B. um einen Showstopper-Status oder um die Zahlen 101 bis 110), was aber bald auch wieder entwertet sein wird.

Die Einträge eines Product Backlog werden dieser Bedeutungs-Inflation normalerweise bewusst entzogen, indem auf Wichtigkeitsklassen einfach verzichtet wird. Die Priorität ergibt sich hier anders, nämlich durch die Natur des Backlogs selbst. Dieses ist keine Ansammlung von unterschiedlich wichtigen Teilmengen mehr (deren jeweilige Einzelteile unter sich gleichwertig sind), sondern etwas viel Einfacheres - eine sortierte Liste.

Was eine solche Liste besonders macht ist, dass auf ihr keine Punkte nebeneinander stehen können sondern nur untereinander. Aufgelistet eben. Es gibt also immer einen wichtigsten Eintrag, einen zweitwichtigsten, einen drittwichtigsten, etc. Und wo auch immer man eine neue Anforderung dazwischenschiebt, sie wird immer jeweils ober- und unterhalb einer anderen stehen und damit automatisch priorisiert sein.

Es bleibt die Frage - wenn es so einfach ist, warum macht es dann nicht jeder so? Die Antwort - weil ein als Liste sortiertes Backlog seinen Verwalter dazu zwingt, Konflikte sowohl früh als auch immer wieder auszutragen. Es ist mit diesem Vorgehen nicht mehr möglich, jeden wichtigen Stakeholder zufriedenzustellen indem man ihm die höchste Wichtigkeitsklasse gibt. Wenn seine Idee auf Position 43 von 120 liegt (und demnach nicht so schnell umgesetzt werden wird) dann sieht er das sofort und kann das eskalieren.

Um derartige Konflikte zu vermeiden wird häufig die klassische Art der Priorisierung bevorzugt. Die Auseinandersetzungen tauchen zwar auch hier auf, aber erst wesentlich später, wenn den Beteiligten langsam dämmert, dass die scheinbar hohe Priorität weitgehend ohne Aussagekraft ist. Manche Organisationen haben es zu erstaunlicher Meisterschaft darin gebracht, diesen Punkt immer weiter nach hinten zu verlagern, mit langen Phasen des Stillstands als Folge.

Zu lernen, dass das kein zielführender Weg ist, und dass das frühe (und konstruktive) Austragen von Konflikten zwar schmerzhaft aber letztendlich besser ist, ist Teil des zu agilen Transitionen gehörenden Kulturwandels. Der ist zwar mitunter unangenehm, bringt aber einen grossen Vorteil mit sich: man ist plötzlich in der Lage Priorisierungen durchzuführen, in einer Art die diesen Namen auch verdient.

Montag, 22. Oktober 2018

Deine Muda: Warten

Bild: Wikimedia Commons / Siyuwj - CC BY-SA 3.0
Fünfter Teil der Deine Muda-Serie. Die vierte Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist das Warten. Ein interessanter Aspekt - auch das erzwungene Nichtstun kann demnach eine zu vermeidende Tätigkeit sein. Max Weber wäre begeistert.

Ähnlich wie in vielen anderen Zusammenhängen ist auch das Warten aus mehr als einem Grund problematisch. Zum einen weil es dazu führt, dass bestimmte Arbeiten später fertig werden, zum anderen wegen der Tätigkeiten die währdenddessen durchgeführt werden. Denn Nichtstun bedeutet in diesem Kontext nicht etwa völlige Untätigkeit, sondern lediglich die Untätigkeit in Bezug auf eine bestimmte Arbeit.

Zunächst aber zu den Verspätungen. Man kann es ohne grosse Erläuterungen verstehen: wenn ein Produktionsprozess immer wieder so lange angehalten werden muss, bis bestimmte Vor- oder Zuarbeiten erledigt sind, dann verlängert sich dadurch die Produktionsdauer. Wie im Fall fast aller anderen Mudas wird das Produktionsmaterial dadurch zeitweise dem Wirtschaftskreislauf entzogen. Es entsteht totes Kapital. Aber das ist noch nicht alles.

Als zweiter Effekt kommt es zu dem so genannten Cost of Delay, bzw. zu Verspätungskosten. Wäre der Produktionsprozess schon früher beendet gewesen, hätte man mit seinem Ergebnis bereits Geld verdienen können. Die Summe die einer Firma dadurch entgeht, dass das nicht möglich ist, ist mit dem Begriff des Cost of Delay gemeint.

Auch damit sind aber noch nicht alle negativen Effekte erwähnt. Was noch fehlt sind die weiter oben genannten Tätigkeiten die währdenddessen durchgeführt werden. Mit dem Warten ist nämlich das Warten des Produkts auf seine Fertigstellung gemeint, nicht etwa das Warten eines Angestellten auf Beschäftigung. Der beginnt in der Regel währenddessen bereits mit dem nächsten Arbeitspaket.

In der Praxis sieht das so aus, dass sobald an einer Arbeit kein Fortschritt mehr möglich ist eine zweite begonnen wird, sobald es auch an der nicht mehr weitergeht eine dritte, etc. Sobald die für das Weiterarbeiten an der ersten Aufgabe notwendige Zulieferung erfolgt ist werden die später begonnenen unterbrochen, es geht mit der ersten weiter, nach deren Abschluss wieder mit den späteren.

Wird auf diese Art und Weise vorgegangen treten aber zwangsläufig Probleme auf: zum einen das Multitasking mit seinen üblichen Begleiterscheinungen von Konzentrationsverlust und Umgewöhnungsaufwand, zum anderen Priorisierungskonflikte. Was ist jetzt wichtiger, die Wiederaufnahme der schon länger wartenden ersten Aufgabe oder das störungsfreie Weiterarbeiten an einer späteren? Auch diese Konflikte kosten Zeit und Geld.

In Summe sind die genannten Folgen von Wartephasen im Produktionsprozess so kostspielig, dass nach Möglichkeit versucht werden sollte sie zu vermeiden. Die einfachste Möglichkeit dazu ist die Bildung eines Crossfunktionales Teams. Wenn alle Tätigkeiten selbst erledigt werden können verschwindet mit der Abhängigkeit von anderen Gruppen die häufigste Ursache des Wartens.

Auch andere Ansätze sind möglich, etwa die bessere Abstimmung von Teams untereinander (Just in Time-Delivery) oder das Anhäufen von Vorarbeiten in einem ausreichenden Ausmass um später nicht in Leerlauf zu geraten (ein durchaus sinnvolles, aber häufig auf andere Art problematisches Vorgehen, das man sich gut überlegen sollte).

Was auf jeden Fall bewusst sein sollte: Bemühungen zur Vermeidung von Wartezeiten führen häufig zu anderen nicht gewinnbringenden Tätigkeiten (Transport, Lagerhaltung, etc.), deren Optimierung möglicherweise wieder zu neuen Wartezeiten führt. Der so entstehende Verbesserungsprozess ist dadurch nie abgeschlossen - was auch absolut Sinn macht.

Donnerstag, 18. Oktober 2018

Agile Workshops

Bild: Pxhere / Rawpixel - CC0 1.0
Zu den Aufgaben die ich bei verschiedenen Kunden habe gehört das Halten von Schulungen und Workshops. Einführung in die Grundlagen agilen Arbeitens, Einführungen in Scrum oder Kanban, Product Ownership, Skalierung, Backlog Management, etc. Mitunter werde ich sogar nur für einzelne derartige Veranstaltungen gebucht. Mein Anspruch ist dabei, dass der Begriff Agile Workshop in mehr als einer Hinsicht zuteffend ist: in Bezug auf den Inhalt aber auch in Bezug auf die Durchführung.

Ein agiler Workshop im Sinn der Durchführung ist in meinem Verständnis gegeben wenn noch während seiner Laufzeit auf sich ändernde Wünsche und Fragen eingegangen werden kann. Ein Exkurs Richtung Lean Startup wird gewünscht? Ein Eingehen auf alternative Schätztechniken wie #Noestimates? Fallbeispiele für Agilität ausserhalb der IT? Alles machbar, und zwar alles sofort, aus der Veranstaltung heraus.

Dass das möglich ist liegt daran, dass ich meine Schulungs- und Workshop-Inhalte in Module eingeteilt habe. Ein Modul agile Basics, ein Modul Scrum, ein Modul User Stories & Story Points, etc. Jedes dieser Module habe ich schon mehrfach durchgeführt, so dass ich es schnell parat habe. Und (in dem Kontext noch wichtiger) sie sind so geschnitten, dass sich einzelne oder mehrere von ihnen hinzufügen, ersetzen oder in ihrer Reihenfolge vertauschen lassen.

Dieses Vorgehen bietet Vorteile für beide Seiten: die Teilnehmer können auch noch kurzfristig Themenwünsche äussern, die (sofern sie nicht zu exotisch sind) sofort erfüllt werden können, für mich bietet es die Möglichkeit hohe Flexibilität mit berechenbarer Durchführung zu verbinden. Und auch ein weiterer Punkt kommt noch dazu - wenn ich interne Scrum Master oder Agile Coaches ausbilde können sie einzelne Module erlernen und nach und nach in den Workshops übernehmen.

Ganz ohne Voraussetzungen geht das natürlich nicht. Die Module muss man parat haben und man muss in der Lage sein kurzfristig zwischen ihnen hin- und herzuschalten. Die Agenda sollte kurzfristig modifizierbar sein (ich benutze Post Its, die sich einfach umhängen und austauschen lassen). Nicht zuletzt würde ich immer von den zu statischen Powerpoint-Präsentationen abraten und stattdessen im Rahmen der Veranstaltung Flipcharts bemalen und beschreiben. Alles das muss man können.

Angesichts des deutlich gesteigerten Ausmasses an Flexibilität und Kundenorientierung sind das allerdings Mühen von denen ich überzeugt bin, dass man sie auf sich nehmen sollte wenn man agile Workshops (in beiden Begriffsbedeutungen) durchführen will. Denn eine agile Wissensvermittlung die selbst nicht agil ist - wäre das nicht ein Widerspruch in sich?

Montag, 15. Oktober 2018

Ein Bild sagt mehr als 1000 Worte (XXII)

Für den nächsten der Innovationsbemühungen abbügeln will indem er davor warnt das Rad neu zu erfinden.


Donnerstag, 11. Oktober 2018

Wo Politik herkommt und wie man sie loswird

Eine kurze Bemerkung zum Kontext: in Firmen und ähnlichen Organisationen versteht man unter Politik nicht Regierungen, Parlamente und Wahlen sondern die unnötige Verkomplizierung von Abläufen durch Machtspiele und Konflikte zwischen Personen und Gruppen. Mit dieser Information im Hinterkopf: Bühne frei für Katherine Kirk.

Montag, 8. Oktober 2018

Warum niemand zum Sprint Review kommt

Bild: Pixabay / Magic Desk - Lizenz
Es ist eine traurige Geschichte die ich schon von vielen Scrum Teams gehört habe: der Sprint ist beendet, alle Anforderungen sind umgesetzt, alles ist in einem präsentationsfähigen Zustand - aber kein einziger Stakeholder erscheint zum Review Meeting. Nach zwei Wochen Arbeit ist das frustrierend, aber es geschieht selten ohne Grund. Folgende Ursachen habe ich bereits bei verschiedenen Teams erleben dürfen:

Es gibt keine Stakeholder

So einfach ist es manchmal. Wenn z.B. die aktuellen Entwicklungsziele die Kopfgeburt eines einzelnen Topmanagers sind, die dieser gegen den Willen aller Beteiligten durchgesetzt hat, dann ist es nicht verwunderlich wenn ausser ihm keiner erscheint.

Es wurden keine Features entwickelt, sondern Komponenten

Wenn das was entwickelt wurde nicht benutzbar und bewertbar ist, warum sollte dann jemand zum Review kommen wollen? Es gibt ja nichts worüber man reden könnte (und ganz nebenbei hat dieses Vorgehen auch nicht viel mit Scrum zu tun).

Es gab kein Sprintziel / keinen Fokus im Sprint


Wenn ein Sprint kein Ziel hat sondern stattdessen unterschiedliche Anforderungen hineingestopft werden stellen viele Stakeholder die Sinnfrage. Lohnt sich ein zweistündiges Meeting wirklich, wenn für jeden nur ein Feature dabei ist, das von Interesse ist? Eher nicht.

Es ist kein Review sondern eine Demonstration

Manche Teams führen kein Sprint Review durch sondern ein Demo-Meeting. Der Unterschied: Neuerungen werden nur vorgeführt und nicht diskutiert. Wird den Stakeholdern so die Möglichkeit zum Feedback geben genommen sinkt erfahrungsgemäss die Teilnahmebereitschaft.

Es gab keine Ankündigung

Da nicht jedes Thema für jeden gleich interessant ist kommen viele Stakeholder nicht zu jedem Review. Um sie zu aktivieren hilft es, wenn die Inhalte mit einigen Tagen Vorlauf kommuniziert werden, so dass klar ist ob sich das Erscheinen lohnt.

Die Vorführung der neuen Features ist konfus oder lustlos

Wer die Teilnehmer eines Meetings nicht ernstnimmt muss sich nicht wundern wenn sie wegbleiben. Und ein nicht vorbereitetes, unstrukturiertes oder widerwillig durchgeführtes Review ist ein Zeichen, dass dieses nicht ernst nehmen stattfindet.

Es gibt keine gemeinsamen Reviews

Ein Sonderfall für Projekte oder Produkte mit mehreren Teams. Wenn es den Anschein hat, dass zu viele Meetings stattfinden neigen, Stakeholder dazu nicht mehr alle zu besuchen. Die einzelnen Reviews zusammenzulegen kann dem entgegenwirken.

---

Natürlich gibt es noch viele weitere mögliche Gründe dafür, dass Sprint Reviews schlecht besucht sind, diese hier sind mir aber vergleichsweise häufig aufgefallen. Behebt man sie ist zumindest die Wahrscheinlichkeit, dass sich weitere Teilnehmer einfinden, deutlich höher.