Spät auftretende Verspätungen

Bild: Rawpixel - CC0 1.0

Es ist eines der Phänomene, mit denen man hochrangige Manger so wahnsinnig machen kann wie mit kaum einem anderen, und gleichzeitig ist es erstaunlich häufig: es geht um Projekte, von denen lange Zeit behauptet wird, dass sie im Plan liegen, in denen aber kurz vor dem geplanten Ende auf einmal erhebliche Verspätungen entstehen. Wer verstehen will, wie es meistens zu diesem Ärgernis kommt, kann es sich an einem bekannten Beispiel erklären lassen - den Zügen der Deutschen Bahn.

Regelmässige Zugreisende kennen sehr ähnliche Abläufe: vor dem Beginn ihrer Reise, z.B. von Bonn nach Köln, überprüft man in der App den Reiseplan, und der Zug ist pünktlich. Auf dem Weg zum Bahnhof nochmal, noch immer keine Verspätung. Eine Viertelstunde vor der geplanten Abfahrt empfängt man die erste kleine Verzögerungsmeldung von fünf Minuten, aus denen werden bald 10, dann 15, dann 20 ... irgendwann fährt der Zug schliesslich mit 45 Minuten Verspätung ein. Was ist da passiert?

Die vom freundlichen Schaffner durchgegebene Erklärung lautet, dass es kurz vor dem Bahnhof eine grössere Baustelle gibt, wegen der die Gleise nur langsam befahrbar sind. Dadurch verspätet sich irgendwann der erste Zug des Tages. Der zweite Zug muss hinter ihm halten und warten bis die Gleise frei sind, und danach auch langsam weiterfahren. Hinter dem wartet der dritte, bevor auch er verlangsamt weiterfährt, hinter dem der vierte, und je mehr es werden, desto mehr Verspätung kommt zusammen.

Jetzt kommt der entscheidende Punkt: bis zu diesem Stau auf den Gleisen sind alle dort feststeckenden Züge pünktlich gewesen. Sie haben diese Stelle in der selben Zeit erreicht, die nötig gewesen wäre, wenn die gesamte Strecke frei befahrbar gewesen wäre. Und da nur der aktuelle Streckenstand überprüft wird um die Pünktlichkeit zu ermitteln, kommt es ab dort zum genannten Phänomen: bis kurz vor Bonn sind alle Züge pünktlich, sammeln auf den letzten Metern aber noch erhebliche Verspätungen an.

Die Parallelen zu Grossprojekten dürften offensichtlich sein: auch die passieren oft ein Stage- oder Quality-Gate nach dem nächsten in Time und in Budget, bis sie gegen Ende durch eines müssen, das viel mehr Zeit beansprucht als ursprünglich angenommen (häufig sind das Integration, QA, Rollout oder Inbetriebnahme). Und das Verrückte daran: Obwohl diese Verzögerungen absehbar sind, sind bis zu ihrem Eintreten alle Ampeln grün - schliesslich ist bis dahin noch alles im Zeitplan.

Der Weg es besser zu machen ist bei Zügen und Projekten der Gleiche: sobald absehbar ist, dass es in einem späteren Abschnitt zu Verspätungen kommen wird, müssen diese mit ihrem voraussichtlichen Wert zu der aktuellen Pünktlichkeits-Vorhersage addiert werden, auch (und gerade) dann, wenn bisher alle Zwischenziele dem Zeitplan entsprechend erreicht wurden. Nur dann hat die Pünktlichkeitsmessung überhaupt irgendeine Aussagekraft und Verwendbarkeit.

Eine wichtige Voraussetzung dafür, dass das passiert, ist übrigens, dass derjenige, der Verspätungen meldet, nicht dafür bestraft wird. Ist das doch der Fall, ist das für alle Beteiligten der frühen Phasen ein handfester Anreiz, nur Pünktlichkeitsmeldungen durchzugeben und die Verspätungsmeldung irgendwem möglichst weit hinten auf der Strecke zu überlassen. So entstehen aufgrund falscher Anreizgebung Wassermelonen-Projekte und Arschkarten-Lücken (mehr dazu hier).

Wenn derjenige, der die absehbar näherkommende Verspätungsursache meldet, nicht dafür bestraft wird, können bestenfalls noch Gegenmassnahmen ergriffen werden, schlimmstenfalls kann man aber zumindest die Verspätung mit ausreichendem Vorlauf kommunizieren. Den an der nächsten Station wartenden Menschen wird es dadurch möglich, sich darauf einzustellen, den eigenen Plan anzupassen und die durch die Verspätung freiwerdende Zeit anders zu benutzen als durch blosses Warten.

P.S.: der eine oder andere wird es sich schon gedacht haben - die Erklärung des Phänomens der spät auftretenden Verspätungen anhand der Züge von Bonn nach Köln kommt nicht von ungefähr. Wenn hier jemand von der Bahn mitliest: für den Reparaturbedarf auf der Strecke könnt Ihr nichts, aber realistische Verspätungs-Ankündigungen wären etwas, was vielen Reisenden wirklich helfen würde.

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

• Scrum Guide (offizielle Version)
  
• Scrum Guide (LeSS Version)

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.

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.

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.

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.

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

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.

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

Ein Bild sagt mehr als 1000 Worte (XLIII)

Social media users around the world are posting pictures of "blue screens of death" on devices located in airports, banks, and stores. #BlueScreen #CrowdStrike #Outage #Microsoft #GlobalOutage pic.twitter.com/IkklCTFWzm

— RRN (@RRNmedia) July 19, 2024

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

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.

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.

Two Pizza Teams

Bild: Unsplash / Faizan Saeed - Lizenz

Wenn versucht wird, eine Framework-neutrale Beschreibung für ein agiles Team zu finden (oder zumindest für eines, das theoretisch zu agilem Arbeiten in der Lage wäre), dann fällt vor allem im englischen Sprachraum immer wieder ein Begriff: der des "Two Pizza Teams". Das hört sich zunächst eher kurios an, tatsächlich steckt aber eine sehr handfeste Bedeutung dahinter, die, sobald man sie verstanden hat, sehr naheliegend ist - die aber auch mehr enthält als man denken könnte.

Erfunden wurde die Idee der Two Pizza Teams bei Amazon, und zwar in deren Software-Entwicklungsteams in den Vereinigten Staaten. Diese Information ist wichtig, weil das Klischee, dass dort alles etwas grösser ist, auch auf die Pizza zutrifft - von der berühmten New York Pizza schaft man z.B. nur zwei oder drei "Slices". Von zwei derartigen Pizzen bekommt man daher ca. 10 Menschen satt, und da das auch die Durchschnittsgrösse der Teams bei Amazon war, bürgerte der Begriff sich ein.

Die Idee hinter dieser geringen Grösse war, die Kommunikations- und Koordinationsaufwände innerhalb der Teams gering zu halten und ihnen dadurch Meetings und Bürokratie zu ersparen und sie zu einfachem Informationsaustausch und zu schnellen Entscheidungen zu befähigen. Wie schnell derartige Aufwände ohne diese Begrenzung ausser Kontrolle geraten können, zeigt die legendäre Visualisierung der exponentiell steigenden Zahl der Kommunikationskanäle bei nur linearer Steigerung der Teamgrösse:

The challenge with adding more engineers to a project. Just moving from 3 developers to 4 doubles the number of lines of communication. pic.twitter.com/sltsBUVq8w

— Rich Rogers (@RichRogersIoT) 1. Oktober 2017

Ebenfalls wichtig zu wissen ist, dass diese Teams zwar nach ihrer Grösse benannt wurden, bei Amazon aber noch weitere Kriterien erfüllen müssen: es muss sich bei ihnen um Einheiten handeln, die nur auf ein einziges (Teil-)Produkt oder einen einzigen Service fokussiert sind, und die nur daran arbeiten. Das schliesst die Bildung technischer Spezialistenteams ausdrücklich aus, da auch das wieder zu Kommunikations- und Koordinationsaufwänden führen würde, und zwar zwischen diesen Teams.

Die damit verbundene Gefahr ist allerdings, dass Two Pizza Teams sich verzetteln können, wenn sie versuchen alle Arbeiten selbst zu erledigen, für die in anderen Firmen verschiedene Spezialistenteams zuständig wären. Um das zu verhindern, gibt es technische Standards, die von den Teams eingehalten werden müssen: zum einen eine an der Fachlichkeit orientierte Architektur mit klaren Schnittstellen, zum anderen cloudbasierte und "as a Service" abrufbare Infrastrukturen und Plattform-Dienstleistungen.

Wenn all das gegeben ist, kommt der letzte Aspekt ins Spiel: bei Amazon müssen Teams so genannte "Single Threaded Leader" (STLs) haben, also Führungskräfte, die nicht mehrere Ziele gleichzeitig verfolgen dürfen (selbst dann nicht, wenn sie für jedes jeweils ein Team haben), sondern die nur für die Erreichung eines einzigen, im Idealfall fachlichen, Ziels verantwortlich sind. Auf diese Weise kann es gar nicht erst dazu kommen, dass Zielkonflikte an die Teams weitergegeben werden.

Two Pizza Teams haben also ihren Ursprung in der typischen Bestellung ihres gemeinsamen Mittagessens, gehen in ihrer Natur aber weit über eine blosse Grössenvorgabe hinaus. In gewisser Weise sind die einzuhaltenden organisatorischen, fachlichen und technischen Vorgaben sogar so umfangreich, dass man von einem eigenen agilen Framework sprechen kann, das sich anstelle von Scrum, XP oder den Skalierungsframeworks einsetzen lässt. Zumindest wenn sie so umgesetzt werden wie bei Amazon.

Im umgangsspachlichen Gebrauch kann mit diesem Begriff manchmal aber auch die blosse Teamgrösse von ca. 10 Personen gemeint sein. Wie so oft gilt nämlich auch hier: es kommt bei Fachwörtern ganz darauf an, wer sie benutzt, wieviel Vorwissen er hat, wie frei er es interpretiert und in welchem Kontext er das tut. Anders wäre es vermutlich auch langweilig.

Why Everybody Hates Agile

Ich glaube zwar nicht, dass "alle" agiles Arbeiten hassen, aber Jesper Boeg hat einen Punkt, wenn er sagt, dass es Fehlentwicklungen gibt, die viele Menschen von dem abstossen, was heute unter dem Label "Agile" vermarktet wird. Und seine Aufzählung dieser Fehlentwicklungen und ihrer Folgen dürfte fast jedem der agil arbeitet an der einen oder anderen Stelle bekannt vorkommen.

Dankenswerterweise belässt er es nicht dabei, sich ausführlich zu beschweren, sondern er hat einen Vorschlag für ein besseres Vorgehen: kundenorientiert und prinzipiengetrieben arbeiten. Jetzt gilt es nur noch, das umzusetzen, ohne dass wieder jemand ein dogmatisches Framework daraus macht.

Newton’s Flaming Laser Sword (Alder's Razor)

Marketing ist alles, das trifft auch auf Leitsätze oder Leitprinzipien zu. Das vielleicht beste Beispiel dafür trägt den schönen Namen Newton’s Flaming Laser Sword (Isaac Newtons brennendes Laser-Schwert), verfasst 2004 vom australischen Mathematik-Professor Mike Alder in einem Artikel in der Zeitschrift Philosophy Now. Dieses Leitprinzip hat aber nicht nur einen bemerkenswerten Namen, es ist auch eines, das inhaltlich sinnvoll ist.

Der Hintergrund der Entstehung dieses Prinzips, war, dass Alder in Diskussionen zunehmend davon genervt war, dass Hypothesen erstellt oder Meinungen geäussert wurden, die so formuliert waren, dass sie nicht beweisbar oder widerlegbar waren. Konkret nannte er das Beispiel eines Philosophie-Professors seiner Univerität, der behauptete, künstliche Intelligenz könnte es nicht geben, da alles was künstlich wäre, keine Intelligenz sein könnte.¹

Sein als Erwiederung darauf gedachter Artikel ist zum einen ein seitenlanger Rant gegen dieses seiner Meinung nach unwissenschaftliche Vorgehen, zum anderen aber auch ein Verweis auf eine lange Reihe von Forschern und Wissenschaftlern, die gezeigt haben wie es besser geht, und die ihre Annahmen und Thesen überprüfbar und damit wiederlegbar gemacht haben. Besonders berief er sich dabei auf den englischen Physiker, Astronom und Mathematiker Isaac Newton.

Newton made his philosophical method quite clear. If Newton made a statement, it was always going to be something which could be tested, either directly or by examining its logical consequences and testing them. If there was no way of deciding on the truth of a proposition except by interminable argument and then only to the satisfaction of the arguer, then he wasn’t going to devote any time to it.

Mike Alder: Newton’s Flaming Laser Sword, Philosophy Now, May/June 2004

Übersetzt: wenn Behauptungen oder Annahmen gemacht werden, dann sollten es nur solche sein, die entweder durch eine Überprüfung oder durch logische Schlussfolgerungen bestätigbar oder widerlegbar sind. Wenn beides nicht möglich ist, und eine Diskussion über den Wahrheitsgehalt nur dadurch zu gewinnen ist, dass eine der Diskussionsparteien irgenwann erschöpft aufgibt, dann sollte man gar nicht erst anfangen, derartige Diskussionen zu führen.

Um den Bekanntheitsgrad dieses Denkansatzes zu fördern und um aufzuzeigen, dass er im Vergleich zum verwandten Konzept von Occam's Razor ein wesentlich schärferes Instrument darstellte, suchte Alder zuletzt noch nach einem eingängigen Namen für seine Schöpfung. Newton’s Flaming Laser Sword sollte genau das sein. Und zumindest in akademischen Kreisen und unter den Lesern des Magazins erreichte er damit auch schnell sein Ziel.

All good principles should have sexy names, so I shall call this one Newton’s Laser Sword on the grounds that it is much sharper and more dangerous than Occam’s Razor. In its weakest form it says that we should not dispute propositions unless they can be shown by precise logic and/or mathematics to have observable consequences. In its strongest form it demands a list of observable consequences and a formal demonstration that they are indeed consequences of the proposition claimed.

Mike Alder: Newton’s Flaming Laser Sword, Philosophy Now, May/June 2004

Kommen wir zur Übertragung in die Praxis, mit besonderer Berücksichtigung eines spezifischen Kontext: des Change Management. Auch hier gibt es immer wieder axiomatische Aussagen, etwa die, dass Angestellte die nicht kontrolliert werden aufhören würden zu arbeiten, oder die, dass durch die Gewährung von Selbstorganisation automatisch alles besser werden würde. Die Diskussionen darüber, ob das stimmt, sind häufig zutiefst philosophisch.

Newton’s Flaming Laser Sword kann derartige Debatten schnell beenden. Wann immer derartige Vermutungen oder Annahmen aufgestellt werden kann man fragen, ob es empirische Belege für sie gibt, bzw. ob es Möglichkeiten gibt, sie durch Empirie zu validieren. Wenn die Antwort auf beides Nein ist, kann ein Weiterführen der Diskussion zu keinem wirklichen Erkenntnisgewinn führen. Ist die Antwort dagegen Ja, kann die Unterhaltung auf die Zeit nach der Validierung vertagt werden.²

Vor allem in sehr debattenlastigen Umgebungen kann es sehr hilfreich sein, sich auf die Nutzung von Newton’s Flaming Laser Sword zu einigen. Sowohl die Länge als auch die empfundene Sinnlosigkeit vieler Diskussionen geht dann deutlich zurück. Und für alle, denen der Name nicht seriös genug erscheint, gibt es eine alternative Bezeichnung: Alder's Razor, benannt nach Mike Alder selbst. Das klingt neutraler, ist aber inhaltlich identisch.

¹Ganz nebenbei: dass Alder in diesem Artikel auch davon berichtet, bereits 2004 eine "halluzinierende" künstliche Intelligenz gehabt zu haben, zeigt auf, wie lange es dieses Phänomen bereits gibt
²Was natürlich die Bereitschaft voraussetzt, diese Validierungen zeitnah vorzunehmen

Agile Success Stories: Ein Kanban-Board mit 19 Spalten

Es ist mal wieder Zeit für eine Agile Success Story. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen, das kann man viel zu oft bei Agile Coaches, Scrum Mastern und ähnlichen Rollen erleben. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich selbst erlebte "agile Erfolgsgeschichten" veröffentliche, heute eine zum Thema Kanban.

Eigentlich hatte ich den Auftrag gar nicht annehmen wollen. Insgesamt sieben verschiedene Abteilungen eines Kunden wollten "ihre Zusammenarbeit agiler machen", davon drei Fachabteilungen, zwei aus der IT, eine aus Operations und eine aus dem Einkauf. Das klang als Herausforderung durchaus spannend, das Problem war aber das Budget - für eine Woche in Vollzeit würde es reichen, danach nur noch für vier Tage pro Monat während des restlichen Jahres. Im Grunde viel zu wenig.

Am Ende liess ich mich darauf ein, wenn auch mit einer klaren Einschränkung: in dieser knappen Zeit würde zu Beginn kaum mehr möglich sein als die Ermittlung und Visualisierung des Value Streams, und in späteren wöchentlichen Terminen ein Inspect & Adapt in kleinen Schritten. Die urspünglich vom Kunden gewünschte Einführung eines agilen Skalierungsframeworks wäre mit diesem geringen Aufwand illusorisch gewesen. Das wurde angenommen, also legten wir los.

Bereits das Value Stream Mapping war dann anspruchsvoll genug. Es handelte sich um eine geschäftskritische Anwendung, die auf Wunsch interner und externer Stakeholder ständig weiterentwickelt wurde. Neue Features wurden jeweils von einer der drei Fachabteilungen beauftragt und entweder von einer der beiden internen IT-Abteilungen oder durch externe Dienstleister (koordiniert durch den Einkauf) entwickelt.

Das, was dieses Vorgehen schwierig machte, waren Unübersichtlichkeit und Intransparenz. Es gab so viele Feature Requests (die natürlich alle dringend waren), dass niemand einen Gesamtüberblick darüber hatte, welche internen oder externen Entwickler gearde im Auftrag welcher Fachabteilung etwas umsetzten. Das Ergebnis waren redundante Arbeiten, die Entwicklung inkompatibler Features, ständige Nacharbeiten, zu hohe Arbeitsbelastung und ständig gerissene Deadlines.

Nach einer Woche intensiven Nachforschens gab es dann ein erstes Ergebnis: abhängig von den beiden Variablen bestehendes/neues Budget und interne/externe Entwicklung liessen sich drei Varianten des Value Streams identifizieren, eine mit 10 Stationen, eine mit 15 und eine mit 19 (!). Da das bei weitem zu viel war um auf einem Bildschirm überblickbar zu sein, fand die Visualisierung in Form eines physischen Kanban-Boards statt - Drei Zeilen mit jeweils 10, 15 und 19 Spalten.¹

Bis zu unserem ersten Einzeltermin hatten die verschiedenen Einheiten sich dann die Aufgabe mitgenommen, alle grösseren Arbeitspakete an denen sie gerade sassen auf dieses Board zu bringen. Als ich nach einer Woche zurückkam war ich erstmal erschlagen - mehr als 60 verschiedene Zettel hingen über das ganze Board verstreut, jeder einzelne davon als Symbolisierung eines Gesamtaufwandes von mindestens einer Personenwoche. Kein Wunder, dass bisher die Übersicht gefehlt hatte.

Eigentlich hatte ich als nächstes vor diesem Board ein Daily etablieren wollen, was aber in einem lauten Proteststurm unterging ("Nicht noch mehr Meetings", wurde gefordert). Worauf sich alle einlassen konnten war aber ein wöchentlicher Termin, in dem Vertreter der sieben Abteilungen alles was in den letzten Tagen stattgefunden hatte auf dem Board aktualisierten, egal ob es neue Requests, Entwicklungsfortschritte, Budget-Zusagen oder sonst etwas waren.

Was in diesen Terminen auffällig war, war, dass nahezu jede Aktualisierung eine mittelgrosse Diskussion auslöste. Deren Inhalte reichten von Überraschung und Interesse über Zustimmung und Feedback bis hin zu Protest und Sinnfragen. Nahezu jeder der teilnahm hatte irgendetwas zu irgendeinem Thema beizutragen, so dass es regelmässig mehr als zwei Stunden dauerte, bis auf dem Board alles auf den aktuellen Stand gebracht war.²

Das wirklich Bemerkenswerte an diesen "Kanban Weeklies" war aber nicht ihre Länge. Anders als man es hätte erwarten können gab es kaum Beschwerden darüber, dass in sie so viel Zeit investiert werden musste oder dass in ihnen so viele Themen diskutiert wurden. Stattdessen wurde regelmässig hervorgehoben, wieviel grösser durch sie Transparenz, Übersichtlichkeit und als Folge dessen auch Planbarkeit und Reaktionsfähigkeit geworden wären.

Gleich mehrfach konnten neue Feature Requests einzelner Fachabteilungen bereits im Anbahnungsstatus gestoppt werden, weil eine der anderen darauf hinwies, etwas Vergleichbares bereits beauftragt zu haben. Die Entwicklungsabteilungen konnten besser absehen, wann grössere Arbeitspakete bei ihnen einschlagen würden und sich entsprechend Zeit einplanen. Die Operations-Abteilung konnte sich auf Lastspitzen durch neue Features besser einstellen. Etc, etc, etc.

Selbst wenn es WIP-Limits, Service-Klassen, Durchlauf-Metriken und viele andere Ideen die ich hatte aufgrund des beschränkten Zeitbudgets nicht mehr in dieses Kanban-System geschafft haben, wurden das Board uns seine Benutzung von allen Beteiligten als eine spürbare Verbesserung gesehen, durch die die meisten der oben genannten Probleme (redundante Arbeit, Intransparenz, ständige Nacharbeiten, etc.) spürbar zurückgegangen waren.

Auch ich habe aus diesem Einsatz eine Lehre mitgenommen: auch eine punktuelle Begleitung kann unter Umständen völlig ausreichend sein. Es braucht nicht immer einen Scrum Master, Kanban Coach oder sonstigen Methodiker, der in Vollzeit ein Team begleitet, manchmal kann es genügen, den Arbeitsfluss zu visualisieren, alle Beteiligten dazu zu bewegen ihn sich regelmässig gemeinsam anzusehen und darauf zu vertrauen, dass sich daraus die richtigen Dinge ergeben werden.

Und eine zweite Erkenntnis (die ich aber bereits vorher hatte) gebe ich noch dazu. Ab einer bestimmten Grösse sollten Kanban-Boards in physischer Form aufgebaut werden, eines wie das hier beschriebene könnte man auf keinem Bildschirm auch nur annäherungsweise übersichtlich darstellen. Um eines meiner Lieblingszitate zu bringen: "When you put a problem in a computer, the box hides the answer. The problem must be visible!"

¹Also deutlich mehr als auf dem Symbolbild auf dieser Seite
²Ich meine mich sogar an einen Termin erinnern zu können, der mehr als vier Stunden dauerte

Scrum goes Pop Music (IV)

Kaum schaut man zwei Jahre nicht hin, schon veröffentlicht jemand neue Musik. Chad Beier ist seinem Hobby treu geblieben und hat weitere, auf das Thema der agilen Produktentwicklung umgetextete, Coverversionen bekannter Pop- und Rockhits aufgenommen (siehe hier, hier, hier und hier). Wunderbar geeignet für die Party nach dem nächsten erfolgreichen Release.

Der Harmont-Effekt

Bevor wir heute in die Business-Welt eintauchen, gibt es einen kleinen Ausflug in die Weltliteratur: wir werfen einen kurzen Blick in den Science Fiction-Roman Picknick am Wegesrand, von den legendären Brüdern Arkadi und Boris Strugazki. Er spielt in der fiktiven amerikanischen Stadt Harmont, in der Jahre zuvor Ausserirdische mit einer unbekannten Mission gelandet sind, nach deren Abschluss sie den Planeten Erde wieder verlassen haben.

Inhaltlich dreht sich der Roman um den Umgang der Menschen mit verschiedenen rätselhaften Objekten, die die Ausserirdischen zurückgelassen haben. Sie sind hoch entwickelt und hübsch anzusehen, der Versuch sie zu benutzen ist aufgrund des fehlenden Wissens um ihre Funktionsweise aber hochriskant und endet für die Menschen oft mit Verletzungen oder Unfällen. Und damit genug von der Literatur und zurück ins Business.

Auch in grossen Unternehmen und Behörden gibt es das Phänomen, dass von ausserhalb kommende Besucher rätselhafte Hinterlassenschaften zurückgelassen haben, von denen keiner genau weiss wie sie funktionieren und deren Benutzung für jeden der es versucht riskant ist. In Anlehnung an Picknick am Wegesrand, bzw. an dessen fiktiven Hadlungsort, beschreibe ich die Entstehung dieser Hinterlassenschaften gerne als den Harmont-Effekt.

Was das für von ausserhalb kommende Besucher sind? Verschiedene, aber die vermutlich wichtigste Gruppe unter ihnen dürften ganz klar die Strategieberatungen sein, die einfliegen, auf Topmanagement-Ebene ihre Ideen verkaufen, und wieder abfliegen ohne sich an der Umsetzung zu beteiligen (oder genau zu wissen wie das ginge). Klassische Strategieberatungs-Hinterlassenschaften sind SpotiSafe und OKRs, die irgendwie auf bestehende Strukturen gekippt werden und dort alles verbürokratisieren.

Die zweite Gruppe sind die Vertreter grosser Standardsoftware-Hersteller, deren Versprechen darin besteht, dass ihr Produkt zwar nicht alle, zumindest aber viele Probleme lösen könnte. Sobald diese Systeme dann angewandt werden sollen, beginnen aber die Schmerzen der inkompatiblen Formate und Workflows, verbunden mit fehlendem Wissen über Konfigurierbarkeit und Erweiterungen. Klassische Hinterlassenschaften dieser Art sind Systeme von SAP, Atlassian, Salesforce und ähnlichen Anbietern.

Eine dritte Gruppe sind Thought Leader und Management-Gurus, auf die der sie beauftragende Manager durch einen Konferenzvortrag oder eines ihrer Bücher aufmerksam geworden ist. Meistens sind ihre Lösungen durch Vereinfachung und Generalisierung anschlussfähig, scheitern in der Regel aber am Wissen, wo sie im Einzelfall Sinn machen und wo nicht. Klassische Thought Leader-Hinterlassenschaften sind Open Space-Formate für Meetings oder unbenutzte Flight Level-Boards.

Als letzte, aber seltenere Gruppe könnte man Manager nennen, die in anderen Unternehmen oder Unternehmensteilen beruflich sozialisiert wurden, und die jetzt versuchen, die dort erlerntern Strukturen und Prozesse auf ihre neue Umgebung zu übertragen. Oft endet das darin, dass nur noch Probleme für diese Lösungen gesucht werden, statt umgekehrt. Klassische Hinterlassenschaften dieser Art sind die "Playbooks" von Google, Amazon oder Spotify.

Die gemeinsame Ursache für diese verschiedenen Ausprägungen des Harmont-Effekts ist, dass in keinem dieser Fälle eine in die Breite gehende Vermittlung von Systemverständnis, Kontextwissen und Prozessdesign-Techniken stattgefunden hat. Stattdessen ist es jeweils eine kleine, oft nur kurzzeitig präsente Gruppe, die Hau Ruck-artig Neuerungen einführt und bereits wieder verschwunden ist, wenn sich aus der Anwendung Fragen und Probleme ergeben.

Ein besseres Vorgehen wäre es, von Beginn an so in die eigenen Mitarbeiter zu investieren, dass diese zu Problemanalyse und Lösungsentwicklung selbst in der Lage sind. Das kann auch gerne mit externer Unterstützung passieren, diese sollte aber nicht mit dem Ziel erfolgen, dass fertige Lösungen von Aussen mitgebracht werden, sondern dass sie intern bedarfsgerecht entwickelt werden können. Derartige Ergebnisse würden dann auch nicht mehr wie rätselhafte ausserirdische Hinterlassenschaften wirken.

Kommentierte Links (CXIV)

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.

Christiaan Verwijs: Why Science Is Essential To Professionalize Our Community

Es ist einer der grossen Schwachpunkte der agilen Community: es gibt sehr viele starke Meinungen über das für und wieder der verschiedenen Frameworks und Praktiken, nur in den seltensten Fällen sind sie aber durch belastbare und reproduzierbare Empirie validiert. Christiaan Verwijs erklärt warum das problematisch ist, zeigt auf welche Möglichkeiten es gibt, die eigenen Ansichten mit Fakten zu untermauern und weist auf ein grundlegendes Problem hin: anders als in anderen Berufen gibt es bei Product Ownern, Scrum Mastern, Agile Coaches keine nichtkomerziellen Organisationen, die für die Einführung und Beibahaltung derartiger Arbeitsweisen sorgen könnten.

Benjamin Huser-Berta: Limit Work in Progress without Work In Progress Limits (Teil I, Teil II)

Kanban ist vermutlich das am häufigsten missverstandene agile Framework (die Debatte ob es agil oder lean ist sparen wir uns an dieser Stelle). Die meisten Menschen verwechseln es mit dem blossen Kanban-Board, und selbst die, die verstehen, dass mehr dahinter steckt, kennen darüber hinaus häufig nur die Praktik der Limitierung paralleler Arbeit. Benjamin Huser-Berta zeigt eine weitere auf, die Messung und Regulierung des Total Work Item Age (TWIA), also des durchschnittlichen Alters der im System befindlichen Arbeitspakete. Beim Durchlesen dürfte auch klar werden, warum TWIA eher unbekannt ist - damit zu arbeiten erfordert Aufwand und Disziplin.

Hauke Friederichs: Mit billiger Hightech gegen die Russen

Die Verteidigung der Ukraine gegen den russischen Angriffskrieg hat an vielen Stellen den verdrängten Fakt wieder erkennbar gemacht, dass das agile Arbeiten Wurzeln und Parallelen in der Kriegsführung hat (siehe hier, hier und hier). Hauke Friedrichs hebt am Beispiel von für die Ukraine arbeitenden deutschen Rüstungsfirmen eine weitere hervor: bei der Entwicklung von neuen Waffen- und Abwehrsystemen sind einfache, flexible Praktiken dringend nötig, wenn sie zeitnah zum Einsatz kommen sollen. Schnelle, unbürokratische Entwicklung, enger Austausch mit den Anwendern, modularer Aufbau und kontinuierliche Weiterentwicklung. Die Parallelen zur agilen Produktentwicklung sind unübersehbar.

Michael Küsters: The Scrum Master as a Trash Collector

Ein interessanter Ansatz zum Reframing der Rolle des Scrum Masters. Statt seine Rolle durch die Einführung dessen zu definieren, was Scrum einer Organisation zusätzlich hinzufügt (Rollen, Regeln, Praktiken, Meetings, etc) stellt Michael Küster bei seiner Betrachtung in den Mittelpunkt, was der Scrum Master abschaffen sollte: Bürokratie, Redundanzen, Ineffizienz, Stress und weitere verbreitete Zeit- und Geldfresser. Mein erster Gedanke - würde sich diese Sichtweise im Management verbreiten, würde das automatisch zu einer ganz anderen Legitimation vieler Massnahmen führen.

Maarten Dalmijn: Scrum's Built-in 'Get Out of Jail Free Card' Against Criticism

Was Maarten Dalmijn hier macht, ist die Enttarnung vieler Verteidungen von schlecht funktionierendem Scrum als No true Scotsman-Fehlschlüsse. Sie alle drehen sich darum, dass angeblich nicht die Methode selbst im jeweiligen Zusammenhang unpassend war, sondern dass sie lediglich falsch oder halbherzig umgesetzt wurde. Hätte man es "richtig" gemacht, wäre alles ganz anders gekommen. Das ist natürlich bequem, geht aber an der Realität vorbei. Scrum ist nicht überall die ideale Lösung, manchmal gibt es andere Ansätze die besser passen.

Nein, das ist nicht die Unternehmenskultur

Unter Unternehmensberatern gibt es einen alten Witz: wenn man etwas über die Kultur eines Unternehmens wissen will, dann sollte man sich zuerst ihre offizielle Beschreibung zeigen lassen - denn dann weiss man zumindest wie sie nicht ist. Das ist sicher zynisch, das ist aber auch in den meisten Fällen wahr, denn die offiziellen Unternehmenskulturen stimmen nur selten mit denen, die tatsächlichen im Alltag gelebt werden, überein.

Bevor wir auf die Gründe dafür eingehen, ein kurzer Hinweis: es ist in diesem Zusammenhang egal auf welchem Weg die offizielle Unternehmenskultur entstanden ist, wie sinnvoll oder menschenfreundlich sie erscheint, wie sehr sich die Belegschaft mit ihr identifiziert oder wie stark und häufig sie betont oder verlangt wird. Es gibt strukturelle Gründe die praktisch immer dafür sorgen, dass offizielle und gelebte Kultur sich unterscheiden. Hier sind sie:

Kultur ist ausdifferenziert und nicht in wenigen Schlagwörtern beschreibbar

Die meisten offiziellen Beschreibungen von Unternehmenskulturen bestehen nur aus wenigen Werten, Prinzipien oder Umgangsregeln. Selbst wenn diese zutreffen sollten, würden sie aber nur einen Teil der jeweiligen Kultur beschreiben, zu der ausserdem noch Glaubenssätze, Verhaltens- und Deutungsmuster, mündliche Überlieferungen (wisst Ihr noch, damals in Projekt Omega ...), sprachliche Besonderheiten, Traditionen und viele weitere Dinge gehören, die insgesamt ganze Bücher füllen würden.

Kultur ist nicht nur positiv

Was praktisch alle offiziellen Kulturbeschreibungen gemeinsam haben ist, dass sie ausschliesslich positive Aspekte beschreiben: Verlässlichkeit, Solidarität, freundlicher Umgang, Leistungsbereitschaft, etc. In der Realität gehören zu praktisch jeder Kultur aber auch negative Aspekte, die häufig sogar mit den positiven zusammenhängen: Sorgfalt führt z.B. oft zu Perfektionismus, Experimentierfreude zu Unvorsichtigkeit, und so weiter. Ohne diese Aspekte sind Kulturbeschreibungen unvollständig.

Kultur ist nicht überall im Unternehmen gleich

Schon in kleinen Unternehmen existieren verschiedene (Teil-)kulturen, die sich zum Teil deutlich unterscheiden: Innendienst und Aussendienst, Entwicklung und Marketing oder Management-Ebene und Umsetzungs-Ebene weichen mitunter so stark voneinender ab, dass von einer gemeinsamen Kultur kaum noch die Rede sein kann. Und in Grossorganisationen kann jedes Ressort oder sogar jede Abteilung eine eigene Kultur haben, die mit der offiziellen nur in Teilen übereinstimmt.

Kultur ist nicht stabil

Mit anderen Worten: selbst wenn die offizielle Unternehmenskultur einmal mit der tatsächlich gelebten übereinstimmen sollte, wäre das nur eine Momentaufnahme. Kommende und gehende Kollegen, steigender Wettbewerbsdruck mit darauf folgenden Verteilungskämpfen um knapper werdende Ressourcen, technische Entwicklungen, gesellschaftliche Trends und vieles mehr tragen ununterbrochen dazu bei, dass Kultur sich verändert - weg von der offiziellen Beschreibung.

Kultur ist subjektiv

Zuletzt: egal was Teil einer offiziellen Unternehmenskultur ist, verschiedene Menschen werden diese Begriffe unterschiedlich verstehen. Gerade die häufig verwandten Schlagworte wie Respekt, Verantwortung, Offenheit, Gemeinsamkeit und Ähnliche sind so generisch, dass sich unterschiedliche Deutungen nicht verhindern lassen. Die Folge ist, dass zwar alle die Kultur mit den gleichen Worten beschreiben, das dahinterliegende Verständnis aber weit auseinandergehen kann.

Es würden sich vermutlich noch weitere Gründe dafür finden lassen, dass die offizielle und die tatsächlich gelebte Unternehmenskultur sich praktisch immer unterscheiden, aber auch aufgrund der hier bereits genannten dürfte klar sein: es ist so. Das macht die offiziellen Kulturbeschreibungen zwar nicht schlecht, es sorgt aber dafür, dass sie (wenn überhaupt) nur Teilaspekte oder Vergangenheitsformen beschreiben, und nicht das was im Alltag anzutreffen ist.

Man muss die schönen Kulturprogramme und -darstellungen auch deshalb nicht abschaffen, man kann sie durchaus beibehalten, wenn auch mit einer wichtigen Ergänzung: allen sollte bewusst sein, dass es sich bei ihnen nicht um eine aktuelle Zustandsbeschreibung handelt, sondern um ein ambitioniertes Zielbild, auf das man zwar hinarbeiten kann, das man aber nicht in Gänze oder dauerhaft erreichen kann. Wenn alle sich auf dieses ständige gemeinsame Hinarbeiten einigen, dann hat eine offizielle Unternehmenskultur einen Sinn. Sonst nicht.

Deine Muda: Overthinking

Bild: Pexels / Thirdman - Lizenz

Zehnter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann, kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Overthinking.

Zuerst ein Übersetzungsversuch. Für den Begriff Overthinking gibt es keine exkte Entsprechung in der deutschen Sprache, eine sinngemässe Übersetzung wäre "länger über etwas nachdenken als sinnvoll ist" oder "unverhältnismässig lange über etwas grübeln". In beiden Übersetzungs-Varianten ist die Muda-Natur bereits offensichtlich enthalten, bei näherer Betrachtung lassen sich aber ausserdem noch verschiedene Problem-Dimensionen erkennen.

Zum einen kostet ein unnötig langes Nachdenken die Beteiligten (Arbeits-)Zeit und damit ihr Unternehmen auch Geld. Das führt entweder dazu, dass sie nicht mehr für andere Tätigkeiten verfügbar sind (dazu gleich mehr) oder es hat zur Folge, dass zur Kompensation dieser Ausfälle weitere Menschen eingestellt werden müssen. Der zweite Fall wird nochmal schwerwiegender dadurch, dass diese Einstellungen (plus Koordination, Bezahlung etc.) weitere Verwaltungsaufwände erzeugen.

Zum anderen kann es zum Phänomen der Verzögerungskosten (Cost of Delay) kommen. Wird die durch das Overthinking entstehende Mehrarbeit nicht durch zusätzliches Personal kompensiert, schieben sich andere Tätigkeiten zwangsläufig nach hinten, wodurch sich Einnahmen verzögern (und dadurch kleiner ausfallen) können, Geschäfts-Chancen verschwinden können oder zusätzliche Zinsen auf alte oder neue Kredite anfallen können, die zur Kompensation ausfallender Einnahmen nötig werden.

Angesichts dieser Nachteile stellt sich die Frage, warum das Overthinking in vielen (vor allem grossen) Organisationen so weit verbreitet ist. Die Antwort kann natürlich je nach Einzelfall eine andere sein, häufige Gründe sind meiner Erfahrung nach aber Perfektionismus, Machbarkeits- und Steuerbarkeits-Illusionen, Risiko-Aversion (häufig verbunden mit knappen Budgets, deren Verwendung man unter Kontrolle halten will) und fehlende Systemsicht.

Um die nicht gewinnbringende, aber ressourcenverbrauchende Muda des Overthinking in den Griff zu bekommen, ist es daher erfolgsversprechend, zu untersuchen ob eine diese zugrundeliegenden Ursachen gegeben ist, um diese zu thematisieren und möglichst zu beseitigen. Selbst dann wenn das nicht gelingt, kann aber alleine die Erkenntnis der problematischen Effekte ausreichend sein, um ein Zurückfahren der Grübel-Aufwände auf ein sinnvolles Mass zu verursachen.

Agile vs Lean

Eine Frage, die unter Methodikern und Theoretikern gerne und ausgiebig diskutiert wird, die man als Berater aber auch immer wieder beim Kunden gestellt bekommt, ist die nach dem Unterschied zwischen Agil und Lean. Ist das nicht irgendwie ähnlich oder sogar identisch? Dreht sich nicht beides darum, das eigene Vorgehen durch ständige Verbesserung so zu optimieren, dass man effektiver, effizienter und reaktionsfähiger wird?

Bevor ich eine Antwort darauf versuche, ein Disclaimer: weder Agil noch Lean sind abschliessend definiert. Es gibt zwar das Manifest für agile Softwareentwicklung als zentrales Dokument, das aber nur sehr abstrakte Richtlinien vorgibt, und auf der Lean-Seite das ebenfalls nur Richtlininien vorgebene Toyota Production System. Darüber hinaus gibt es auf beiden Seiten nur noch optionale Praktiken und Sekundärliteratur. Aus all dem sind aber Definitionen ableitbar.

Der offensichtlichste Unterschied dürfte der Einsatzbereich sein. Agil wird fast ausschliesslich in der Produktentwicklung gearbeitet,¹ also dort, wo sich die Herausforderungen aus (noch) unklarer Anwender-Akzeptanz, technischer Machbarkeit, etc. ergeben. Lean ist im Gegensatz dazu vor allem in der seriellen Fertigung verbreitet,² die Herausforderungen hier sind Betrieb und Stabilisierung extrem grosser und fehleranfälliger Fertigungsstrassen, Lieferketten, o.ä.

Beiden Arten von Herausforderung wird versucht mit ähnlichen Mitteln beizukommen, die auf der agilen Seite unter dem Schlagwort Inspect & Adapt zusammengefasst werden und auf der Lean-Seite unter den Begriffen Kontinuierliche Verbesserung (KVP) oder Kaizen. Beides dreht sich um ständige Optimierungen. Was aber grundsätzlich unterschiedlich ist, ist das im Mittelpunkt dieser Bemühungen stehende Objekt: im Fall von Agil ist es das Produkt, im Fall von Lean ist es der Prozess.

Im Fall von agilem Arbeiten sieht das konkret so aus, dass in den Inspect & Adapt-Terminen entweder neue oder geplante Funktionen mit Anwender-Vertretern oder Stakeholdern begutachtet werden (z.B. im Sprint Review) oder dass in ihnen überlegt wird, was getan werden kann um diese gemeinsame Begutachtung in kurzen Zyklen zu ermöglichen oder beizubehalten (z.B. in der Retrospektive). Es können natürlich auch andere Aspekte zur Sprache kommen, die sind aber im Vergleich sekundär.

Umgekehrt geht es in den KVP- und Kaizen-Events in erster Linie darum, den Erstellungsprozess eines Produkts (oder Teilprodukts) schneller, ressourcenschonender, weniger störungsanfällig oder vorhersagbarer (in Bezug auf Durchlaufzeiten oder Wartungsintervalle) zu gestalten.³ Auch hier ist es möglich, dass Impulse für die Produktentwicklung entstehen, die werden dann aber nicht selbst realisiert sondern in die vorgelagerten (agil arbeitenden) Produktentwicklungsprozess weitergeleitet.

Wie immer gibt es natürlich auch hier Grauzonen und Uneindeutigkeiten. Wenn es z.B. im Rahmen einer auf die Fertigungsprozesse bezogenen Kostensparmassnahme dazu kommt, dass ein anderer Werkstoff verwendet wird als bisher, dann kann das auch zu einer Veränderung des Produkts führen (das dann z.B. leichter ist). Und einen "historisch gewachsenen" Begriff wie Lean Startup hätte man im Rückblick besser "Agile Startup" genannt, um Missverständnisse zu vermeiden.

Im Grossen und Ganzen ist die Gleichung Agil = kontinuierliche Produkt-Optimierung und Lean = kontinuierliche Prozess-Optimierung aber gut geeignet um zu erkennen mit was man es gerade zu tun hat. Aufbauend darauf kann es dann auch leichter werden, Handlungsfelder, Zuständigkeiten und Handlungsoptionen zu definieren, aufzuteilen oder zusammenzulegen. Auch das sollte übrigens Teil einer kontinuierlichen Optimierung sein.

¹Der Begriff "Produkt" ist hier weit gefasst und enthält neben physischen Produkten auch digitale Produkte, Dienstleistungsprodukte, etc.
²Und in Umfeldern mit stark standardisierten Tätigkeiten, z.B. Systemgastronomie oder Callcenter
³Anders als man denken könnte ist das nichts womit man irgendwann fertig ist, sondern eher einen ständiges Austarieren

Ein Bild sagt mehr als 1000 Worte (XLII)

Bild: Comic Agile - CC BY-NC 4.0

Wer agiles Arbeiten nur mit digitalen Tools kennt, wird angesichts dieses Comics vielleicht etwas ratlos sein. Alle die es mit Post Its an Wänden kennen wissen, dass er witzig ist und dass es wahr ist.

Das agile Mindset (II)

Bild: Pexels / Yan Krukau - Lizenz

Ein Hoch auf die Wissenschaft! Diesesmal in Person von Karen Eilers, die an der Universität Kassel eine Wirtschaftsinformatik-Dissertation mit dem klangvollen Titel The Agile Mindset – Why it Matters, What it is, and How to Measure it verfasst hat. Was sie in diesem Rahmen an Erkenntnissen gewinnen konnte und wie sie diese zusammengetragen hat, hat sie in einem ausführlichen Gespräch in dem Podcast Agile World News erzählt.

An dem hier beschriebenen Ansatz gibt es einiges, das ich bemerkenswert finde, bereits angefangen damit, dass versucht wird dem Begriff "Mindset" seine Unschärfe zu nehmen. Es wird anerkannt, dass er sehr offen interpretiert werden kann und sehr unklar zu anderen Begriffen wie "Einstellung", "Haltung" und "Mentalität" abgegrenzt ist. Die hier gewählte Definition mag vielleicht nicht jeder teilen, aber zumindest gibt es hier eine. Eine sachliche Diskussion wird dadurch überhaupt erst möglich.

Ebenfalls erwähnenswert finde ich, dass das agile Mindset (Vorhandensein, Ausprägungen, etc.) in diesem Ansatz nicht mehr etwas ist, dass von aussen durch Zuschreibung oder "Diagnose" entsteht (was dort wo man es versucht fast zwangsläufig zu übergriffigem Verhalten führt). Stattdessen wird davon ausgegangen, dass es bei allen agil arbeitenden Menschen irgendwie vorhanden ist und nur noch durch Empirie identifiziert werden muss (vereinfacht gesagt: was oft genannt wird gehört dazu).

Die vier Themengebiete, die in der Dissertation am häufigsten identifiziert wurden und die in ihr daher als typisch oder konstituierend für ein agiles Mindset gelten, sind Lern-Orientierung, kollaboratives Arbeiten, Co-Creation mit den Kunden und Selbstorganisation. Das klingt passend zu dem Arbeitsmodus, den man meistens unter der Bezeichnung "agil" vorfindet, ist aber auch darüber hinaus spannend: letztendlich handelt es sich um eine Selbstbeschreibung (und damit Selbstwahrnehmung) der agilen Community.

Lern-Orientierung

Wenig erstaunlich. Lernorientierung ist u.a. das, was man in agilen Teams auch als Growth Mindset bezeichnen würde, also die Anerkennung der Tatsache nicht alles zu wissen, die Bereitschaft sich neues Wissen anzueignen, z.B. in Reviews, Retrospektiven, etc.

Kollaboratives Arbeiten

Ebenfalls erwartbar, da in den meisten agilen Teams Teil der täglichen Arbeit: gemeinsame Meetings, gemeinsame Arbeit an Anforderungen und ähnliche Praktiken beseitigen Kopfmonopole und Flaschenhälse und machen so den Arbeitsfluss schneller und resilienter.

Co-Creation mit den Kunden

Spannend, da hier etwas (aus meiner Sicht richtigerweise) als wesentlich beschrieben wird, was in der Realität oft nur eingeschränkt stattfinden kann. Hier könnte weitergeforscht werden, ob das Wunsch oder Wirklichkeit ist (vor allem in grossen Organisationen werden oft Kunde und Auftraggeber verwechselt).

Selbstorganisation

Ebenfalls ein wichtiges und richtiges Thema, bei dem ein tieferes Erforschen interessant wäre. Obwohl sich tatsächlich praktisch alle agil arbeitenden Teams als selbstorganisiert bezeichnen dürften, sind das Verständnis dieses Begrifft und die Ausgestaltung in der Realität extrem vielfältig.

Über diese ersten Einordnungsversuche hinaus ist für mich noch etwas weiteres auffällig: die vier identifizierten Kernbereiche sind sehr stark auf den Ebenen der Einzelpersonen und der sozialen Beziehungen in Umsetzungsteams angesiedelt. Die Aspekte der technischen Agilität aus DevOps, XP, etc. und der wirtschaftsnahen Business-Agilität kommen nicht vor, was ein Hinweis darauf sein könnte, dass vor allem Scrum Master (o.Ä.) und nur wenige Entwickler und Manager befragt wurden.

Die Arbeit bietet also einiges an Erkenntnissen, aber auch einiges an weiteren Forschungspotentialen und Denkanstössen. Es ist zu hoffen, dass diese Themen in Kassel und anderswo weitergeführt werden, so dass sich die Diskussion um das agile Mindset weg von starken Meinungen und hin zu gesicherten Ergebnissen bewegen kann. Denn auch das ist etwas, was für mich zu einem agilen Mindset gehören sollte: der Drang, empiriebasiert zu arbeiten.