Mittwoch, 31. Juli 2019

Kommentierte Links (LI)

FS
  • DACH30: Agile Rollen - Kompetenzen

  • Wenn man auf die Verbreitung, das Verständnis und die Akzeptanz agiler Vorgehensweisen blickt gibt es im deutschsprachigen Raum zunehmend Grund zum Optimismus. So auch hier: Vertreter von über 50 Unternehmen aus Deutschland, Österreich und der Schweiz haben gemeinsam versucht Mindeststandards für agile Rollen aufzustellen, mit einem Ergebnis das sich sehen lassen kann. Für die (Framework-neutral benannten) Rollen des Team Facilitators, des Value Verantwortlichen, des Umsetzungsteams und der Agilen Führungskraft gibt es jetzt grundlegende Tätigkeitsbeschreibungen und Shu Ha Ri-Stufen. Sollte sich das so durchsetzen wäre damit einen grosser Schlag gegen die Verbreitung von Cargo Cult gelungen.

  • Ron Jeffries: Fixed-Everything - Agile?

    Keine andere Website kommt so häufig in den kommentierten Links vor wie die von Ron Jeffries, und das aus gutem Grund. In gewohnter Weise eloquent und langatmig erörtert er die Frage ob es innerhalb eines "eisernen Dreiecks" aus unveränderbarem Umfang, Zeitrahmen und Budget noch Agilität geben kann. Seine Antwort: ja. Was man an dieser Stelle allerdings anmerken muss - er beschreibt hier die gelebte Realität, in der es eben doch zu der teilweisen Aufweichung der drei Dimensionen kommt. Dann wiederum - womit, wenn nicht mit der Realität, soll er sich auch auseinandersetzen? Ein echtes eisernes Dreieck ist schliesslich ähnlich häufig wie ein Albino-Panda.

  • Joe Dunn: Tribes And Tribal Conflicts In A Tech Company

    Der Mensch ist ein irrationales Wesen, trotz aller Zivilisiertheit getrieben von Instinkten, Gruppendynamiken und unbewussten Verhaltensmustern. Das zu erkennen gehört zu den Voraussetzungen guter Organisationsentwicklung, und zu diesen Erkenntnissen gehört auch die, dass grosse Organisationen in "Stämme" zerfallen die ähnliche Konflikte austragen wie vor langer Zeit ihre Vorfahren. Statt den Goten, Langobarden und Vandalen stehen sich heute Vertrieb, IT und Rechtsabteilung gegenüber und begegnen sich mit Vorurteilen und Feindseligkeit. Joe Dunn versucht sich an der Deutung interner Auseinandersetzungen als Stammeskonflikte und an der Frage wie sie aufzulösen sind. Und das Ganze hat nichts mit Spotify zu tun.

  • J. Meadows: Waste Not, Want Not - A Simplified Value Stream Map for Uncovering Waste

    Ein Blick auf die Lean Management-Seite der Softwareentwicklung. Ausgehend von den Mudas des Toyota Production System stellt J. Meadows zwei fiktive Unternehmen einander gegenüber: Wasteful Inc. und Efficient Inc. Ein schönes Beispiel für die Möglichkeiten des Flussoptimierung, aber auch eines das mit Vorsicht zu betrachten ist. Bei zu unbedachter Weiterverwendung droht die grosse Gefahr des Lean Management: dass auch ein vom Markt gar nicht nachgefragtes Produkt immer schneller und effizienter produziert wird, mit genau dem Ergebnis das eigentlich vermieden werden soll - Waste.

  • Dagmar Bott: Agiles Bar Camp – oder einfach Agile Session Time

    Bar Camps und Open Spaces gelten als eines der besten Werkzeuge für die selbstorganisierte Durchführung von (Un)Konferenzen, Workshops und Wissenstransfer-Veranstaltungen. Wie das in der Praxis aussehen kann erklärt Dagmar Bott anhand der in ihrem Unternehmen stattfindenden Agile Session Time. Ein Ansatz den man jeder anderen Firma sehr zur Nachahmung empfehlen möchte. Um die Klammer zum ersten kommentierten Link zu schlagen: auch die zunehmende Etablierung derartiger Formate trägt dazu bei, dass man die agile Transition der deutschen Unternehmenslandschaft mit Optimismus beobachten kann.

Montag, 29. Juli 2019

Raus aus dem Hamsterrad

FS
Bild: Wikimedia Commons / Mylius - CC BY-SA 3.0
Wenn Scrum irgendwo neu eingeführt wird kann man davon ausgehen, dass es eine der ersten aufkommenden Diskussionen sein wird: müssen denn diese Rollen Product Owner und Scrum Master wirklich sein? Können diese Aufgaben nicht von jemand anderem nebenher gemacht werden? Die Antwort: wenn das Ergebnis wirklich Scrum sein soll, dann nicht. Allerdings nicht als Selbstzweck sondern weil es Sinn macht.

Welcher das ist zeigt sich vor allem dort wo das "nebenher machen" stattfindet, etwa wenn die PO-Aufgaben von einem Business Analysten oder Fachabteilungs-Mitarbeiter übernommen werden und die Scrum Master-Aufgaben von einem Teammitglied. Wie gesagt, nebenher, also zusätzlich zu dem was ohnehin schon zu dem bisherigen Job gehört. Das Ergebnis wird fast immer das gleiche sein - die neuen Aufgaben werden stark vernachlässigt werden. Und das mit gutem Grund.

Der entscheidende Punkt ist hier, dass die Arbeit der Product Owner und Scrum Master im Gegensatz zu der der meisten anderen Mitarbeiter zu einem nicht Grossteil nicht anlassgetrieben ist. Sowohl die Konzeption und Validierung neuer Produktumfänge als auch die Evolution eines Teams in Richtung Crossfunktionalität und Selbstorganisation brauchen in der Regel Monate um umgesetzt zu werden, Sprints oder operative Tätigkeiten erfordern dagegen die Konzentration auf die Gegenwart.

Die Folgen sind immer die gleichen. "Um die langfristigen Themen kümmern wir uns wenn es mal im täglichen Betrieb nicht so viel zu tun gibt" heisst es dann. Dieser Zeitpunkt kommt aber praktisch nie, denn zu tun gibt es immer. Die Verschiebung der PO- und Scrum Master-Themen führt sogar zu mehr Arbeit im Alltag, da die stockende Weiterentwicklung des Teams und die unklare Produktstrategie den Beteiligten immer wieder auf die Füsse fallen und neue kurzfristige Reaktionen erforderlich machen. Ein Teufelskreis.

Um eben das zu verhindern ist es nötig in kurzen, regelmässigen Abständen aus dem operativen Hamsterrad herauszusteigen, einige Schritte zurückzutreten, das Große Ganze auf sich wirken zu lassen und sich Sinn- und Perspektivfragen zu stellen. "Wird das neue Feature wirklich so angenommen wie wir dachten?" "Wird der aktuelle Arbeitsmodus auch in einem Vierteljahr noch so funktionieren?" Etc. Wenn die Antwort darauf unklar ist sollten auch die anderen Teammitglieder aus dem Rad herausgeholt werden um sie auf das aufmerksam zu machen was von dort aus nicht sichtbar ist.

Den Product Ownern und Scrum Mastern diese Möglichkeit zu geben ist eine der Grundvoraussetzungen dafür, dass Scrum wirklich zum Greifen kommt. Und da das im Rahmen einer Zusatzaufgabe nicht funktioniert sollte die Rolle so eingeführt und ausgestaltet werden wie sie gedacht ist.

Donnerstag, 25. Juli 2019

Big Bang-Releases

FS
Bild: Pexels / Rawpixel - CC0 1.0
Es ist die IT-Story des Monats, des Sommers und vermutlich auch des Jahres - die Einführung eines neuen Enterprise Resource Planning-Systems beim Motoröl-Hersteller Liqui Moly aus Ulm. Was eine derartige Software-Einführung bewirken kann? Zum Beispiel das: falsch angezeigte Lagerbestände, verspätete Lieferungen, zunehmende Kundenbeschwerden, Gewinneinbruch um 30 Prozent.

Ferndiagnosen sind in derartigen Situationen immer schwierig, aber die Recherchen der FAZ und der Wirtschaftswoche zeichnen ein eindeutiges Bild: nachdem Liqui Moly jahrzehntelang auf eine immer weniger zeitgemässe und immer stärker veraltende Software gesetzt hatte sollte die letzten Endes abgelöst werden. Der angedachte Ersatz war eine Standardsoftware, die im so genannten "Big Bang-Verfahren" eingeführt werden sollte. Big Bang bedeutet, dass von jetzt auf gleich "mit einem Schlag" von der alten auf die neue Software umgeschaltet wird. Und den Big Bang gab es, siehe oben.

Derartig fehlgeschlagene "Auf einen Schlag-Einführungen" sind kein Einzelfall, erst diesen Frühling gab es einen ähnlichen Fall bei Hertz, letztes Jahr bei Lidl, je weiter man sucht desto mehr werden es. Hinter diesen wiederkehrenden Geschichten verbergen sich erfahrungsgemäss ähnliche Ursachen, die sich in vielen (wahrscheinlich fast allen) Big Bang-Vorhaben wiederfinden lassen. Wegen ihnen ist ein solches Vorgehen mit grösster Vorsicht zu betrachten.

Zunächst sind die meisten älteren Grossanwendungen über die Jahre "kaputtentwickelt" worden. Um die Investitionen klein zu halten werden neue Funktionen irgendwo an bestehende angedockt, selbst wenn dadurch die internen Abläufe so verkompliziert werden, dass sie kaum noch nachvollziehbar sind. Mit der fehlenden Nachvollziehbarkeit wird dann die Dokumentation widersprüchlich, das Wissen wie alles funktioniert besteht irgendwann nur noch in den Köpfen der älteren Mitarbeiter (laut FAZ hielt bei Liqui Moly nur noch ein Entwickler das Altsystem am Laufen).

Für die Ablösungs-Vorhaben bedeutet dass, das in solchen Fällen gar nicht mehr klar ist was da abgelöst werden soll. Die Anforderungen an das Neusystem beruhen auf veralteten und unvollständigen Informationen, schlimmstenfalls auf Vermutungen. Die Folge - selbst wenn das neue System genau so funktioniert wie es konzipiert wurde wird es trotzdem nicht das können was eigentlich notwendig wäre. Eine "kaputtenwickelte" Software wird dann durch eine ersetzt die "kaputt entwickelt" wurde.

Es wird noch schlimmer. Eine weitere Fehlerquelle entsteht dort, wo es sich bei der neuen Anwendung um Standard-Software handelt. Anders als es der Name vermuten lässt ist das keineswegs ein Standard der überall funktioniert. Um mit den Schnittstellen und Prozessen des neuen Einsatzgebietes kompatibel zu sein sind in der Regel umfangreiche Anpassungen nötig. Finden diese unter Zeit- und Kostendruck statt (wo ist das nicht so?) kommt es auch hier zu den sprichwörtlichen "quick and dirty"-Lösungen.

Selbst das ist aber noch nicht alles. Alle gerade genannten Probleme lassen sich nämlich erst dann feststellen wenn es zu spät ist. Genau das ist das grosse Risiko eines Big Bang-Releases: wenn alles erst ganz zum Schluss gleichzeitig auf Produktion geschoben wird, dann ist der früheste Zeitpunkt an dem Realitätskontakt stattfindet und sich Fehlkonzeptionen und -funktionen feststellen lassen genau dann - ganz zum Schluss, wenn alles Live geschaltet ist und alle Mitarbeiter und Kunden bereits betroffen sind.

Wie es besser gehen könnte? Durch einen mehrstufigen Prozess1. Zuerst sollte durch Reverse Engineering herausgefunden werden was die alte Anwendung wirklich tut. Als nächstes sollte versucht werden einen ihrer Teile so zu modifizieren, dass er nur noch durch fest definierte Schnittstellen mit dem restlichen System kommuniziert. Dieser Teil kann dann separat ersetzt werden, mit deutlich überschaubareren Konsequenzen wenn hier etwas schiefläuft. Danach kann das Selbe mit dem nächsten Teil passieren, dem übernächsten, etc.

Häufige Einwände an dieser Stelle sind, dass das doch eine Eigen-Entwicklung von Software wäre. Das wäre doch viel teurer als sich fertige Software zu kaufen. Es wäre interessant zu hören was die Leute von Liqui Moly heute darauf antworten würden.

1Alle Wasserfall-Witze bitte jetzt

Montag, 22. Juli 2019

Eisenbahnscheinbewegung

FS
Zum Thema Fake Agile, unsinnige Zertifizierungen und darüber wie man es besser machen kann gibt es mittlerweile viele Vorträge die man sich ansehen kann. Der hier ist aber definitiv einer der unterhaltsamsten.

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 Bundestages 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 (L)

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.
Powered by Blogger.