Mittwoch, 31. Juli 2019
Kommentierte Links (LI)
 |
| Bild: Unsplash / Compare Fibre - Lizenz |
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
 |
| Bild: Wikimedia Commons / Mylius - CC BY-SA 3.0 |
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 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 irgendetwas Dringendes 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 (und die damit verbundene Befreiung von Hamsterrad-Aufgaben) zu geben, ist eine der Grundvoraussetzungen dafür, dass Scrum wirklich zum Greifen kommt. Und da das aufgrund der Gegenläufigkeit zur anlassgetriebenen Alltagsarbeit nicht im Rahmen einer Zusatzaufgabe funktioniert, sollten diese Rollen so eingeführt werden wie sie gedacht sind: als Vollzeit-Stellen.
Donnerstag, 25. Juli 2019
Big Bang-Releases
 |
| Bild: Pexels / Rawpixel - Lizenz |
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
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 (Better Value Sooner Safer Happier) von Jon Smart ist aber definitiv einer der unterhaltsamsten.Btw: ein Vorteil der weitgehend englischen "agilen Terminologie" ist, dass es kaum Komposit-Nomen gibt. Darum ist die Eisenbahnscheinbewegung in diesem Kontext auch lustig.
Donnerstag, 18. Juli 2019
Agile Reden
 |
| Bild: Flickr / European Parliament - CC BY 2.0 |
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
 |
| Bild: Pixabay / EME - Lizenz |
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
"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.
