Donnerstag, 18. Juli 2019

Agile Reden

FS
Bild: Flickr / European Parliament - CC BY 2.0
Vor meiner Karriere in der IT habe ich einige Jahre in der politischen Verwaltung gearbeitet und hatte dort reichlich Gelegenheit mir die Auftritte verschiedener Politiker anzuhören. Auch die neue EU-Kommissionspräsidentin Ursula von der Leyen gehörte dazu, über deren Vorstellung vor dem EU-Parlament es hiess, es sei die "Die fast perfekte Rede" gewesen. Ohne diesen Auftritt im Einzelnen würdigen zu wollen - reden kann sie, genau fast alle hochrangigen Politiker. Und faszinierenderweise kann man bei näherer Betrachtung in dieser politischen Redekunst etwas wiederfinden was man dort nicht vermuten würde: Agilität.

Um das einordnen zu können macht zunächst eine kurze Definition von Agilität Sinn: Agilität bedeutet in meinem Verständnis, in kurzen Abständen liefer- und reaktionsfähig zu sein. Das ist nicht nur in der IT eine Notwendigkeit sondern auch bei politischen Reden. Auch hier ist die Vorbereitungszeit häufig kurz (im aktuellen Beispiel von der Leyen nur wenige Tage) und auch hier muss oft kurzfristig auf geänderte Rahmenbedingungen eingegangen werden. Dass das Ergebnis trotzdem fast immer gut klingt hat seinen Ursprung in Techniken die sich auch in der agilen Softwareentwicklung wiederfinden.

Zuerst wäre unter diesen Techniken die Modularisierung zu nennen. Die Reden von Spitzenpolitikern mögen zwar in ihrer Gesamtheit immer wieder anders sein, einzelne Abschnitte in ihnen sind sich aber immer wieder sehr ähnlich und wiederverwendbar. Ein Erläuterung zu den "abendländischen Werten", eine Anekdote aus der eigenen Kindheit, ein Bekenntnis zur Klima-Politik - es sind nahezu identische Passagen, die auswendig gelernt abrufbar sind und die sich oft auch in beliebiger Reihenfolge anordnen lassen. Die meisten Politiker-Reden bestehen grösstenteils aus solchen Bausteinen.

Als zweite Technik wird häufig die Parametrisierung eingesetzt. Dahinter verbirgt sich nichts anderes als der Trick, durch das Austauschen einzelner zentraler Begriffe den Eindruck zu erwecken, spezifisch auf die jeweilige Situation einzugehen. "Für mich war [Berlin / Hannover / Brüssel] immer ein besonderer Ort", "Die Zukunft von [Deutschland / Europa / der CDU] ist ohne Werte nicht denkbar", etc. Die Wiederverwendbarkeit und Anschlussfähigkeit der auswendig gelernten Module wird auf diese Weise deutlich erhöht, genau wie die Geschwindigkeit in der sie auf die jeweilige Situation angepasst werden können.

Als dritte Technik kommt die Automatisierung dazu. Vor allem in Interviews und Diskussionen kann der Eindruck von Kompetenz und Schlagfertigkeit dadurch hervorgerufen werden, dass Antworten und Erwiderungen (scheinbar) spontan und ohne Verzögerung erfolgen. Dass das möglich ist liegt an antrainierten Automatismen. Mit häufigen Fragen oder Schlüsselbegriffen werden bestimmte, parametrisierte Rede-Bausteine verknüpft, die reflexartig abgespult werden können. Beispielsweise können viele Politiker Vorwürfe der Untätigkeit in bestimmten Politikfeldern sofort mit Konjunktur- oder Investitionsdaten kontern, die vom Aufbau ähnlich, aber je nach Fall mit unterschiedlichen Zahlen gefüllt sind.

Als vierte Technik kommt ein durchgehendes Live-Monitoring der Ergebnisse dazu. Seien es die direkten Zuhörer-Reaktionen in Parlamenten oder auf Wahlkampfauftritten oder die Signale des persönlichen Referenten im Interview - sobald erkennbar ist, dass eine bestimmte Wirkung sich aufbaut lässt diese sich durch das Abspulen bestimmter Bausteine verstärken (z.B. mit dem Modul "emotional aufgeladene Anekdote") oder abschwächen (z.B. mit dem Modul "komplizierte technokratische Erläuterung"). Auch hier kann eine Parametrisierung ("Der wissenschaftliche Dienst des Bunbdestages sagt ..." vs. "Eine von der Altersarmut bedrohte Rentnerin erzählte mir ...") zusätzlich wirken.

Natürlich sind diese Techniken nicht aus der IT übernommen worden, sie wurden parallel zu ihr und unabhängig von ihr in der Politik entwickelt. Dass sie einander trotzdem so ähnlich sind ist ein starker Indikator dafür, dass es sich um übergreifende Grundmuster handelt, die überall da anwendbar sind wo Agilität im Sine von Liefer- und Reaktionsfähigkeit von Vorteil ist.

Montag, 15. Juli 2019

Deine Muda: Defects

FS
Bild: Pixabay / EME - CC0 1.0
Achter Teil der Deine Muda-Serie. Die letzte der sieben klassischen Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist die Erzeugung fehlerhafter Produkte, so genannter Defects. Bei diesem Muda-Typ sind zwei Ausprägungen möglich: die versehentliche und die absichtliche Erzeugung.

Für jeden nachvollziehbar ist die versehentliche Erzeugung: dort wo Menschem am Werk sind werden Fehler gemacht und manchmal haben diese Fehler zur Folge, dass nicht (oder nur eingeschränkt) funktionierende Produkte erzeugt werden. Sobald das auffällt müssen Nacharbeiten stattfinden, was an sich schon ärgerlich ist. Wenn die Fehler es ausserdem noch unentdeckt durch die Qualitätskontrolle geschafft haben kommt noch der Image-Schaden dazu.

Weniger nachvollziehbar aber häufiger als man denkt ist die bewusste Produktion fehlerhafter Ergebnisse. Sei es, dass die Fertigung nicht funktioniert wie sie soll oder dass einzubauende Komponenten nur in minderer Qualität vorliegen - dort wo Quoten oder Deadlines eingehalten werden müssen ist die Verlockung gross das Problem nach hinten zu verschieben und zu reparieren "sobald Zeit dafür da ist" (was schlimmstenfalls nie der Fall sein wird).

Die offensichtlichste Folge von fehlerhaft erzeugten Produkten sind zusätzliche Kosten. Sowohl die Reparaturaufgaben als auch die nachgelagerte Qualitätssicherung kosten Arbeitszeit (und damit auch Geld), dazu kommen noch weitere Faktoren: die Verlängerung der Zeit in der Fertigung oder Reparatur verzögert auch den den Zeitpunkt des Verkaufs (→ totes Kapital, Cost of delay), schlimmstenfalls kommen Vertragsstrafen oder Materialkosten dazu.

Weniger offensichtlich aber von ähnlich schweren Auswirkungen ist die Störung des Arbeitsflusses. Immer wieder müssen bereits begonnene Arbeiten unterbrochen werden um Reparaturen vorzunehmen oder die Qualität zu überprüfen, im schlimmsten Fall müssen Dokumentationen ergänzt, Warnhinweise angebracht oder Kundenservice-Aufgaben übernommen werden. Sowohl die dadurch verursachten Konzentrationsstörungen als auch die ständigen Kontextwechsel verlangsamen die Abläufe und können weitere Fehler verursachen.

Die Massnahme zur Vermeidung fehlerhafter Produktion gehört zu den Elementen die das Toyota Production System berühmt gemacht haben: sobald ein Fehler entdeckt wird, wird die gesamte Produktion angehalten und der Produktionsprozess einschliesslich aller vor- und nachgelagerter Schritte wird repariert und verbessert. Das Besondere daran: die Berechtigung zum Anhalten der Produktion hat nicht nur das Management sondern jeder einzelne Angestellte. Nur so lässt sich der Reparatur-Prozess so schnell beginnen, dass möglichst wenig fehlerhafter Ausstoss entsteht.

Donnerstag, 11. Juli 2019

Agile Bauprojekte

FS

"Jaa, in der Software-Entwicklung, da mag das gehen. Aber in anderen Branchen ist Agilität nicht anwendbar, da passt Wasserfall viel besser!" Derartige Aussagen darf sich so ziemlich jeder Agile Coach regelmässig anhören. Und selbst wenn es mittlerweile zahlreiche andere Anwendungsbeispiele gibt, vom Flugzeugbau über den Krankenhausbetrieb bis zum Schul-Unterricht, ein letzter Rückzugsort bleibt allen Skeptikern: "Aber in der Baubranche, da geht das nicht! Agile Bauprojekte sind unmöglich!" Aber sind sie das wirklich?

Tatsächlich gibt es Bauprojekte in denen Inspect & Adapt nicht nur ausprobiert wird sondern die ohne dieses Vorgehen sogar undenkbar wären. Die klassischen Voraussetzungen für agiles Arbeiten treffen bei ihnen zu - Komplexität, Unberechenbarkeit und Änderungsanfälligkeit. Und es handelt sich dabei keineswegs um verstreute Einzelfälle sondern um solche die regelmässig vorkommen. Um ein häufiges Beispiel zu nennen: die Sanierung von Altbauten. 

Vor dem Hintergrund des steigenden Wohnungsbedarfs in den grossen Städten werden zur Zeit viele der Gründerzeit-Gebäude aus der vorletzten Jahrhundertwende renoviert oder umgebaut, wobei es zu zahlreichen ungeplanten Hindernissen kommen kann: Leitungen verlaufen anders als in den veralteten Plänen eingezeichnet, Rohre sind marode, in den Wänden werden Stahlträger entdeckt, auszutauschende Metallgitter sind tief im Mauerwerk verankert, Stuckverzierungen erweisen sich als denkmalgeschützt.

Die ursprünglichen Pläne einzuhalten ist nach Entdeckung derartiger Hindernisse schwierig bis unmöglich. Sei es, dass die ursprünglich vorgesehenen Umbauten jetzt zu langfristig geworden sind, zu teuer oder wegen Statik und Denkmalschutz nicht zulässig -  es geht gar nicht anders als Änderungen an ihnen vorzunehmen. Und da vieles erst im Rahmen laufender Bauarbeiten offensichtlich wird bedeutet das auch, dass Pläne geändert werden müssen während bereits mit ihrer Umsetzung begonnen wurde.

Sogar ein iterativ-incrementelles Vorgehen ist in derartigen Zusammenhängen häufig anzutreffen. Auf jeden Umbau eines Flügels, Stockwerks oder Zimmers folgt jeweils eine kurze, auf den im Umbau gewonnenen Erkenntnissen beruhende Aktualisierung der Statik-, Elektronik- oder Leitungspläne sowie ein Anpassen des Plans für die nächste Bauphase. In vielen Fällen sind diese Iterations-Zyklen sogar kürzer als ein Monat, so dass man das Bauprojekt sogar nach Scrum organisieren könnte.

Natürlich heisst das nicht, dass Agilität in allen Bauvorhaben Sinn machen würde, in vielen Fällen sind andere Ansätze besser geeignet. Aber um zum Anfang zurückzukommen: dass Agil und Bauen grundsätzlich nicht zusammenpassen ist ganz sicher falsch.

Montag, 8. Juli 2019

Humanity above Bureaucracy

FS
Wann immer ein Beispiel für Organisationen gesucht wird die dezentral und selbstorganisiert strukturiert sind ist die Wahrscheinlichkeit gross, dass der Name Buurtzorg fällt. Wie dieser Pflegedienst-Anbieter entstanden ist und funktioniert erklärt hier sein Gründer, Jos de Blok.

Donnerstag, 4. Juli 2019

Die Produktbeschreibung als Pressemitteilung

FS
Bild: Pexels / Rawpixel - CC0 1.0
Draussen in der Welt gibt es die Inspirationen. Letzte Woche durfte ich den Vortrag eines Amazon-Mitarbeiters hören, in dem vorgestellt wurde wie in diesem Unternehmen gearbeitet wird. Einiges davon war bereits bekannt, etwa die Micoservice-Architektur oder die 2 Pizza-Teams, anderes noch nicht. Zu den eher unbekannten Aspekten gehörte die Formulierung von Produktbeschreibungen, die bei Amazon in einer ungewöhnlichen Variante existieren: als Pressemitteilung.

Natürlich handelt es sich dabei nicht um Pressemitteilung im eigentlichen Sinn, sie sind nur für die interne Kommunikation gedacht. Ihr Inhalt ist immer so formuliert, dass er den in der Zukunft liegenden Produktions-, bzw. Vermarktungsstart beschreibt. Ob jemals eine dieser Pressemitteilungen wirklich an die Medien verschickt wurde ist unklar, es ist aber auch nicht weiter von Relevanz. Wichtig sind die Inhalte, die durch das Format erzwungen werden.

Pressemitteilungen sind kurz. Die (bei Amazon) übliche Länge ist eine Seite. Der Verfasser ist also gezwungen längliche Ausführungen zu unterlassen und sich auf das Wesentliche zu konzentrieren. Sie haben ein Datum. Dafür muss eine Idee existieren bis wann eine Fertigstellung einer ersten Version realistisch wäre. Und ganz wichtig: sie erfordern bestimmte Arten der Formulierung und des inhaltlichen Aufbaus.

Da Pressemitteilungen sich an eine breite Öffentlichkeit richten müssen sie einfach und verständlich formuliert sein, es darf kein Fachchinesisch geben. Auch inhaltlich gibt es klare Vorgaben: von oben nach unten müssen sie abnehmend relevant und zunehmend detailliert werden. Das klingt zwar abstrakt, wird bei genauerer Betrachtung aber schnell konkret.

Oben (direkt nach dem Datum) steht die Überschrift. Die sollte nicht länger als eine Zeile sein und einen ersten Eindruck geben worum es geht (z.B. "Stadt Bonn stattet Parkautomaten mit Chatbots aus"). Ggf. kann ergänzend noch eine Unter- oder Dachzeile dazukommen die weiteren Kontext gibt (z.B. "Diskussionen mit Politessen werden unnötig"). Darunter steht der so genannte Teaser, ein hervorgehobener Textblock in dem Produkt und Produktmehrwert zusammengefasst werden.

Eilige Leser sollten an dieser Stelle abbrechen können und trotzdem alle wesentlichen Informationen haben. Für alle anderen folgen in den nächsten Absätzen weitere Hintergründe. Was war das initiale Problem, bzw. der ursprüngliche Marktbedarf? Wie sah die erste Lösungsidee aus? Wie erfolgte die Konkretisierung? Was waren die ersten Schritte? Was war der Umfang der ersten Version? (zur Erinnerung, die Pressemitteilung ist aus Sicht eines in der Zukunft liegenden Release formuliert)

Neben diesen Kerninformationen können noch weitere Elemente von Pressemitteilungen genutzt werden, zum Beispiel (fiktive) Zitate des Produktverantwortlichen oder begeisterter Kunden, Infografiken oder FAQ-Boxen. Durch deren Freistellung vom Fliesstext wird das Dokument zwar länger, auch jetzt sollte es aber anderthalb Seiten nicht überschreiten um nicht unübersichtlich zu werden.

Das fertige Ergebnis kann dann in der für Produktbeschreibungen üblichen Form genutzt werden: als Unterlage für einen Pitch oder eine Genehmigung, als Ausgangslage für Workshops oder als Fokussierungshilfe für das Umsetzungsteam. In späteren Umsetzungsphasen können auch weitere Dokumente dazukommen, sie sollten aber immer auf die Pressemitteilung verweisen und ihr nicht widersprechen.

Montag, 1. Juli 2019

Kommentierte Links (XXXXX)

FS
  • Sam McAfee: Leaders, The Problem Is Not Your Agile Teams — It’s You.

  • Die hier beschriebene Ausgangslage ist häufiger anzutreffen. Ein Unternehmen holt sich einen agile Coach an Bord (egal ob intern oder extern) und gibt ihm den Auftrag "die Teams schneller zu machen". Wie von Sam CAfee richtig beschrieben liegt dahinter häufig das Missverständnis, dass Agilität ein Vorgehen wäre das im Rahmen eines (oder mehrerer) Teams umsetzbar ist, ohne dass das beauftragende Management sich selbst ändern müsste. Seine Annahme, dass der Grund dafür unqualifiziertes oder oberflächliches Handeln der oberen Ebenen ist, sollte zwar hinterfragt werden, grundsätzlich hat er aber recht- eine Transition nur auf Teamebene wird nicht funktionieren.

  • Takeshi Yoshida: Single Sprint Scrum Pilot

    Ein interessanter Kontrapunkt zur häufigen Annahme, dass iterative Vorgehensmodelle wie Scrum erst durch Übung ihre wirkliche Wirksamkeit entfalten. Takeshi Yoshida geht davon aus, dass selbst ein einziger, singulärer Sprint bereits grossen Mehrwert hat, und zwar sowohl für die Produktenticklung als auch als Showcase für das was in der Unternehmensentwicklung möglich ist. Damit hat er zwar definitiv recht, die Frage stellt sich aber ob in einem solchen Konstrukt nicht eines der zentralen Elemente von Scrum ind Agile verlorengeht: die Übernahme von regelmässigem Kundenfeedback in die weitere Produktentwicklung.

  • Helen Wassef: 5 ways Modern Agile Can Take SAFe Out of a Rut

    Um mal einen anderen Herangehensansatz an SAFe zu haben als den üblichen, sehr kritischen: genau wie andere agile Ansätze ist dieses Framework ein an sich neutraler Container, der sehr unterschiedliche Vorgehensweisen, Werte und Praktiken enthalten kann. Wenn man von dieser Prämisse ausgeht kann man durch ein spezifisches Befüllen dieses Containers dafür sorgen, dass das sehr häufige Abrutschen in starre, komplizierte und bürokratische Strukturen unwahrscheinlicher wird. Vor diesem Hintergrund ist Helen Wassefs Idee zu verstehen, Elemente von Modern Agile mit SAFe zusammenzuführen. Auf jeden Fall wäre es ein interessantes Experiment: das schwergewichtigste und das leichtgewichtigste agile Framework miteinander kombiniert.

  • Dan Ray: How to Have 15-Minute Sprint Planning Meetings

    Genau das ist es was ich meinen Teams auch immer sage! Wenn ein vernünftig priorisiertes Product Backlog vorliegt, dass gemeinsam mit dem Umsetzungsteam in einem Refinement verfeinert wurde, dann wird das Sprint Planning in wenigen Minuten durchführbar sein (ich glaube sogar, dass es in unter 10 Minuten geht). Allerdings gibt es dafür noch weitere Voraussetzungen, die Dan Ray nicht erwähnt: es sollten keine grösseren Restaufwände aus dem letzten Sprint übrig sein, es sollte keine kurzfristigen Planungsänderungen gegeben haben und das Team sollte möglichst wenig Abhängigkeiten nach aussen haben. Dann geht es.

  • Gustavo Razzetti: Dumb Rules Are Frustrating Your Best People

    Bürokratie lähmt und demoralisiert, das ist ein allgemein bekanntes Phänomen. Gustavo Razzetti versucht sich an Ratschlägen zu ihrer Vermeidung und kommt auf insgesamt fünf:
    1. Halte die Regeln einfach
    2. Bestrafe nicht die sich rational verhaltende Mehrheit durch Detailvorgaben die für eine irrationale Minderheit gedacht sind
    3. Regeln sollten ermächtigen und nicht einengen
    4. Vertraue den Menschen und sie werden es erwidern
    5. Behandle Menschen wie Erwachsene
    Es wären sicher noch weitere Ratschläge möglich, aber mit diesen anzufangen würde vielen Organisationen bereits helfen.

Donnerstag, 27. Juni 2019

Change Fatigue (II)

FS
Bild: Pixabay / TotumRevolutum - CC0 1.0
Altersbedingt (Ende der 70er geboren) gehöre ich zu der Generation deren Erwachsenwerden mit dem endgültigen Siegeszug der Digitalisierung zusammengefallen ist. Bedingt dadurch habe ich auch die letzten Rückzugsgefechte der Menschen erleben dürfen, die glaubten dem mit Einmal- oder Teilaufwänden begegnen zu können. An meiner Universität etwa beharrten manche Professoren auf der Nutzung von WordPerfect. Ein Textverarbeitungsprogramm gelernt zu haben sollte ihrer Meinung nach für den Rest ihres Lebens reichen, das Erlernen eines zweiten (MS Word) lehnten sie ab. Auch in meinem ersten Job traf ich vergleichbare Menschen. Word und Outlook hatten sie sich unter Schmerzen beibringen lassen, der Nutzung von Excel und Powerpoint verweigerten sie sich. Die Begründung: irgendwann müsse es doch genug sein mit "diesen immer neuen Computerprogrammen".

Zwar sind das Anekdoten der Vergangenheit, man kann sie aber auch als Parabel für die Gegenwart einsetzen. Damals wie heute werden die Menschen in ihrem Berufsleben mit immer neuen Tools konfrontiert. Damals Outlook, heute Slack. Damals Word und Excel, heute Jira und Confluence. Et cetera. Und sowohl bei den vergangenen als auch bei den gegenwärtigen Neuerungen sind die irgendwann auftretenden Ermüdungserscheinungen vergleichbar. "Schon wieder ein neues Tool?" "Das alte funktioniert doch noch!" "So viel mehr kann das Neue doch auch nicht!" "Können wir uns nicht endgültig auf eine Lösung einigen und dabei bleiben?" Diese und ähnliche Äusserungen dürften sich quer durch die Arbeitswelt der letzten 25 Jahre ziehen (übrigens auch quer durch alle Altersklassen).

Was die Erzählung von der Word-, Outlook- und Excel-Ablehnung besonders macht ist ihr im Rückblick besonders deutlich erkennbarer Anachronismus. Aus heutiger Sicht erscheint sie genauso irrational wie eine Ablehnung von Kugelschreibern, Notizblöcken und Briefmarken, so sehr sind die Office-Programme mittlerweile in den Alltagsgebrauch übergegangen. Es lohnt sich ein Gedankenexperiment: wie anachronistisch wird die heutige Ablehnung neuer digitaler Werkzeuge in 15 oder 25 Jahren wirken? Wie vorgestrig werden diejenigen erscheinen die nicht mit Chatprogrammen arbeiten wollen, da sich doch alles mit Emails verschicken lässt? Wie aberwitzig wird die Aussage herüberkommen kein Wiki zu brauchen, da es doch gemeinsame Laufwerke gebe?

Natürlich, für jeden der heute das Gefühl hat sich an immer neue Tools gewöhnen zu müssen sind solche Gedanken nur bedingt tröstlich. Und ja, nicht alles was zur Zeit neu eingeführt wird werden wir in 10 Jahren noch benutzen. Ist es demnach nicht ein vertretbarer Mittelweg sich erstmal zurückzuhalten, andere die ersten Erfahrungen machen zu lassen und erst dann mit einzusteigen wenn sich die neue Idee durchgesetzt hat? So verlockend das auch klingen mag, eine Option ist es leider nicht. Konsequent durchgezogen würde es die eigene Firma zum Nachzügler der Modernisierung machen, bei dem neue Möglichkeiten erst als letztes genutzt werden können und um das alle mit Pioniergeist und Zukunftsoffenheit ausgestatteten Arbeitskräfte einen grossen Bogen machen werden. Ein solches Unternehmen wird kaum wirtschaftlich erfolgreich sein.

Es bleibt das finale Argument: "Aber ich kann nicht mehr!" "Die ganzen Veränderungen sind zu viel für mich!" "Nimmt den hier keiner Rücksicht auf mich?" Ein Aufschrei dem man kaum begegnen kann ohne hartherzig zu wirken, oder? Das kann man auch anders sehen. Nur weil einige nicht mehr dazulernen wollen soll eine ganze Organisation ihre Zukunfsfähigkeit aufs Spiel setzen, und mit ihr auch die aller anderen Angestellten, die in einer veraltenden Arbeitswelt eingekapselt sein würden? Das kann nicht die Lösung sein. Ohne die Bereitschaft zur Veränderung sind die meisten Jobs heute nicht mehr ausübbar. Diese Erkenntnis ist nicht für jeden schön, an ihr vorbeikommen wird man aber genausowenig wie die zu Beginn erwähnten Damen und Herren an Word und Excel vorbeigekommen sind.

Donnerstag, 20. Juni 2019

Agiles Change Management (III)

FS
Bild: Pexels / Rawpixel - CC0 1.0
Es ist eine der kleineren Meldungen, die im grossen Nachrichtengeschehen kaum Aufmerksamkeit finden: zum ersten mal seit dem Krieg hat die CDU die Landratswahl in Osnabrück verloren. Gewonnen hat stattdessen eine Anna Kebschull von den Grünen. Was diese Lokalmeldung besonders macht ist eine ihrer Aussagen nach der Wahl: "Mein Stil sieht vor allem Transparenz und eine Kommunikation vor, die nicht vorgefertigte Pläne vorlegt und dann durch Sprachregelungen anderen Leuten erklärt, warum sie sie gut zu finden haben. Ich will offen Probleme ansprechen, Lösungen vorschlagen, Expertisen einholen und Akteure vor Ort einbeziehen, um gemeinsamen Pläne zu stricken." Das ist etwas Besonderes.

Klassisches Change Management funktioniert in seiner Kommunikation genau umgekehrt, nämlich so wie Kebschull es mit ihren treffenden Worten beschreibt: den Menschen wird nur noch erklärt warum sie das fertig festgelegte und geplante Vorgehen gutzufinden haben. Das gibt es in der Politik (mit der berüchtigten Formulierung alternativlos), das gibt es aber auch in der freien Wirtschaft, bei Umstrukturierungen, Strategiewechseln, Entlassungen, etc. Der Grund dafür ist, dass dieses Vorgehen wunderbar zur alten Top-Down- oder Wasserfall-Welt passt. Planung, Durchführung, Verkündung - das ist idealtypische Sequenzialität. Und idealtypisch in mehr als eines Hinsicht: für die Realität ist sie kaum geeingnet.

Selbst wenn man annimmt, dass es vielleicht wirklich alternativlose Entscheidungen gibt - die meisten sind es nicht, mit ihnen sollte man anders umgehen. Dort wo die Zukunft nocht nicht klar absehbar ist (und damit dort wo Agilität und agiles Change Management Sinn machen) kann das blosse "Durchkommunizieren" bereits beschlossener Pläne keine Option sein. Stattdessen muss die Durchführung frühzeitig und regelmässig durch Überprüfung und Feedback validiert werden, mit der begleitenden Kommunikation als zentralem Faktor. Wenn diese nämlich nicht nur von oben nach unten sondern auch von unten nach oben verläuft kann sie wertvolle Informationen zu Sinnhaftigkeit und Akzeptanz eines Vorgehens enthalten.

Oben angekommen sollten diese Rückmeldungen die Grundlage eines Inspect & Adapt-Prozesses sein, dessen Ergebnisse wieder nach unten weitergegeben werden, als Grundlage für weiteres Feedback nach oben. Etc., etc. Um im Rahmen dieser Kommunikationsschleifen nicht zu erstarren muss aber eine weitere Voraussetzung gegeben sein: Geschwindigkeit. Nur wenn die Feedbackschleifen kurz sind kann auch die Reaktion auf Veränderung rechtzeitig erfolgen, sind sie zu lang wird nur an den Problemen der Vergangenheit gearbeitet, nicht an denen der Gegenwart. Und ja, derartig schnelles Feedback ist auch in grossen Organisationen möglich, dafür gibt es Beispiele.

Für Change Management-Einheiten die bisher nur auf Verkündung ausgerichtete Einwegkommunikation gewöhnt waren bedeutet ein derartiges Vorgehen eine fundamentale Neuausrichtung, weg von gewohnten und lieb gewonnen Mustern. Das kann weh tun. Allen die davon betroffen sind kann man aber raten sich durch diese Schmerzen zu arbeiten. Die Alternative wäre noch unangenehmer: irgendwann feststellen zu müssen gar kein Change Management zu sein sondern ein Planwirtschafts- oder Stillstandsmanagement.

Montag, 17. Juni 2019

Die 10 Voraussetzungen von Scrum

FS
Bild: pxhere - CC0 1.0
"Wir haben es mit Scrum versucht, aber es funktioniert nicht!" Diese irgendwo zwischen Stossseufzer und Resignation schwankende Aussage dürfte schon in vielen Firmen gefallen sein. "Natürlich nicht, bei Euch fehlen die Voraussetzungen!" ist die in den meisten Fällen zu hörende Antwort. Was diese Voraussetzungen sind bleibt allerdings häufig unausgesprochen. Das muss nicht so sein, in den meisten Fällen reicht ein Blick in den Scrum Guide. Aus ihm lassen sie sich ableiten. Im folgenden zehn wichtige von ihnen, samt einer kurzen Erläuterung.

1. Scrum is founded on [...] empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known

  • Was heisst das? Dass Scrum Teams alle relevanten Zahlen kennen müssen. Nicht nur Bugrate und Umsetzungszeit sondern auch Herstellungs-, bzw. Personalkosten, Kundenbewertungen, Nutzungsdaten, Marktforschungsergebnisse, etc.
  • Warum ist das wichtig? Weil ohne Datengrundlage alle Verbesserungsversuche nur auf Mutmassungen basieren könnten und nicht validierbar wären

2. Everyone focuses on the work of the Sprint and the goals of the Scrum Team

  • Was heisst das? Dass es für die Mitglieder eines Scrum Teams keine Teilzeit-Zugehörigkeit und keine Zusatzaufgaben geben darf
  • Warum ist das wichtig? Weil Kontextwechsel und Verfügbarkeitsengpässe zwangsläufig dazu führen, dass Konzentration abnimmt, Wartezeiten und Konflikte dafür zunehmen

3. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work

  • Was heisst das? Dass alle sich darauf einlassen, dass die Zukunft sich anders entwickelt als es geplant wurde, wodurch auch das Ergebnis ein anderes sein kann
  • Warum ist das wichtig? Damit nicht weiter an obsolet gewordenen Plänen festgehalten wird, die nicht mehr zu Rahmenbedingungen und Marktbedürfnissen passen

4. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team

  • Was heisst das? Dass die Selbstorganisation ernst gemeint ist. Nur das Scrum Team selber entscheidet wieviel Arbeit es in den Sprint nimmt, welche Metriken es erhebt, etc.
  • Warum ist das wichtig? Um Bürokratie und Ineffizienz zu vermeiden. Die Effekte von Top Down-Management (Stille Post-Effekte, Reporting-Overhead, Entscheidungsverzögerungen, unrealistische Planungen) sollen vermieden werden

5. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team

  • Was heisst das? Dass jede Fähigkeit die zur Herstellung eines Produkts nötig ist im Team vertreten sein muss, egal ob es um Backend, Frontend, UX, Marketing, Recht oder sonst etwas geht
  • Warum ist das wichtig? Weil externe Abhängigkeiten immer wieder dazu führen, dass benötigte Personen nicht verfügbar sind und Arbeiten deshalb nicht beendet werden können

6. Incremental deliveries of "Done" product ensure a potentially useful version of working product is always available

  • Was heisst das? Dass nach jedem Sprint ein Produktionsrelease möglich ist. Er muss nicht stattfinden, er muss aber möglich sein
  • Warum ist das wichtig? Weil sonst die Gefahr besteht, dass sich Integrations-, Release- oder Dokumentationsaufwände zu einer Bugwelle stauen die am Ende nicht mehr bewältigbar ist

7. For the Product Owner to succeed, the entire organization must respect his or her decisions

  • Was heisst das? Dass der PO entscheiden darf ob bestimmte Funktionen ein- oder ausgebaut werden oder ob das unterbleibt
  • Warum ist das wichtig? Um zu verhindern, dass Managementrunden, Steuerungskommittees oder andere Kontrollgremien zu Verzögerungen oder politisch getriebenen Entscheidungen führen

8. Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint

  • Was heisst das? Dass die Teamgrösse zwischen 3 und 9 Mitgliedern (plus PO und Scrum Master) liegen muss (diese Zahlen sind ebenfalls aus dem Scrum Guide)
  • Warum ist das wichtig? Weil zu kleine Teams hohe Ausfallrisiken haben und nicht crossfunktional sein können und grosse zu starke Effizienzverluste durch hohen Kommunikationsbedarf haben

9. Scrum Masters do this [promoting and supporting Scrum] by helping everyone understand Scrum theory, practices, rules, and values

  • Was heisst das? Dass der Scrum Master nicht nur für das Coaching des Teams zuständig ist sondern auch für das Coaching von Managern und Stakeholdern
  • Warum ist das wichtig? Weil sonst den (ggf. versehentlich) destruktiv handelnden Personen die Tragweite ihrer Handlungen nicht bewusst wird

10. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint

  • Was heisst das? Dass a) Stakeholder im Review-Meeting anwesend sein müssen und b) sie dort aktiv Feedback geben müssen statt nur zuzuhören
  • Warum ist das wichtig? Um zu vermeiden, dass das Scrum Team versehentlich am Bedarf vorbei produziert und schlimmstenfalls betriebsblind wird


Um es klar zu sagen: das sind anspruchsvolle Voraussetzungen, vor allem für grosse und hierarchische Organisationen. Im Zweifel sind sie nicht sofort erreichbar, was aber nicht schlimm ist, so lange man sie erreichen will und darauf hinarbeiten kann (jede Firma sollte sich dann aber fragen ob sie diesen Zustand bereits Scrum nennen will). Vielleicht passen sie aber auch gar nicht zur Unternehmenskultur und -struktur - dann ist Scrum vermutlich nicht der passende Ansatz.

Donnerstag, 13. Juni 2019

Design Sprints (am Beispiel von illegalem Whisky)

FS
Es geht doch nichts über eine Erklärung komplexer Sachverhalte anhand von abseitigen Beispielen.

Montag, 10. Juni 2019

Der vergessene Ursprung von Scrum

FS

Eigentlich könnte man denken, dass über die Ursprünge von Scrum alles bekannt ist. Die Grundidee wurde in den 80er Jahren von japanischen Fabrikteams entwickelt und von Hirotaka Takeuchi und Ikujiro Nonaka in ihrem bahnbrechenden Artikel im Harvard Business Review The New New Product Development Game beschrieben, in dem auch erstmalig das Wort Scrum auftaucht. Ab 1993 wurden diese Erkenntnisse von Ken Schwaber und Jeff Sutherland auf die IT übertragen und 1995 wurde das so entstandene Vorgehensmodell der Öffentlichkeit vorgestellt. Zumindest ist das die weitverbreitete Annahme.

Was in diesem Zusammenhang wenig beachtet wird ist ein Buch aus dem Jahr 1990, das den Titel Wicked Problems, Righteous Solutions trägt und von zwei Amerikanern namens Peter DeGrace und Leslie Hulet Stahl verfasst wurde. DeGrace und Stahl wollten in diesem Werk die Probleme aufzeigen die durch die Anwendung eines Wasserfall-Vorgehens auf einen Softwareentwicklungsprozess enstehen und mögliche Alternativen erörtern. Neben anderen, mittlerweile vergessenen Ansätzen wie Whirlpool, Sashimi und Hollywood stellten sie auch einen namens Scrum vor, der auf autonomen, crossfunktionalen selbstorganisierten Teams beruht.


Nun könnte diese inhaltliche Ähnlichkeit, zeitliche Nähe und gleiche Benennung auch Zufall sein, sie sind es aber nicht. Schwaber und Sutherland kannten das Buch von DeGrace und Stahl und bauten darauf auf (siehe hier und hier). Der offensichtlichste Hinweis darauf ist die Benennung: sowohl das "alte" als auch das "neue Scrum" berufen sich auf den oben genannten Artikel von Takeuchi und Nonaka, The New New Product Development Game. Was dabei leicht übersehen werden kann - in ihm wird das Vorgehen als Rugby Approach beschrieben, das Wort Scrum kommt nur einmal vor, und das an einer wenig prominenten Stelle. Die Übertragung dieses Namens auf das ganze Vorgehensmodell wurde erstmals in Wicked Problems, Righteous Solutions durchgeführt und von dort weiter übernommen. Dieses Buch ist also tatsächlich die Initialzündung.


Die Pionierarbeit von DeGrace und Stahl besteht wesentlich daraus, überhaupt den Harvard Business Review-Text zu finden und zu realisieren, dass sich seine Erkenntnisse auf die Softwareentwicklung übertragen lassen (was u.a. voraussetzt dieses Magazin überhaupt gelesen zu haben). Aus heutiger Sicht erscheint das zwar naheliegend, da sich gerade diese Arbeit so stark für iteratives und incrementelles Arbeiten eignet wie keine andere. Man darf aber eines nicht vergessen: zum damaligen Zeitpunkt gab es diese Erkenntnis noch nicht. Trotzdem einen Artikel über die Fertigung von Hardware in japanischen Fabriken zu lesen und zu erkennen, dass er auch im Kontext einer völlig andere Industrie Sinn macht, ist keineswegs etwas Naheliegendes worauf man schnell kommen würde. 


Sogar einer der zentralen Slogans des heutigen Scrum findet sich bereits im Buch von DeGrace und Stahl. Es ist das kontrovers diskutierte doing twice the work in half the time. In Wicked Problems, Righteous Solution wird es noch weniger griffig formuliert, es heisst dort you further unsettle the team by saying that their job is to produce the system in, say, half the time and money and it must have twice the performance of other systems. Das ist zwar anders, aber klar widererkennbar.


Um Schwaber und Sutherland nicht zu schlecht dastehen zu lassen muss man ergänzen, dass viele der heute zentralen Elemente von Scrum bei DeGrace und Stahl noch nicht zu finden sind. Es gibt keinen Scrum Master, keine Sprints und keine Retrospektiven. Andere, wie z.B. die incrementelle Lieferung, kommen zwar vor, werden aber separat von Scrum erläutert. Scrum im heutigen, engeren Sinn haben also tatsächlich die beiden Herren erfunden die dafür bekannt geworden sind.


Edit: 26.06.2019
Ursprünglich stand in diesem Artikel, dass Schwaber und Sutherland nicht auf die Vorarbeit von DeGrace und Stahl verwiesen hätten. Haben sie doch. Danke an Jan Fischbach für den Hinweis und Schande über den Autor. Die hier stehenden Fake News wurden entfernt.

Donnerstag, 6. Juni 2019

Start where you are (II)

FS
Bild: Max Pixel - CC0 1.0
Das mit dem Kanban-Prinzip Start where you are ist bekanntlich so eine Sache. An vielen Stellen muss man zuerst Klarheit darüber schaffen, was der Ist-Zustand ist, häufig verbunden mit der schmerzhaften Erkenntnis, dass der offizielle Prozess nur eine Fassade (so genanntes Business Theater) ist, während das gelebte Vorgehensmodell ganz anders aussieht. Selbst das lässt sich aber nochmal ins Unschöne steigern, und zwar auf eine Art die gerade in agilen Transitionen häufig ist.

Ein immer wieder anzutreffendes Phänomen ist es, dass eine festgefahrene Transition erst dann wieder Fahrt aufnehmen kann wenn man sich in Bezug auf die bisher erzielten Ergebnisse ehrlich macht. Und dort wo man sich an diese Wahrheiten traut kann es peinlich werden: gerade die scheinbaren Vorzeige-Erfolge entpuppen sich häufig als Missverständnis, nicht zielführende Umsetzung oder im schlimmsten Fall sogar Etikettenschwindel.

Einfach ist es noch dort wo offensichtlich getrickst wurde. Wenn nur bestehende Rollen, Prozesse und Meetings ohne inhaltliche Änderung umbenannt wurden lässt sich der Finger schnell in die Wunde legen. Das kann zwar für diejenigen peinlich sein die sich mit den scheinbaren Erfolgen gebrüstet haben, im den meisten derartigen Fällen ist der Etikettenschwindel aber ohnehin ein offenes Geheimnis, dessen Aufdeckung nur mit einem "endlich sagt es mal einer" kommentiert wird.

Schwieriger ist es in Konstellationen in denen in grösserem Ausmass Cargo Cult anzutreffen ist. Wenn die Verantwortlichen und Beteiligten aufgrund von fehlendem Verständnis bisher davon überzeugt waren alles richtig gemacht zu haben, dann kann das Aufdecken dieser Illusion eine unschöne Überraschung sein, häufig verbunden mit emotionalen Abwehrreaktionen. Diese sanft aufzufangen und sachlich auf die Missverständnisse hinzuweisen kann eine herausfordernde Aufgabe sein.

Wirklich kompliziert kann es dann werden, wenn zwar das richtige Verständnis und grundlegend richtige Massnahmen anzutreffen sind, die scheinbaren Erfolge aber nur auf unerkannten Seiteneffekten beruhen. Ein Beispiel dafür könnte ein Kanban-Pilotteam sein, dass scheinbar seinen Wertstrom erfolgreich optimiert hat, bei dem in Wirklichkeit aber die Protegierung durch den Geschäftsführer zu einer Vorzugsbehandlung im Vergleich zu anderen Teams geführt hat, wodurch die unverändert im System vorhandenen Unwuchten bei Auslastung und Staffing einfach an andere Stellen verlagert werden.

In derartigen Fällen muss das Start where you are dazu führen, dass das scheinbare Erfolgsmodell als Problemfall erkannt und offensichtlich gemacht wird. Nur dann kann der kontinuierliche Verbesserungsprozess einen Ansatzpunkt finden und Wirkung entfalten. Die Reaktionen darauf können nochmal heftiger ausfallen als im Fall der Cargo Cult-Implementierung, schliesslich können die Beteiligten zu Recht darauf verweisen "alles richtig gemacht zu haben". Diesen Frust ernst zu nehmen, in konstruktive Bahnen zu lenken und zum Ausgangspunkt einer echten Transition zu machen ist dann das Meisterstück des verantwortlichen Change Managers.

Montag, 3. Juni 2019

"El Jefe", der Kunde

FS
Bild: Wikimedia Commons / Er nun wieder - CC BY-SA 3.0
Einmal mehr ist es der Zufall durch den eine interessante Geschichte zu Stande kommt. Zu Besuch bei dem in Spanien lebenden Teil der Familie kam das Gespräch zufällig auf die Supermarktkette Mercadona, die in den letzten Jahrzehnten viele ihrer Konkurrenten verdrängt hat. Das wäre auf ein fortschrittliches Management-Konzept zurückzuführen, hiess es. Neugierig geworden nutzte ich später die Zeit am Flughafen für eine kurze Recherche, und tatsächlich - im Wall Street Journal, in El Pais und in Publikationen der Harvard Business School liess sich einiges über dieses Unternehmen finden was sich bemerkenswert anhört.

Eine der interessantesten Ideen ist die Hierarchie der verschiedenen Zielgruppen und Stakeholder die durch das Unternehmen bedient werden sollen. Der Wichtigkeit nach absteigend sind das der Kunde, die Angestellten, die Gesellschaft, die Lieferanten und die Eigentümer. Das ist bemerkenswert: nicht nur, dass der Kunde an der Spitze steht (das behaupten fast alle Firmen von sich), sondern auch das was danach kommt - Angestellte, Gesellschaft und Lieferanten nicht nur als Zielgruppe zu nennen sondern sie sogar über den Eigentümern einzuordnen ist etwas was ich noch nicht gehört habe.

Ungeachtet dessen scheint es so, dass auch versucht wird dem Anspruch der Kundenorientierung gerecht zu werden. Dazu gehört nicht nur freundliches, gut ausgebildetes Personal (kann ich aus eigener Anschauung bestätigen) sondern auch darüber hinausgehende Ansätze: das Management wird angehalten regelmässig auf der Verkaufsfläche mit Kunden zu sprechen, und nicht nur im sondern auch um die Supermärkte findet Marktforschung statt. Etwa durch Kundenmanager die in den umliegenden Cafes mit den Kunden über ihre gerade getätigten Einkäufe reden.

Apropos Personal: um die Wünsche des Kunden (intern "El Jefe" genannt) besser erkennen und umsetzen zu können sind die Teams der einzelnen Supermärkte so crossfunktional wie möglich. Das heisst nicht nur, dass sie (wie auch in Deutschland üblich) je nach Bedarf zwischen Kassieren, Reinigen und Einräumen wechseln können, sondern dass sie Fortbildungen in Warenkunde, Kundenansprache, Betriebswirtschaft und Logistik erhalten. Mit Hilfe dieses Wissens sind sie in ganz anderer Weise in der Lage Prozesse erkennen, beurteilen und optimieren zu können.

Diese Optimierungen finden schliesslich fast nie in Form von grossen Change-Programmen statt sondern durch viele, kleine, ständig durch Feedback verbesserte Schritte. Mal ist es die Einführung von Familienpackungen, mal die Reduktion von Verpackungsmüll (beides in Kooperation mit Lieferanten), an anderen Stellen werden Arbeitsschritte automatisiert (z.B. bei den Preisanzeigen), Beratungsangebote verbessert, Transportwege verkürzt oder Recyclingquoten erhöht.

Ein weiteres Beispiel dafür wo man lean und agile Praktiken finden kann. Nicht nur bei Google und Spotify sondern auch um die Ecke, im nächsten Supermarkt.

Freitag, 31. Mai 2019

Kommentierte Links (XXXXIX)

FS
  • Steve Denning: Understanding Fake Agile

  • Der Titel dieses Artikels ist leicht irreführend, da Steve Denning in ihm nicht nur das beschreibt was er (zu Recht) als "Fake Agile" bezeichnet sondern auch Frühstadien und Mischformen die nicht unbedingt schlecht sein müssen. Im Einzelnen spricht er von den folgenden Typen:
    • Agile im Frühstadium
    • Etikettenschwindel-Agile
    • Agile nur in der Software-Erstellung
    • Angehaltene Agile Transition
    • Gebrandetes Agile
    • Skaliertes Agile (v. A. SAFe)
    • Agile light
    Besonders mit dem vorletzten Punkt hat er natürlich für Gesprächsstoff gesorgt, da er damit einen nicht unwesentlichen Teil aller sich als agil empfindenden Firmen angreift. Die Art wie denen mittlerweile gegenübergetreten wird wäre aber ein Thema für sich und geht über Dennings Artikel hinaus (siehe auch: Extremists and the hate SAFe machine).

  • Michael Küsters: It's still about agile teams

    Ein Text der auch als Reaktion auf Dennings Fake Agile-Artikel verstanden werden kann kommt von Michael und versucht sich an der Ehrenrettung von SAFe. In Anerkennung des Phänomens, dass ein Grossteil der SAFe-Implementierungen mit Agilität nicht viel zu tun hat weist er darauf hin, dass nicht alles was schlecht funktioniert auch schlecht gemeint ist. Vor allem mit dem ersten Punkt aus einer von ihm zusammengestellten Liste wiederholt auftretender Probleme dürfte er den Nagel auf den Kopf getroffen haben: SAFe wird als Management-Methode wahrgenommen und nicht als Ansatz der Produktentwicklung. In der Realität dürfte genau das die Ursache für die meisten fehlgeschlagenen Umsetzungen sein. Michaels Gegenmodell einer SAFe-Variante die die Entwicklung und Unterstützung der unteren Arbeits-, bzw. Teamebene in den Mittelpunkt stellt ist zwar idealistisch, in der Realität aber leider fast nicht existent.

  • Allen Helton: The 5 W’s of Rapid Prototyping

    Aus dem Grossen (der Skalierung) in Kleine. Rapid Prototyping ist eine Entwicklungsvariante die auch da Sinn macht wo von Agilität noch in den Anfängen steckt, die aber ebenfalls in fortgeschrittenen agilen Kontexten anzutreffen ist. Ähnlich wie ein MVP oder ein Proof of Concept ist ein Prototyp ein noch unfertiges Zwischenergebnis, mit dem schon erste Annahmen validiert oder erste Tests durchgeführt werden können. Agil wird diese Idee in Form des Rapid Prototype, was bei Allen Helton bedeutet, dass er innerhalb eines Sprints fertiggestellt werden kann. Anhand von Beispielen erläutert er wo ein solches Vorgehen Sinn macht, wie man es erreichen kann, was als Ergebnis herauskommen könnte und wer mitarbeiten sollte. Das klingt bei ihm erstmal einfach, ist es aber natürlich nicht. Ohne Produktvision, Nutzerverständnis und technische Exzellenz ist Rapid Prototyping nicht zu haben. Was aber auch zu beachten ist: selbst wenn man durch den Versuch einen Rapid Prototype zu bauen nur ein bisschen besser in diesen Bereichen wird ist auch das schon ein Gewinn.

  • Matthew Strom: Responsive Roadmaps

    Über die Gemeinsamkeiten von Product Roadmaps und geografischen Karten hatte ich schon mal etwas geschrieben, Matthew Strom denkt diese Idee aber nochmal in eine andere Richtung weiter. Angelehnt an die Darstellungsprobleme von Weltkarten zeigt er eine Fehlwahrnehmung auf die mit klassischen Roadmaps verbunden ist: statt sie als vereinfachte Darstellung zu sehen, aus der man für bessere Verständlichkeit einen Teil der Komplexität ausgeblendet hat, werden sie für ein repräsentatives Abbild der Realität gehalten. Sich derartig an ihnen zu orientieren würde aber genau so wenig ans Ziel führen wie eine Übersee-Navigation anhand einer Mercator-Karte. Sein Alternativvorschlag ist erkennbar an das Objectives and Key Results-Modell (OKR) angelehnt, was diesen Artikel aus noch einem anderen Grund lesenswert macht - es zeigt was man mit OKRs alles anfangen kann wenn man aufhört darin nur ein Instrument der Menschenführung zu sehen.

  • Stefan Barth: Wann muss das Management in agile Teams eingreifen?

    Noch einmal ein neuer Blick auf ein Thema über das ich schon einmal nachgedacht habe. Unter welchen Umständen darf ein Manager eingreifen und einem selbstorganisierten Team eben diese Selbstorganisation wieder wegnehmen? Die vereinfachte Antwort: wenn es Dysfunktionen entwickelt die so schwerwiegend sind, dass es sie selbst nicht mehr beheben kann. Dass Stefan das derartig offen anhand von (anonymisierten) Fällen aus der eigenen Firma bespricht ist einer der seltenen Fälle in denen offen über ein Phänomen gesprochen wird das häufiger ist als man denkt.

Dienstag, 28. Mai 2019

Ein Bild sagt mehr als 1000 Worte (XXV)

FS

In einer besseren Welt wäre das ein Burndown-Chart geworden. Aber es hat nicht sollen sein.

Donnerstag, 23. Mai 2019

Frontline Staff driven Improvement

FS
Normalerweise würde man die agilen Vorgehensweisen mit ihren kurzen Lern- und Feedbackzyklen und schnellen Reaktionen vor allem in der IT erwarten, wo sie auch bis heute schwerpunktmässig vorkommen. Beispiele für eine Umsetzung in einem anderen Umfeld gibt es trotzdem, und gerade wegen ihrer Ungewöhnlichkeit sind sie in vielen Fällen bemerkenswert. Der Grund dafür ist, dass den Beteiligten die gängigen Frameworks oft gar nicht bekannt sind, weshalb sie Vieles selbst entwickeln und so zu methodischen Innovationen beitragen. Ein derartiger Fall sind die Cleveland Kliniken, eine Krankenhauskette in den USA.



Was in diesem Video zu sehen ist, ist ein auf zweimal täglich stattfindenden "Huddles" (Standup Meetings) beruhender Verbesserungsprozess. Jedes Team führt sie für sich selbst durch, identifiziert hier Verbesserungspotentiale und arbeitet an ihrer Umsetzung. Als Umsetzungshilfe wird dabei ein selbstentwickeltes Improvement Model genutzt, das die Verbesserungsprozesse visualisiert und so vergleichbar und nachverfolgbar macht.

Da zwar viele aber nicht alle Probleme auf diese Art und Weise gelöst werden können kaskadiert der Prozess nach oben. Sobald die Teams der untersten Hierarchieebene sich besprochen haben geben sie die nicht selbst lösbaren Probleme an das zeitlich anschliessende Huddle der nächsthöheren Hierarchieebene weiter. Auch dieses löst möglichst viel davon selbst und gibt den Rest an die nächsthöhere Ebene weiter, die genauso verfährt. Da alle Huddles zeitlich begrenzt sind und aufeinander folgen sind die morgens auf den Stationen festgestellten Probleme spätestens Mittags dort angekommen wo sie gelöst werden können - selbst dann wenn das die oberste Geschäftsführung ist.

Mit diesen so genannten "Tiered Huddles" sind bei den Cleveland Kliniken bemerkenswerte Strukturen entstanden, die so auch in agilen Firmen nicht häufig zu finden sind. Vor allem die Kombination aus Subsidiarität und leichtgewichtigen Prozessen macht eine enorme Geschwindigkeit in der Abstimmung, Informationsübermittlung und Problemlösung möglich. Inspirierend.



Montag, 20. Mai 2019

Story Points entsprechen Zeit (und passen trotzdem auf keinen Zeitstrahl)

FS
Bild: Pixabay / Geralt - CC0 1.0
Zu den am häufigsten missverstandenen Elementen agiler Arbeitsweisen gehören Story Points. Von klassischen Projektmanagern werden sie häufig in Zeiteinheiten umgerechnet, was bei den meisten agil arbeitenden Team zu heftigen Abstossungsreaktionen führt. Auf die Frage was diese Punkte denn dann sein sollen wenn nicht Zeit wird häufig erklärt, dass sie die Komplexität der geschätzten Arbeit anzeigen, was nicht in Stunden oder Tage umrechenbar wäre. Für alle die dieser Meinung sind dürfte die letzte Woche ein unangenehmes Erwachen gewesen sein.
Der Herr der diese (rhetorische) Frage stellt ist Ron Jeffries, und was er andeutet stimmt - er gehörte in den 90ern zu den Erfindern der Story Points. Er weiss also tatsächlich wie sie gemeint sind und was sie bedeuten sollen. Auch zum Thema Komplexität hat er eine Meinung - und es ist keine gute.
Für ihn ist also klar, dass Story Points Zeit bedeuten und nicht Komplexität. Und wie gesagt, er ist der (Mit)Erfinder. Haben die oben genannten Projektmanager demnach recht wenn sie einen Punkt mit einer Stunde gleichsetzen? Nun - nein. Auch nicht. Es ist (Ironie der Geschichte) komplexer als das.

Zunächst ist ein Story Point eine neutrale Schätzgrösse. Die ist nötig, da unterschiedliche Menschen für die selbe Aufgabe unterschiedlich viel Zeit brauchen. Je nachdem wer an ihr arbeitet dauert es also mehr oder weniger lang (siehe hier). Zur Ermittlung der Umsetzungsdauer einzelner Aufgaben sind Story Points demnach unbrauchbar. Genau diese Einzelfallschätzung ist es aber, die häufig verlangt wird - und dass das nicht funktionieren kann ist dann Ursache der oben genannten Abstossungsreaktionen.

Was aber machbar ist, ist die Verwendung von Story Points für die Planung grosser Mengen von User Stories. Bei 50, 100 oder mehr User Stories mitteln sich die verschiedenen Abweichungen, so dass die so genannte Velocity entsteht: der durchschnittliche Durchsatz von Story Points pro Sprint. Basierend darauf kann man Prognosen über die zukünftige Arbeitsgeschwindigkeit eines Teams machen (wichtig an dieser Stelle: grosse Mengen von User Stories sind nicht das Selbe wie einzelne grosse Arbeitspakete).

Aber ist denn damit zumindest langfristig eine Planungssicherheit möglich? Nun - immer noch nicht. Die Durchschnittsleistung eines Teams wird mit grosser Wahrscheinlichkeit sinken wenn einzelne Mitglieder ausgetauscht werden, wenn neue Technologien eingesetzt werden, wenn neue fachliche Herausforderungen anstehen oder wenn mit neuen Schnittstellen oder Kunden umgegangen werden muss. Umgekehrt kann Stabilität in Teamzusammenstellung, Technologie, Aufgabenstellung oder Umgebung auch die Velocity stabilisieren oder sogar steigern.

Hier könnte man letztendlich den Silberstreifen am Horizont vermuten. Es ist also nur nötig Teamzusammenstellung, Technologie, Aufgabenstellung und Umgebung stabil zu halten und schon kann verlässlich und sicher prognostiziert geplant werden? Ja, tatsächlich, das wäre theoretisch möglich. In der Realität dürften derartige Rahmenbedingungen aber selten bis nie auftreten. Und damit kommen wir zum vielleicht grössten der Missverständnisse rund um Story Points.

Story Points haben gar nicht den Zweck berechenbare Arbeit zu planen. Sie sollen helfen Annahmen zur Umsetzungsdauer unberechenbarer (und damit unplanbarer) Arbeit zu machen (mehr dazu hier). Das findet zwar in Zeiteinheiten statt (mit den oben genannten Einschränkungen), da einige der Annahmen sich aber als falsch herausstellen werden wird das Gesamtergebnis immer anders sein als die initiale Annahme. Das Fazit kann daher nur lauten: Story Points entsprechen zwar Zeit - passen aber trotzdem auf keinen Zeitstrahl.


Nachtrag 23.05.:
Ron Jeffries hat seine Gedanken in einem Artikel zusammengefasst. Verkürzt gesagt - statt Story Points empfiehlt er #NoEstimates.

Donnerstag, 16. Mai 2019

Modularisierung

FS

Manchmal sind die Unterschiede zwischen Software und Hardware kleiner als man denken sollte. Bestimmte Situationen können in beiden Fällen so ähnlich sein, dass sie ähnliche Herausforderungen und ähnliche Lösungsansätze mit sich bringen. Ein Glücksfall für alle die diese erklären müssen, schliesslich bieten sich dadurch verständliche Analogien mit denen man arbeiten kann.

Ein derartig eingängiges Fallbeispiel befindet sich zur Zeit zwischen Köln und Bonn, in einem Ort mit dem schönen Namen Wahn. In Wahn befindet sich eine Brücke über die die Autobahn 59 geführt wird, und da diese Autobahn um eine weitere Spur ausgebaut werden soll wird als erster Schritt diese Brücke erneuert. So weit, so banal. Und doch ist dieser Brückenneubau etwas Besonderes.

Wie man den Internetseiten des Landesbetriebs Strassenbau entnehmen kann wurde die Wahner Brücke anders gebaut als üblich. Während es sich bei den meisten Autobahnbrücken um zwei parallele Teilbauwerke handelt (eine pro Richtung) besteht diese hier aus einem einzigen Stück. Um jetzt jeweils die eine Hälfte erneuern zu können während der Verkehr über die andere geführt wird muss die Brücke vorher in zwei Teile zersägt werden.

Natürlich ist das kein einfaches Unterfangen. Die Geräte benötigen Platz, die Statik und Stabilität des Gesamtbauwerks muss gesichert werden, die Arbeit muss von Spezialisten durchgeführt werden die nicht sofort zur Verfügung stehen, sowohl die benötigte Zeit als auch die zu zahlenden Kosten sind höher als sie es bei einer der üblichen zweigeteilten Brücken sein würden. Man kann sich vorstellen was alles dahintersteckt.

Zur Analogie: auch in der Softwareentwicklung können derartige Situationen auftreten. Es sind hier zwar keine Fahrspuren die parallel laufen, es können aber Transportwege für Daten sein, beispielsweise einer für Stammdaten und einer für Metadaten. Und auch hier ist es so, dass ein festes Verbinden dieser Wege zu Problemen führt - soll einer von ihnen erneuert werden muss man entweder beide umbauen (und ggf. sperren) oder sie vorher aufwändig in separate Module zerschneiden.

Sogar die Ursachenforchung dürfte zu ähnlichen Ergebnissen führen. Ob es Zeitnot war, zu wenig Budget, fehlende Erwägungen zukünftig nötiger Arbeiten oder schlicht Gedankenlosigkeit, all das kann sowohl im Fall von Software als auch im Fall von Hardware der Grund für die fehlende Modularisierung sein, in Wahn genau wie in der IT.

Zuletzt bietet der Brückenbau zu Wahn noch ein weiteres "Geschenk" für alle die ihn zu Vergleichszwecken nutzen wollen: neben dem Anlass und der Analogie bietet er auch die Zeit für eine Erklärung. Er sorgt nämlich ein Jahr lang jeden Tag für Stau.

Montag, 13. Mai 2019

Scrum in der Schule

FS
Manchmal muss man in die Ferne blicken um das Naheliegende zu entdecken. Auf der re:publica 2019 wurde eine Schule aus Bonn vorgestellt die Scrum im Unterricht einsetzt. Und ohne es zu wissen bin ich erst vor wenigen Tagen an ihr vorbeigelaufen. Eine kleine Welt.

Donnerstag, 9. Mai 2019

Retrospektiven-Ergebnisse

FS
Bild: Pexels / Elevate Digital - CC0 1.0
Egal ob man sie Retrospektiven nennt oder Lessons Learned-Meetings, Kaizen-Events, Schulterblick oder KVP-Sitzung, es sind derartige Veranstaltungen die den Kern aller ständigen Verbesserungsprozesse bilden und damit auch den Kern der Agilität. In ihnen können Beschlüsse und Massnahmen erarbeitet werden durch die der Inspect & Adapt-Prozess mit Leben gefüllt wird. Um in diesem Zusammenhang zielgerichtet vorgehen zu können empfiehlt sich ein näherer Blick: welche Arten von Ergebnistypen können hier entstehen?

1. Action Items

Der Retrospektiven-Klassiker. Was auch immer vom Team selber erledigt werden kann lässt sich als Massnahme beschliessen und mitnehmen. Wie das im Einzelfall aussieht kann sich von Fall zu Fall unterscheiden, es gibt aber good Practices: die Massnahmen sollten bis zur nächsten Retrospektive abschliessbar sein, es sollte eine Person für die Umsetzung (bzw. deren Koordination) verantwortlich sein und der damit verbundene Aufwand sollte in die Kapazitätsplanung einfliessen. Besonders das letzte klingt zwar selbstverständlich, wird aber häufig vergessen.

2. Anforderungen

Für die einen naheliegend, für die anderen nicht. Gehören Anforderungen nicht eher zur Planung als zum Lessons Learned? Im Prinzip ja, allerdings fallen sie auch im Planning oder Replenishment nicht vom Himmel. Irgendwo befindet sich ein vorgelagerter Schritt in dem sie initial erdacht werden, und der kann auch eine Retrospektive sein. Wenn hier z.B. beschlossen wird, dass ein Refactoring oder Monitoring Sinn macht, kann das in den Planungs- und Priorisierungsprozess einfliessen und auf diese Weise in die Umsetzung gegeben werden.

3. Apelle

Ein eher unschöner Ergebnistyp. Wenn sich ein Missstand ausserhalb der Einflusssphäre eines Teams befindet bleibt manchmal keine andere Möglichkeit übrig als einen Apell an denjenigen zu richten der zur Behebung in der Lage ist. An dieser Stelle liesse sich zwar kontrovers diskutieren ob ein Team das nicht alle Probleme selbst beheben kann an seiner Crossfunktionalität arbeiten müsste, im Moment des unmittelbaren betroffen Seins sind diese Überlegungen aber nicht hilfreich. Ein parallel zum Apell verfasstes Action Item zum Skillaufbau ist dagegen eine gute Idee.

4. Buffer / Slacktime

Frei nach Max Weber: auch das Unterlassen von etwas ist eine Massnahme. Dementsprechend kann es eine gute Idee sein einen Teil der eigenen Zeit bewusst nicht zu verplanen. Ob dieser dann als Reserve für ungeplante Arbeiten verwendet wird, für Überstundenabbau oder für Weiterbildung kann kurzfristig entschieden werden. Vor allem in hoch volatilen Umfeldern kann es sehr sinnvoll sein so vorzugehen, da es das Risiko versehentlicher Überplanung verringert und das Reaktionsvermögen erhöht.

Sicherlich existieren neben diesen vier noch weitere Retrospektiven-Ergebnistypen, die überwiegende Mehrzahl dürfte aber einem von ihnen zuzuordnen sein. Alleine sich über sie bewusst zu werden kann helfen. Sollte sich z.B. herausstellen, dass aus Retrospektiven fast ausschliesslich Apelle entstehen ist das in fast allen Fällen ein Indikator dafür, dass hier ein Problem existiert das angegangen werden sollte.

Montag, 6. Mai 2019

Code Ownership (IV)

FS
Bild: FFCU / Markus Spiske - CC0 1.0
Wie viele andere Begriffe hat auch der der Code Ownership verschiedene Bedeutungsaspekte, je nachdem aus welchem Blickwinkel man ihn betrachtet. Auf der anderen Seite verbirgt sich dahinter eine Art von Besitzanspruch im Sinne von "dieser Code gehört mir" (warum das ein Problem ist kann man hier, hier und hier nachlesen). Es lässt sich aber auch eine zweite Deutung formulieren: sich den Code zu eigen machen. Auch die ist von grosser Wichtigkeit.

Unter dem "sich zu eigen machen" können sich wiederum verschiedene Bedeutungen verbergen, die aber alle einen verwandten Inhalt haben - es geht darum das Objekt (in diesem Fall den Code) zu studieren, zu verstehen, zu erlernen oder zu verinnerlichen, bis zu dem Punkt an dem bei neuen Problemen und Herausforderungen sofort eine Idee entsteht wo und wie diese zu lösen sein könnten. Sie muss noch nicht perfekt sein, aber einen ersten Anhaltspunkt bieten.

Der Nutzen eines solchen Wissens ist offensichtlich: wann immer die genannten Problemen und Herausforderungen auftreten ist es nicht nötig sich zuerst in die Dokumentation einzulesen, Code Reviews zu machen oder Reverse Engineering zu betreiben, stattdessen kann schneller mit der eigentlichen Arbeit begonnen werden. Und bedingt durch die gegebene Vertrautheit dürfte auch deren Ergebnis besser sein.

Um ein Code Ownership in diesem Sinn zu erreichen ist es nicht ausreichend ihn geschrieben oder einmalig verstanden zu haben, schon gar nicht wenn das nur durch eine Person geschieht. Idealerweise ist es eine ganze Gruppe die sich regelmässig mit ihm beschäftigt, um so das Wissen nicht nur zu verteilen sondern durch ständige Kommunikation am Leben zu halten. Am Ende sollte dabei ein kollektives Gedächtnis des gemeinsam verinnerlichten Codes stehen.

An dieser Stelle beginnen in vielen Organisationen die Herausforderungen. Nicht etwa in erster Linie wegen der Herstellung von Collective Code Ownership (obwohl auch das schon ein Problem sein kann) sondern vielmehr weil eine regelmässige Beschäftigung eines Teams mit einem bestimmten Anwendungsteil oft nicht vorgesehen ist. Modifizierungen finden vor allem im Rahmen von Projekten statt zwischen denen Monate oder sogar Jahre liegen können.

Von diesem Muster wegzukommen und sich in Richtung einer "Continuous Code Ownership" zu bewegen kann grössere und aufwändige Umstellungen erfordern, es ist aber eine der Voraussetzungen um im Zweifel schnell lieferfähig zu sein.

Freitag, 3. Mai 2019

Ein Bild sagt mehr als 1000 Worte (XXIV)

FS

Dienstag, 30. April 2019

Kommentierte Links (XXXXVIII)

FS
  • Christiaan Verwijs: Here’s what's wrong with maturity models

  • Die Frage ist erstmal naheliegend: Wie gut bin ich eigentlich in dem was ich mache? Auf diesen Kontext hier übertragen: Wie gut beherrsche ich Agile, Scrum, Lean, Kanban, etc.? Die scheinbar naheliegendste Lösung der Überprüfung und Auszeichnung durch Zertifizierungen läuft sich gerade tot, so dass eine andere gesucht wird. Maturity Modelle scheinen auf den ersten Blick eine naheliegende Alternative, allerdings eine die mit Vorsicht zu betrachten ist. Christiaan Verwijs zeigt die grundlegenden Probleme dieses Konzepts auf - zu generalistisch, zu wenig auf den jeweiligen Fall eingehend, zu linear. Mit anderen Worten: nicht agil.

  • Joshua Kerievsky: Preconditions for Agility

    Mit der Bewegung von agilen Vorgehensweisen in Richtung Mainstream erhöht sich nicht nur die Zahl der Erfolgsgeschichten sondern auch die der Fehlschläge. Ein häufiger Grund dafür ist der Versuch "agile" Vorhaben in einem Kontext durchzuführen in dem sie nur eingeschränkt oder gar nicht funktionieren können. Joshua Kerievsky führt einige Vorbedingungen auf die gegeben sein müssen damit das Ganze Erfolgsaussichten hat: Crossfunktionalität, gemeinsames Verständnis der Ziele, Teamwork, Bereitschaft zu Work in Progress-Limits und Kenntnis der üblichen Praktiken bei allen Beteiligten. Dass das für Agilität elementar ist dürfte offensichtlich sein, umgekehrt stellt sich aber die Frage wie ohne zumindest einige dieser Vorbedingungen überhaupt produktiv gearbeitet werden kann.

  • Jeff Sutherland: Why Less Communication is Better!

    Ein weiterer Beitrag zu den Ursprüngen von Scrum und Agilität im Militär. Nach den römischen, mongolischen und preussischen Armeen diesesmal mit einem Verweis auf die modernen amerikanischen und vor allem deutschen Streitkräfte. Vom Deutschland des 21. Jahrhunderts aus betrachtet nicht ganz unproblematisch. Einen der beiden Scrum-Gründer von Wehrmachts-Begriffen wie "Auftragstaktik" und "Führen mit Auftrag" schwärmen zu sehen ist (gelinde gesagt) befremdlich und führt spätestens dann zu Unwohlsein wenn der Frankreich-Feldzug von 1940 als positives Beispiel herangezogen wird. Selbst wenn man versuchen könnte das militärische Vorgehen von der dahinterliegenden Ideologie zu trennen ist es unwahrscheinlich, dass dieses Thema hier populär wird.

  • Roman Pichler: 10 Scaling Tips for Product People

    Im Grunde auch benutzbar für jede andere Form von Skalierung im agilen Umfeld (und darüber hinaus). Pichlers 10 Skalierungstips sind:
    1. Beziehe die richtigen Leute ein
    2. Skaliere nicht zu früh
    3. Starte mit einem MVP (um noch nicht skalieren zu müssen)
    4. Mache die Entwicklungsteams verantwortlich und selbstständig
    5. Teile Teams und fülle sie auf um zu wachsen
    6. Mache Teams produktorientiert statt komponentenorientiert
    7. Starte mit allen Beteiligten an einem Ort und expandiere schrittweise (und nur wenn nötig)
    8. Erwäge die Abspaltung neuer Teilprodukte oder Varianten
    9. Nutze die Vorteile gemeinsamer Plattformen (z.B. von Frontend-Komponenten oder Security)
    10. Skaliere nie zu einem späten Zeitpunkt
    Interessant an dieser Liste: während das meiste die vorbehaltlose Zustimmung der meisten agilen Practitioner finden dürfte sind mit den Tips 5 und 9 zwei durchaus kontrovers zu betrachtende dabei. Nicht dass sie nicht funktionieren könnten, sie bergen aber Risiken in sich derer man sich bewusst sein sollte.

  • Shaaron A. Alvares: Tuckman Was Wrong! Doc Norton on Reteaming Models

    Zum Abschluss noch ein Link der zusammen mit dem ersten eine thematische Klammer bildet. Auch das legendäre Tuckman-Modell der Teambildungsphasen (Forming, Storming, Norming, Performing, Adjourning) krankt daran, dass es zu generalistisch, zu wenig auf den jeweiligen Fall eingehend und zu linear ist. Interessant ist insbesondere der Link zu einer Studie mit über 300 Teams, derzufolge nur zwei Prozent von ihnen (!) sequentiell durch die fünf Phasen gingen. Ob die beschriebenen Alternativen der "fluiden Teams" oder des "dynamic Reteamings" besser sind könnte man aber auch diskutieren. Wie so oft: es kommt darauf an.

Donnerstag, 25. April 2019

The New Managerial Contract

FS
Nach diesem Video ist man glatt versucht sich bei Hamza Khan um einen Job zu bewerben, so überzeugend ist er in seinem Vortrag. Dazu die Acherbahnfahrt durch die Management-Geschichte, von der Industrialisierung über Peter Drucker bis Jay-Z und einige minimalistische Slides mit prägnanten Aussagen. So sollten Talks sein.


Montag, 22. April 2019

Willkürliche Deadlines

FS
Bild: Wikimedia Commons / Waterced - CC BY-SA - 4.0
Fast jeder der länger in Projekten oder Programmen jeglicher Grösse gearbeitet hat wird sie kennen: willkürliche, unrealistische Deadlines. Nicht zu verwechseln mit den gerechtfertigten Deadlines (z.B. wegen sich ändernder Gesetze), mit denen man irgendwie umgehen muss, handelt es sich bei ihnen um scheinbar ohne Notwendigkeit getroffene Entscheidungen, bei denen allen Beteiligten von Beginn an klar ist, dass man sie mit grosser Wahrscheinlichkeit deutlich verfehlen wird. Warum es trotzdem immer wieder zu ihnen kommt erkennt man an einem aktuellen Beispiel.

Nur wenige Tage nach dem Brand der weltberühmten Kirche Notre Dame de Paris wurde bereits verkündet wann der Wiederaufbau abgeschlossen sein soll: in fünf Jahren, also 2024. Dass diese Zahl realistisch ist kann zu Recht bezweifelt werden. Bereits vor dem Brand war der Bau schwer beschädigt, die zusätzlichen Beschädigungen durch den Brand sind in ihrer Tragweite noch nicht absehbar und um das Ganze noch komplexer zu machen soll in den Wiederaufbau das Ergebnis eines noch durchzuführenden Architekturwettbewerbes einfliessen. Auf dieser Grundlage in so kurzer Zeit fertig zu werden ist illusorisch.

Dass diese Zahl trotzdem im Raum steht hat Gründe. Der naheliegendste: Wunschdenken. Die pariser Bürgermeisterin Anne Hidalgo äusserte ganz offen einen Grund für den engen Zeitplan - zu den in Paris stattfindenden olympischen Spielen 2024 sollten die Schäden beseitigt sein. Ein nachvollziehbares Anliegen, schliesslich werden dann zigtausende Athleten, Touristen und Journalisten nach Frankreich kommen. Dass dieses Wunschdenken aber nicht von Beginn an als das erkannt wird was es ist liegt unter anderem an der Entkoppelung von Auftrag und Umsetzung. Je weniger man über ein Thema weiss, desto stärker kann Realismus von Hoffnung überlagert werden.

Ein zweiter Grund ist der, dass eine derart gewagte Aussage den der sie trifft als tatkräftigen Macher erscheinen lässt. Gerade im Fall des Urhebers dieses "Fünfjahresplans", des französischen Präsidenten Macron, der sich gerade erst von verheerenden Umfragewerten erholt, eine grosse Verlockung - nicht zuletzt weil mit der Europawahl eine wichtige Abstimmung nur wenige Wochen bevorsteht. Mit dem noch frischen Eindruck eines energischen Krisenbewältigers könnte er hier punkten, unabhängig von den langfristigen Erfolgsaussichten. Und sollte er damit erfolgreich sein können sich seine Wähler später an die eigene Nase fassen.

Ein dritter Grund ist, dass das angekündigte Zieldatum in einer Zeit liegt in der Macron keine negativen Folgen für sich selbst mehr befürchten muss. Laut französischer Verfassung kann er nur einmal wiedergewählt werden, und zwar 2022, also Jahre vor dem von ihm selbst gesetzten Zieldatum. Selbst wenn die Wähler es ihm übelnehmen sollten wenn der Wiederaufbau 2024 nicht abgeschlossen ist - die Folgen darf dann ein anderer ausbaden (und selbst der kann sich dann darauf berufen, dass die Ankündigung nicht seine war. Siehe hier). Parallelen zu zeitlich begrenzten Management-Amtszeiten sind offensichtlich.

Faktoren wie diese lassen sich in vielen komplexen Vorhaben finden, ob in Staat oder Wirtschaft, in Bau- oder IT-Projekten. Betrachtet man sie lassen sie die Setzung scheinbar willkürlicher Deadlines in neuem Licht erscheinen. In den meisten Fällen sind sie bedingt durch die Funktionsweise des umgebenden Systems und ergeben im Kontext von dessen Rahmenbedingungen absolut Sinn. Umgekehrt regen diese Erkenntnisse zur Hoffnung an. Wenn ein Systemdesign derartige Phänomene begünstigt, dann kann ein anderes sie unwahrscheinlicher machen. Man kann also daran arbeiten.

Donnerstag, 18. April 2019

Warum Scrum-Zertifikate früher Sinn gemacht haben (und heute nicht mehr)

FS
Bild: Pxhere - CC0 1.0
Zertifizierungen werden im Rahmen des agilen Arbeitens (und hier besonders im Zusammenhang mit Scrum) kontrovers diskutiert. Während viele Recruiter und Personaler noch immer ein Gütesiegel in ihnen sehen herrscht unter Practitionern eher der gegenteilige Eindruck vor. Ein Zertifikat gilt hier lediglich als Beweis dafür, dass man etwas Geld übrig hatte und eine begrenzte Menge Wissen auswendig lernen konnte (und selbst das mit begrenztem Praxisbezug). Was in dieser Debatte untergeht: Scrum-Zertifikate waren mal anders gemeint und haben einen ganz anderen Sinn ergeben als heute.

Ein Blick zurück auf die Anfänge: 2002 wurde mit der Scrum Alliance die erste Zertifizierungs-Organisation gegründet, zuerst nur mit Scrum Master-Zertifizierungen, erst später mit immer weiteren. Zwei bedeutende Dinge waren in dieser Zeit anders als heute - zum einen war Scrum noch relativ unbekannt und wenig verbreitet, zum anderen befand sich das Internet noch in seiner Frühphase, in der viele der heute populären Dienste noch nicht oder nur in einer frühen Form existierten. Beides führte dazu, dass die frühen Anwender des neuen Frameworks noch stark voneinander isoliert waren.

Während heute jeder Interessierte eine immer grösser werdende Auswahl an Meetups und Unkonferenzen in seiner näheren Umgebung finden kann befand sich die Scrum-Community damals noch im Zustand einer Diaspora. Vereinzelt gab es schon erste User Groups (vor allem an der amerikanischen Ost- und Westküste), im grössten Teil der Welt waren die ersten Vorreiter aber noch auf sich gestellt. Der heute fast überall vor Ort mögliche Austausch mit Gleichgesinnten war nur in Verbindung mit Reisen und Konferenzteilnahmen möglich, was nicht für jeden organisierbar und finanzierbar war.

Auch Informationen aus dem Internet gab es spärlicher als heute. Selbst die heutigen sprichwörtlichen ersten Schritte waren noch nicht möglich. Die Wikipedia existierte erst ein Jahr und war noch hochgradig lückenhaft, bis zum ersten Artikel über Scrum (siehe hier) sollten noch Jahre vergehen. Hier war also keine Hilfe zu finden. Und auch das Betrachten eines Einführungsvideos auf Youtube war keine Option, diese Seite ging erst im 2005 online, also ebenfalls Jahre in der Zukunft. Einzelne Websites zu dem Thema gab es zwar, aufgrund der im Vergleich zu heute schlechteren Suchmaschinen waren sie aber nur mit Mühe zu finden.

Die Zertifizierungen (und vor allem die Zertifizierungskurse) haben daher in den ersten Jahren eine wichtige Lücke geschlossen. Durch sie war es erstmals möglich die eigene Scrum-Umsetzung mit der offiziellen Version abzugleichen, Good Practices kennenzulernen und sich mit anderen Anwendern auszutauschen. Dass es dazu noch ein buntes Stück Papier gab war eine schöne Zugabe, von grösserer Bedeutung waren aber die beiden Tage davor, die Einblicke bieten konnten die sonst nur schwer zu haben gewesen wären. So war es damals.

Zurück in die Gegenwart: Heute gibt es all das was es früher nicht gab. Es gibt Meetups und User Groups in der eigenen Umgebung, auf denen man sich mit Menschen jeder Erfahrungsstufe austauschen kann. Es gibt online mehr kostenlose Artikel als man im gesamten Leben lesen könnte und mehr Videos als man in Jahren sehen könnte. Es gibt Inhouse Communities in grossen Firmen, es gibt Podcasts, kollegiale Fallberatungen und vieles mehr. Und wer auch nur einen kleinen Teil seiner Zeit hier investiert kan viel, viel mehr lernen als in jeder Zertifizierung.

Darum zum Fazit: es gab mal eine Zeit in der die Scrum-Zertifikate viel Sinn gemacht haben, aber die ist weitgehend vorbei.
Powered by Blogger.