On Lean and Agility

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.

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.

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.

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.

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.

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.

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.

Grafik: Pixabay / Geralt - Lizenz

Maarten Dalmijn: Scrum Alternatives: SCREAM!

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

Danny Faught: Beyond Scrum

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

Kent Beck: Minimum Viable Product revisited