Agile Reden

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.

Deine Muda: Defects

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.

Agile Bauprojekte

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

Humanity above Bureaucracy

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.

Die Produktbeschreibung als Pressemitteilung

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.

Kommentierte Links (XXXXX)

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

Change Fatigue (II)

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.

Wenn die richtigen Teams zur richtigen Zeit an der richtigen Sache arbeiten