Montag, 22. Juli 2024

LeSS veröffentlicht eigenen Scrum Guide

Unter den agilen Frameworks ist LeSS (Large Scale Scrum) vermutlich das mit der kuriosesten Entstehungsgeschichte. Ursprünglich entwickelt um das eigentliche Scrum ohne inhaltliche Veränderungen in Skalierungs-Kontexte übertragen zu können, haben sich seine Urheber gegen 2017 entschlossen, sich vom original-Scrum abzukoppeln und ihre eigene, inhaltlich abweichende Version zu entwickeln. Diese Entwicklung ist seit Juli 2024 abgeschlossen, es gibt jetzt einen "LeSS Scrum Guide".



Die Abweichungen zum offiziellen Scrum Guide lassen sich dabei in zwei Kategorien einteilen: zum einen sind es Themen, zu denen die LeSS-Erfinder Craig Larman und Bas Vodde eine andere Meinung haben als die Scrum-Erfinder Jeff Sutherland und Ken Schwaber, zum anderen sind es redaktionelle Änderungen, die den formalen Aufbau des Scrum Guides (Reihenfolge und Gruppierung der Themen) verändern, inhaltlich aber alles beim Alten lassen.


Bei der ersten Kategorie, den inhaltlichen Abweichungen, ist vor allem das (Development-) Team zu nennen. Aus dem offiziellen Scrum wurde es 2020 entfernt und durch "the Developers" ersetzt, um zu verhindern, dass ein Teil-Team innerhalb des Scrum Teams entsteht, dem Product Owner und Scrum Master nicht angehören. LeSS geht in die andere Richtung - diese beiden Rollen sind hier ausserhalb der Teams auf einer übergreifenden Ebene (und nehmen dadurch z.B. auch nicht an den Retrospektiven teil).


Die zweite wichtige Abweichung ist das Zielbild: im offiziellen Scrum findet sich seit 2020 das übergreifende Product Goal, zu dessen Eigenschaften gehört, dass es erreicht und abgeschlossen werden kann (es kann danach ggf. durch ein neues ersetzt werden). Abweichend davon gibt es in LeSS die Product Vision, die deutlich abstrakter ist. Als Folge dessen ist ein abschliessendes Beenden der Arbeit am Product Backlog hier ausdrücklich nicht vorgesehen (und wird sogar explizit ausgeschlossen).


Die dritte Abweichung dreht sich um das Backlog Refinement. Im offiziellen Scrum ist es eine durchgehend stattfindende Tätigkeit, deren Anlass, Umfang und Teilnehmer nicht erwähnt werden. In LeSS ist es abweichend davon als optionales Meeting beschrieben, einschliesslich der Teilnehmer (Scrum-Rollen und ggf. Stakeholder), des Ablaufs und des möglichen Umfangs (maximal 10 Prozent des Sprints, eine Regel, die 2020 aus dem offiziellen Scrum Guide entfernt wurde).


Darüber hinaus gebt es verschiedene weitere, eher abstrakte Abweichungen. Beispielsweise enthält das Product Backlog im offiziellen Scrum "Work for a complex Problem", in LeSS dagegen "Ideas for incrementally creating a Product"; Scrum basiert laut offiziellem Scrum Guide auf "Empiricism and Lean Thinking", laut LeSS-Scrum Guide dagegen nur auf "Empiricism"; die Definition of Done ist offiziell ein Committment, in LeSS dagegen ein Agreement. Den meisten Lesern dürfte das kaum auffallen.


Die zweite Kategorie der Abweichungen des LeSS-Scrum Guide zum offiziellen Scrum Guide sind die redaktionellen Änderungen. Der Sprint steht nicht mehr im Abschnitt der Events (Meetings) sondern hat einen eigenen Abschnitt, die drei im Sprint Planning zu beantwortenden Fragen sind nicht mehr nummeriert, etc. Das Ziel ist vermutlich eine bessere Lesbarkeit und Verständlichkeit, erklärt werden die Gründe für diese Neuformatierung nicht näher.


Soviel zum Inhalt, als nächstes drängt sich die Frage auf: braucht denn irgendjemand diesen zweiten Scrum Guide? Aus Sicht der LeSS-Erfinder bestimmt, zumindest dann, wenn man ihr Framework anwendet, in dessen Rahmen mehrere Entwicklungsteams sich einen Product Owner und ein Product Backlog teilen. Aus einer Scrum-puristischen Sicht vermutlich eher nicht, alleine deshalb nicht, weil diese Skalierungs-Praktiken seit 2020 auch (optionale) Teile des offiziellen Scrum sind.


Am Ende wird jedes Unternehmen oder jedes Team selber entscheiden müssen, welchen der beiden Scrum Guides es besser findet und welchen nicht. Erfahrungsgemäss dürfte das in den meisten Fällen aber eine relativ nachrangige Frage sein. In der Praxis werden die Umsetzungen der beiden Varianten (wenn sie denn wie vorgegeben stattfinden) sich ohnehin nur durch Methoden-Experten unterscheiden lassen und sich für die Beteiligten gleich anfühlen.


Was auf jeden Fall kritisch anzumerken ist, ist, dass LeSS durch diesen neuen Guide in sich selbst inkonsistent wird. Auf der offiziellen Website LeSS.works findet sich zum Beispiel in der offiziellen Beschreibung des LeSS-Frameworks noch ein aus zwei Teilen bestehendes Planning, im LeSS-Scrum Guide sind es drei. In der Framework-Beschreibung wird von teambasierten Refinements abgeraten, im LeSS-Scrum Guide sind sie enthalten. Da muss noch aufgeräumt werden.


Zuletzt eine Beobachtung: im Abschnitt Purpose of the Scrum Guide haben die LeSS-Erfinder Larman und Vodde eine Spitze gegen Jeff Sutherland untergebracht - der offizielle Scrum Guide wird hier bezeichnet als "the Scrum Guide by Ken Schwaber". Das ist zwar nicht komplett falsch, dass Sutherland an der letzten Version nicht beteiligt war, ist offiziell bestätigt worden. Seinen Beitrag komplett unter den Tisch fallen zu lassen ist aber zumindest ungewöhnlich, wer weiss was da im Hintergrund passiert ist.

Donnerstag, 18. Juli 2024

Woran man erkennt, ob einem Unternehmen Respekt und Augenhöhe wichtig sind

Es ist heute der Standard in jeder grösseren Organisation: alle geben sich (explizit oder implizit) Leitwerte wie Respekt, Augenhöhe, Fairness und Ähnliches. Das ist auch erstmal gut so, die Frage, die sich viele Betrachter dabei stellen, ist aber, ob das wirklich ernst gemeint ist oder nur der Aussendarstellung dient. Glücklicherweise gibt es eine einfache Möglichkeit, das herauszufinden - man muss sich nur anschauem, wie dort externe Mitarbeiter behandelt werden.


Zum gemeinsamen Verständnis: unter externen Mitarbeitern versteht man Menschen, die nicht in der Organisation für die sie arbeiten direkt angestellt sind. Stattdessen handelt es sich um Mitarbeiter externer Personaldienstleister und Zeitarbeits-Firmen, kooperierender Zulieferer oder eingebetteter Fremdfirmen für Kantine, Hausmeisterdienste, etc. In einigen Berufen, wie z.B. Pflegedienstleistungen oder Softwareentwicklung, kommen dazu noch zahlreiche solo-selbstständige Freelancer.


Dass diese externen Kollegen nicht komplett gleich behandelt werden können wie die internen ist auch klar, bei Leistungen wie z.B. einem Zuschuss zu einer Betriebsrente wäre das alleine aus juristischen Gründen nicht möglich. Und seit einigen Jahren muss eine erkennbar andere Behandlung erkennbar sein, wenn man verhindern will, dass externe Freelancer plötzlich als nur scheinselbstständig gelten. Was in vielen Firmen passiert ist mit diesen Gründen aber nicht zu rechtfertigen.


Um nur einige Beispiele zu nennen, die sich jetzt im Augenblick in Deutschland zutragen: eine Behörde verlangt von Bewerbern um externe Positionen die schriftliche Versicherung, sich nirgendwo sonst zu bewerben, schaut sich selbst aber in aller Ruhe verschiedene Kandidaten an. Ein Dax-Konzern verlangt von potentiellen externen Mitarbeitern, auf eigene Kosten quer durch Deutschland zu Vorstellungs-Interviews zu reisen, ein anderer teilt danach Absagen nur auf Nachfrage mit.


Ein IT-Systemhaus einer Behörde verlangt zwei Wochen unbezahlte Einarbeitung, da die Externen in dieser Zeit ja "noch keinen Mehrwert liefern", eine Bankengruppe verlangt das Gleiche, bevor ein auslaufender Vertrag verlängert wird. Bei einem Automobil-Hersteller werden die Büros, in denen die Externen sitzen, deutlich seltener renoviert und repariert als die der Internen, und fast überall sind die Kantinenpreise für externe Kollegen deutlich erhöht, zum Teil um das Doppelte.


Und das ist nur das was offiziell verlangt und kommuniziert wird, inoffiziell kommt noch mehr dazu. Es ist eine weitverbreitete Praxis, von externen Kollegen unbezahlte Überstunden zu verlangen, gerade in schlecht bezahlten Berufen, und wenn man weiss, dass diejenigen auf das Einkommen angewiesen sind. In Medien-Redaktionen wird von den so genannten "Festen Freien" oft verlangt, dass sie durchgehend in Warteräumen verfügbar sein müssen, wenn sie die Chance haben wollen, beauftragt zu werden.


Anstrengende, monotone oder Stress erzeugende Arbeiten werden in vielen Agenturen bevorzugt an externe Kollegen weitergereicht, bei Ergebnis-Präsentationen dürfen sie oft nicht mit auf die Bühne, sie werden bevorzugt in die Teams cholerischer und inkompetenter Vorgesetzter geschickt, und wenn die Budgets für ihre Einsätze gekürzt werden, erfahren sie es als letzte, damit sie durch die Hoffnung auf Verlängerung bis zum Schluss überdurchschnittlichen Einsatz zeigen.


Um auch das zu sagen: in vielen Firmen finden derartige Missstände nicht statt, und es gibt sogar einige, die die externen Mitarbeiter besser behandeln als die internen. Trotzdem sind die gerade genannten Phänomene weitverbreitet, wie zuvor gesagt handelt es sich bei jedem der genannten Beispiele für die schlechte Behandlung von Externen um solche, die gerade jetzt in verschiedenen Unternehmen und Behörden in Deutschland stattfinden und weiter stattfinden werden.


Dass all das mit Respekt, Augenhöhe und Fairness nichts zu tun hat, ist offensichtlich, stattdessen werden externe Kollegen in solchen Firmen als Menschen zweiter Klasse behandelt, und das in den meisten Fällen mit einer erstaunlichen Offenheit und mit einem bemerkenswert geringen Schuld- oder Unrechtsbewusstsein. "Das sind ja nur die Externen", heisst es häufig, "die sind ja eh bald wieder weg", oder der Klassiker: "Wenn es denen nicht gefällt, können sie ja gehen."


Was dabei oft nicht erkannt wird ist, dass diese Verhaltensweisen aber auch in der eigenen Belegschaft spürbare Folgen haben. Dass ein derartiger Umgang mit anderen Menschen toleriert oder sogar normalisiert wird trägt früher oder später zu einer toxischen Arbeitskultur bei, die dazu führt, dass die eigenen (fest angestellten) Mitarbeiter entweder verrohen und abstumpfen oder angewidert in die innere oder äussere Kündigung gehen.


Und dass die schönen an der Wand hängenden und in Management-Reden zitierten Leitwerte ernst gemeint sein könnten glaubt in solchen Firmen niemand, womit die Unternehmenskultur nochmals beschädigt wird. Die Betonung dieser Werte wird dort als paradoxe Kommunikation wahrgenommen und führt nicht nur dazu, dass ihnen nicht geglaubt wird, sondern auch dazu, dass jedem der sie einfordert Unaufrichtigkeit und Doppel-Standards unterstellt werden.


Es gibt also viele Gründe dafür, etwas zu tun, das eigentlich eine Selbstverständlichkeit sein sollte: externe Mitarbeiter gut zu behandeln. Das ist dann auch ein erkennbarer Beleg dafür, dass Respekt, Augenhöhe und Fairness ernst gemeint sind, und nicht nur deshalb an der Wand hängen, weil das gerade in Mode ist.

Montag, 15. Juli 2024

Agile Cookies

Bereits seit einiger Zeit taucht dieses Video von Dorota Mleczko immer wieder in meinen Social Media-Feeds auf. Mittlerweile ist es auch in Youtube verfügbar, so dass man auch  sich dort (und hier) anschauen kann, wie eine Unterhaltung zwischen Scrum, Kanban, Extreme Programming und SAFe aussehen würde.



Ich halte die vier Frameworks trotz aller absichtlichen Überzeichnung für gut getroffen. Wer sich beruflich mit ihnen (und ihrer Wahrnehmung durch ihre Anwender) beschäftigt, wird einiges davon im Video wiedererkennen. Ich sage nur: Fishbone.Diagramm.

Donnerstag, 11. Juli 2024

Agile Success Stories: Das Compliance-MVP

Man soll ja Erfolge nicht nur feiern, sondern auch in Erinnerung behalten, denn wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann sonst leicht in Frustration abrutschen. Um es nicht dazu kommen zu lassen, möchte ich von einer weiteren "agilen Erfolgsgeschichte" erzählen, die sich einmal im IT-Systemhaus einer grossen Bankengruppe zugetragen hat, bei der Entwicklung eines neuen Onlinebanking-Systems.


Agiles Arbeiten steckte dort noch in den Anfängen, und wie in vielen anderen Unternehmen auch wurde noch davon ausgegangen, dass es sich dabei nur um eine neue Arbeitsweise für die Software-Entwicklung handeln würde. Andere Organisationseinheiten reagierten nur mit einer Mischung aus Amüsiertheit und Entrüstung, als angeregt wurde, dass auch sie ihren Arbeitsmodus ändern sollten. Ihre Ideen waren klar: sie wollten im Voraus definieren, was sie wollten, und dann warten bis es fertig war.


Was zu ihrer Überraschung anders war, war aber, dass ihnen schon früh mitgeteilt werden konnte, wie (un)realistisch ihre Vorstellungen waren. Durch feature- statt komponentenorientierte Entwicklung, frühe Integration und automatisiertes Testen war der reale Arbeitsfortschritt klar erkennbar, und durch eine grobe Schätzung der noch offenen Anforderungen auch die noch nötige Zeit, beziehungsweise die vermutlichen Liefertermine der fehlenden Features. Und nätürlich - die waren später als gewünscht.


Die ersten Reaktionen darauf waren abwiegeln und abstreiten. Es wäre doch noch viel zu früh für solche Aussagen, die Roadmap wäre schliesslich von Experten gemacht worden, die Entwicklungs-Teams müssten nur bereit sein, "etwas Gas zu geben", dann würde der Zeitplan wieder passen. Und so weiter. Allein - alle drei Wochen bestanden die Entwickler in den Sprint Reviews auf ihren schlechten Botschaften. Im ersten Quartal, im zweiten, im dritten, und am Anfang des vierten.


Wenige Monate blieben damit noch bis zum geplanten Go Live in der ersten Tochtergesellschaft, und plötzlich wollten auch die anderen Organisationseinheiten agil werden. Besonders ein Begriff hatte es ihnen auf einmal angetan: das Minimum Viable Product (MVP), in ihrem Verständnis ein nur auf das absolut Notwendige reduzierter Funktionsumfang, mit dem der anvisierte Termin noch irgendwie zu halten sein müsste. Den wollten sie haben, und den glaubten die Entwickler auch liefern zu können.


In der Folgezeit wurden die Anforderungen Seite um Seite zusammengestrichen. Opulente Redaktions-Workflows? Erstmal nicht. Der komplette Nachbau aller Features des alten Systems im Neuen? Völlig übertrieben. Die Umstellung aller internen CMS-Seiten auf die Fonts, Formen und Farben des Corporate Design? Unnötig. Etc. Am Ende blieb nur ein letztes der unrealistisch grossen Arbeitspakete übrig, das angeblich nicht verhandelbar war. Das so genannte Reporting Center.


Dieses letzte laut Compliance-Abteilung zwingend nötige Feature sollte sicherstellen, dass sich nachvollziehen liess, welcher interne Mitarbeiter wann welche Änderungen in dem Onlinebanking-System vorgenommen hatte. Zu diesem Zweck sollte es möglich sein, sich alle Änderungen anzeigen zu lassen, sie nach Zeitraum, Bearbeiterrolle oder betroffenem Teilsystem zu filtern und grafisch aufbereitet anzeigen zu lassen. "Wenn es das nicht gibt, macht uns die Bafin den Laden zu", hiess es.


Als zwei Wochen vor Weihnachten absehbar wurde, dass auch diese Drohung nicht zu einer wundersamen schnellen Fertigstellung führen würde, fiel auf einmal auch hier das neue magische Wort. "Gibt es nicht auch davon ein MVP, und wenn ja, welches?" Und es gab eines - eine aus dem System exportierte Tabelle aller Bearbeitungsvorgänge, mit dem Angebot der Entwickler, ggf. beim Verständnis zu helfen. Und ein inoffizielles Vorfühlen bei der Bafin ergab: für die erste Version würde das reichen.


Und damit war es geschafft. Das Go Live in der ersten Tochtergesellschaft konnte wie geplant stattfinden, und nicht nur das. Die dort mit dem MVP-System arbeitenden Mitarbeiter konnten gefragt werden, wie sie mit dem System zurechtkamen, ihnen konnte gesagt werden, welche Features sonst noch geplant waren, und was sie vermutlich kosten würden. Und völlig überraschend kam das Feedback, dass viele davon gar nicht benötigt würden und stattdessen etwas Anderes sinnvoll wäre.


Dem Vernehmen nach ist das etwas überdimensionierte Reporting Center irgendwann doch gekommen, aber trotzdem enthält diese Geschichte einigen von dem, was agiles Arbeiten so wirkungsvoll macht: frühe Auslieferung, hohe Transparenz, ständiges Feedback, ein MVP, aus dem man mehr über die echten Bedürfnisse echter Anwender lernen kann und eine Anpassung der Pläne an die Realität (statt des Versuchs das Gegenteil zu erzwingen). Und all das in einer stark regulierten Branche.


"So sollten wir öfter arbeiten", hatte einer der Bank-Manager mir zum Ende meines Einsatzes gesagt. Ich wünsche ihm und seinen Leuten, dass das seitdem auch passiert ist.

Montag, 8. Juli 2024

Der dreiteilige Vermerk

Wer hier schon länger mitliest weiss es - ich habe am Anfang meiner Karriere in einer Behörde gearbeitet, in der ich nicht nur viele der bekannten und beklagten Dysfunktionen erleben musste, sondern in der auch vieles einfacher, flexibler und effizienter organisiert war als in vielen Unternehmen, in denen ich später gearbeitet habe. Ein Werkzeug das ich dort kennengelernt habe benutze ich sogar bis heute (wenn auch meistens unter anderem Namen): den dreiteilen Vermerk.


Zum Hintergrund: mein Referat hatte relativ wenige gleichbleibende Regeltätigkeiten und war stattdessen an vielen Projekten, Arbeitsgruppen, Veranstaltungen und weiteren sehr unterschiedlichen Aufgaben beteiligt. Sowohl in der internen Kommunikation als auch in der Zusammenarbeit mit anderen Behörden, externen Partnern und höheren Hierarchieebenen war es daher immer wieder nötig, neue Themen und komplexe Zusammenhänge schriftlich zu kommunizieren.


Die Dokumente mit denen in der öffentlichen Verwaltung normalerweise Kommunikationen stattfanden, hiessen im Behördendeutsch "Vermerk", aber trotz ihrer zentralen Bedeutung für die Informationsverteilung gab es für sie kein standardisiertes Format. Je nachdem von welcher Person oder in welcher Organisationseinheit sie verfasst waren konnten sie lang sein oder kurz, strukturiert oder unübersichtlich, prägnant oder ausschweifend.


Das in meinem Umfeld meistens genutzte Format war das bereits Erwähnte. Der Vermerk bestand dabei in der Regel aus drei Teilen, die immer in der gleichen Reihenfolge angeordnet waren und die inhaltlich aufeinander aufbauten:

  1. Worum geht es?
  2. Was ist bisher passiert?
  3. Was ist als nächstes zu tun?

Gegebenenfalls folgten danach noch weiterführende Informationen, ein freizugebendes Dokument, ein Entwurf eines Rede-Manuskripts oder irgendeine andere Mehrwert stiftende Anlage.


Um auf die drei Hauptbestandteile einzugehen: alleine der erste Teil war bereits wichtiger als man denken könnte. Angesichts vieler verschiedener Themen und ständiger Kontextwechsel konnte nicht davon ausgegangen werden, dass jeder, der in einen Termin eingeladen oder um eine Entscheidung gebeten wurde, sofort alle Ziele, Handlungsbedarfe und Hintergründe parat hatte. In Worum geht es? wurden diese daher möglichst komprimiert auf maximal einer Seite zusammengefasst.1


Der zweite Teil, Was ist bisher passiert?, sollte verhindern, dass Diskussionen immer wieder von vorne begannen, oder dass Sachstände oder bereits abgeschlossene Aktivitäten redundant oder aufwändig zusammengetragen werden mussten. Im Idealfall enthielt er alle bereits beschlossenen Schritte oder Massnahmen, eine Übersicht darüber, welche bereits angegangen worden waren und ggf. welche davon bereits mit welchem Ergebnis beendet worden waren. Auch das idealerweise auf maximal einer Seite.


Der dritten Teil, Was ist als nächstes zu tun?, diente schliesslich dem Zweck, die anstehende Diskussion oder Entscheidung möglichst effizient zu gestalten. Im einfachsten Fall enthielt er mehrere Entscheidungs-Optionen, von denen nur noch eine gewählt werden musste, es konnten aber auch zu priorisierende Themen sein, Budget-Freigaben oder einfach die Agenda für das kommende Meeting, so dass jeder sich auf die Themen vorbereiten konnte.


Ähnlich wie z.B. die "Press Releases" von Amazon, die ich viel später kennengelernt habe, sind die dreiteiligen Vermerke eine einfache, komprimierte und klar strukturierte Art um komplizierte oder komplexe Themen verständlich aufzubereiten und effiziente Diskussions- und Entscheidungsprozesse zu befördern. Sie auf insgesamt nur ein bis zwei Seiten zu beschränken ist nicht immer einfach, kann aber dabei helfen, sich viele Ineffizienzen und redundante Diskussionen zu ersparen.


Ich habe bereits in verschiedenen Unternehmen mit diesem Format gearbeitet und es auch anderen empfohlen, wenn auch immer mit einer Einschränkung - es sollte nicht kategorisch vorgeschrieben werden, sondern nur da benutzt werden wo es Sinn macht. Auch in der Behörde in der ich es kennen gelernt habe, haben wir bei Bedarf andere Formate genutzt, wenn diese besser gepasst haben. Uns war bewusst, dass alles andere nur zu Bürokratie geführt hätte.



1Eine DIN A 4-Seite mag nach viel klingen, war im Vergleich zu anderen Dienststellen wenig. Der Durchschnitt lag bei einer halben Seite.

Dienstag, 2. Juli 2024

Ein Bild sagt mehr als 1000 Worte (XLIII)

Und für alle, die es spontan nicht zuordnen können, hier ist die Story hinter diesen Bluescreens.

Samstag, 29. Juni 2024

Kommentierte Links (CXV)

Grafik: Pixabay / Geralt - Lizenz
Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Maarten Dalmijn: Scrum Alternatives: SCREAM!

Die Mitte der 2010 Jahre ist im Rückblick die große Zeit der Scrum-Verschlimmbesserungen gewesen Ich selbst habe mich seinerzeit über einige dieser (inzwischen zu Recht in Vergessenheit geratenen) Konstrukte aufgeregt, namentlich über Reliable Scrum, Ultimate Scrum, Secure Scrum und Autoscrum. Maarten Dalmijn hat jetzt irgendwo einen weiteres derartiges Framework ausgegraben, dem ohne erkennbare Ironie der Name SCREAM! gegeben wurde, und das im Gegensatz zu den anderen noch irgendwo im Einsatz ist - mit sehr überschaubaren Ergebnissen. Es ist ein kurioses Phänomen: nahezu alle Versuche, ein "verbessertes Scrum" zu erfinden, enden im Gegenteil.

Pawel Huryn: How to Fix the Double Diamond of Design Thinking?

Ich habe eigentlich schon länger vor, irgendetwas zum Thema Design Thinking zu schreiben, zu dem ich ein sehr gespaltenes Verhältnis habe. Einerseitz ist der Ansatz von der Grundidee gut, andererseits endet seine Umsetzung regelmässig mit einem Wasserfall im Wasserfall, genauer gesagt mit einem Sequenzmodell innerhalb der Anforderungsphase. Pawel Huryn ist mir mit seinem Artikel jetzt zuvorgekommen, und das auch noch mit einem lobenswerten Spin. Statt sich einfach nur über das zu beschweren, was problematisch ist, macht er Vorschläge dazu, wie es besser ginge: durch mehr Feedback-Schleifen, Continuous Delivery und zusätzliche Erkenntnisquellen. Das sind gute Ideen.

Danny Faught: Beyond Scrum

Eine häufige Entwicklung (und eine, die ich auch absolut ok finde) ist die, dass Teams, die eine Zeit lang nach Scrum gearbeitet haben, irgendwann anfangen dessen Regeln an ihre Bedürfnisse anzupassen. Danny Faught berichtet in seinem Erlebnisbericht seiner letzten Einsätze von einigen Veränderungen, die auch ich immer wieder erlebt habe: aus den fest getakteten, auf ein einziges Ziel focussierten Sprints wird ein Flow-orientierter Durchlauf, aus dem Versuch Aufwände zu schätzen werden Durchsatz-Zahlen, dazu kommen andere Elemente aus Kanban und XP. Das was die Fälle aus diesem Bericht von vielen anderen unterscheidet ist ihre Ehrlichkeit - es wird auch nicht so getan, als würde das Ergebnis noch Scrum sein. Es ist irgendetwas anderes geworden.

Elaine Lin Hering: How to Get Your Team to Actually Speak Up

Ein weiterer Schritt heraus aus der Scrum Bubble, diesesmal einer, in dem es um eine der absoluten Grundlagen und Vorbedingungen für agiles Arbeiten geht: darum, dass die Mitarbeiter bereit sind, offen, ehrlich und proaktiv zu kommunizieren. Die Ausführungen von Elaine Lin Hering zu diesem Thema haben viel mit psychologischer Sicherheit zu tun, aber auch mit ehrlichkeit, Berechenbarkeit, Einbeziehung und Unterstützung. Das ganze mit einer Management-Perspektive im Hinterkopf, also darauf bezogen, was ein Manager machen kann, um die erwähnten Effekte herbeizuführen.

Kent Beck: Minimum Viable Product revisited

Das es sehr unterschiedliche Verständnisse der Natur eines Minimum Viable Product (MVP) gibt, hatte ich irgendwann bereits aufgeschrieben. Auch Kent Beck, einer der Erfinder des Extreme Programming, hat seine Definition, die sehr der aus dem Lean Startup ähnelt. Ein MVP ist in seiner Sicht das Ergebnis der kleinstmöglichem Umsetzungsarbeit (Minimum), mit der man einen belastbaren Lerneffekt (Viable) zu dem Kundenanliegen an dem man arbeitet (Product) gewinnen kann. Mit anderen Worten: kein MVP to earn", sondern ein "MVP to learn". Auch aus meiner Sicht die spannendere und oft zielführendere Variante.

Dienstag, 25. Juni 2024

Runaway Effect

Bild: Pixabay / Peter Kaul - Lizenz

Es ist ein Phänomen, das man immer wieder beobachten kann: in irgendeiner Softwareentwicklungs-Organisation tritt eine Verschlechterung der Arbeits-Effektivität und -Effizienz auf, erst nur ein bisschen, dann ein bisschen mehr, dann deutlich mehr, dann viel mehr. Verbesserungsmassnahmen werden ergriffen, aber im besten Fall verlangsamen sie die Entwicklung nur, im schlimmsten Fall bleiben sie wirkungslos. Es wird immer schlimmer. Für dieses Phänomen gibt es einen Namen: den Runaway-Effekt.


Die Gründe für diese Benennung sind offensichtlich. Zum Einen erinnert die zunehmende Beschleunigung der Verschlechterung an einen Läufer oder Motor, der nach dem Start immer mehr Geschwindigkeit aufnimmt, zum Anderen an den Versuch, eine schnellere Person einzufangen. Aufgrund ihrer höheren Geschwindigkeit wird sie immer in der Lage sein, sich durch Weglaufen dem Zugriff zu entziehen. Übertragen: wenn das Problem an einer Stelle gelöst ist, ist es längst woanders aufgetaucht.


Der Grund für diese Entwicklung ist fast immer der gleiche: irgendwann wurde bewusst oder unbewusst entschieden, technische Schulden aufzunehmen, also nichtfunktionale (und für den Nicht-Techniker unsichtbare) Qualitätsaspekte wie Testabdeckung, Clean Code und stringente Architektur wegzulassen, um dadurch mehr Zeit für die Featureentwicklung zu haben. Das Tückische daran - in der unmittelbar anschliessenden Zeit halten sich die Folgen scheinbar in Grenzen.


Im Einzelnen sehen diese Folgen so aus, dass an einigen Stellen etwas mehr manueller Aufwand entsteht (z.B. beim Testen), und dass Code und/oder Architektur nicht sofort verständlich sind, so dass man sich bei einer Weiterentwicklung zuerst "Hineindenken" muss. Im Hintergrund geht der Runaway-Effekt aber bereits los: bei den manuellen Tätigkeiten kommt es zu Flüchtigkeitsfehlern und neuer Code "erbt" seine Architektur und (Un)Verständlichkeit von dem bereits vorhandenen.


Das addiert sich über die Zeit auf, die manuellen Aufwände (und Fehler) werden immer mehr und die Nachvollziehbarkeit von Code und Architektur wird immer geringer. Beides sorgt ausserdem dafür, dass immer mehr Fehlfunktionen versehentlich ins System gelangen, wo sie mit mühsamer Detektivarbeit gesucht werden müssen, wenn ihre Auswirkungen irgendwann auffallen. In Kombination sind das die Gründe für die ständig grösser werdenden Effektivitäts- und Effizienzverluste.


Schlimmstenfalls kommt es sogar dazu, dass IT-Systeme selbst dann ständig zunehmende Probleme generieren wenn gar nicht an ihnen gearbeitet wird. Unter Lastspitzen zusammenbrechende Systeme können ein Grund dafür sein, aber auch vollaufender Speicherplatz, in den unmöglichsten Situationen auftretende Race Conditions oder Fehler, die nur zu bestimmten Zeitpunkten auftreten können, etwa beim Jahreswechsel oder bei der Sommer- und Winterzeitumstellung.


Ein häufiger Versuch, den Runaway-Effekt in Griff zu bekommen sind so genannte Code- oder Feature-Freezes. Beim ersten wird die Anwendung gar nicht mehr weiterentwickelt (z.B. weil stattdessen ein komplett neues System entwickelt wird), beim zweiten darf nicht mehr an funktionalen Erweiterungen gearbeitet werden, damit alle Arbeitskraft in den Abbau der technischen Schulden gehen kann, die für die Entstehung des Effekts gesorgt haben. Oft anzutreffen ist eine Kombination: Feature Freeze für wichtige oder häufig zu ändernde Teile, vorläufiger Code Freeze für den Rest.


Eine entscheidende Frage bei solchen Reparatur- oder Ablöse-Phasen ist, mit welchem Ziel sie durchgeführt werden. Wenn in ihnen das Ausmass der technischen Schulden unter eine Schwelle gedrückt werden  soll, ab der der Runaway-Effekt auftritt, ist das zumindest etwas, besser wäre ihr weitestmöglicher Abbau. Zum anderen ist entscheidend, ob danach ein erneutes Anstauen technischer Schulden zugelassen wird. Wenn ja, ist es nur eine Frage der Zeit, bis alles von vorne losgeht.