Ein Bild sagt mehr als 1000 Worte (L)

Grafik: Forrest Brazeal - CC BY-NC-ND 4.0

Sehr wohltuend an der gerade laufenden Marktbereinigung: es hat schon länger niemand mehr den Gartner Hype Cycle auf irgendetwas Agiles angewandt.

The AI Build Trap

An sich klingt es erst einmal wie etwas Positives: mit Hilfe der immer besseren und intuitiveren KI-Tools ist es heute so einfach wie nie, Software zu erstellen. Sei es als Programmier-Unterstützung, wie im Fall des Github Copilot, oder als ein Programm, dass einem den Grossteil der Arbeit abnimmt, wie Lovable - es gibt eine ganze Reihe von Möglichkeiten, die eigene Produktivität in bisher ungeahnte Höhen zu schrauben. Und doch steckt auch ein Risiko dahinter.

Vereinfacht gesagt: wenn es auf einmal so einfach ist, neue Programme und Features zu erstellen, wird das auch mit grösserer Bereitwilligkeit getan werden als bisher. Statt aufgrund der begrenzten Kapazität der IT-Abteilungen nur die wirklich wichtigsten Anforderungen umzusetzen, kann jetzt jeder Kundenwunsch, jede einzelne Stakeholder-Anforderung und jede Entwickler-Idee in Produktion gebracht werden. Und das ist bei weitem nicht so positiv, wie es klingen mag.

Die offensichtlichste Folge eines derartigen bereitwilligen Umsetzens aller Wünsche ist die Entstehung von Bloatware, also von Anwendungen, die derartig mit Funktionen überladen sind (von denen viele nur eine sehr kleine oder ggf. sogar lediglich eine hypothetische Anwendergruppe haben) dass sie unübersichtlich werden, schlecht zu bedienen sind, hohe Ladezeiten haben und viel Speicherplatz einnehmen. Mit anderen Worten - es wird ein aus Kundensicht schlechtes Produkt.

Und auch unterhalb der Benutzeroberfläche führt das massenhafte Erzeugen von Funktionalitäten (und damit von Code) zu Problemen. Auch hier ist die Unübersichtlichkeit ein zentrales Problem. Je grösser die Codebase wird, desto schwieriger wird es zu sagen, an welcher Stelle was passiert. Die Überprüfung der KI-Ergebnisse durch einen Menschen (deren Verzicht einem Kontrollverlust gleichkäme) wird immer schwieriger und irgendwann sogar unmöglich.

 

Diese Phänomene erinnern nicht ohne Grund an die Build Trap (sinngemäss die Produktivitäts-Falle), die 2019 von Melissa Perri in ihrem gleich benannten Buch beschrieben wurde. Auch ihr selbst ist diese Parallele aufgefallen, und sie hat sie in mehreren Social Media-Posts thematisiert. Von ihr stammt auch die Erweiterung des ursprünglichen Begriffs zu dem der AI Build Trap, der damit als zusätzliche und spezifische Ausprägung dieses Antipatterns beschrieben ist.

Um auch hier zu einem konstruktiven Ausblick zu kommen: in die AI-Produktivitäts-Falle zu geraten, ist zum Glück kein Naturgesetz, man kann (und sollte) es auf verschiedene Weisen verhindern. Zum einen, indem man durch kleine, schnell veröffentlichte Incremente überprüft, ob es für die neuen Funktionen überhaupt Bedarf oder Akzeptanz gibt, zum anderen indem intern regelmässig sichergestellt wird, dass der Code von Menschen verstanden wird und ggf. verändert werden kann.

Das kann sich natürlich wie eine Entschleunigung der gerade erst gewonnenen Programmier-Höchsgeschwindigkeit anfühlen - und es ist auch eine. Trotzdem ist es sinnvoll, sich darauf einzulassen, wenn man nicht riskieren will, sich in der Build Trap wiederzufinden, und Produkte gebaut zu haben, die vom  Kunden nicht gewollt und von den eigenen Entwicklern nicht verstanden werden.

Interview with an Senior DevOps Engineer 2025

Dieses Video von Kai Lentit hat mich diese Woche mehr als einmal zum Lachen gebracht. Nicht nur wegen der Rolle, in die erschlüpft (irgendwas zwischen Super Mario und Albert Einstein), sondern vor allem wegen der hohen Dichte von DevOps-bezogenen Gags. Etwas Schönes für die IT-Nerds.

Witzig ist das auf gleich zwei Ebenen: zum einen, weil es die durch die DevOps-Community wabernden Buzzword-Wolken treffend persifliert, zum anderen weil in dem ganzen Wortsalat einige sehr scharfe Abrechnungen mit häufigen Umsetzungs-Fehlern versteckt sind. "DevOps is a mindset - you build it, you run it. Now you're bad at building and running it." Soll tatsächlich so vorkommen.

Vibe Coding-Prototypen statt Anforderungsdokumente

Über die Folgen des Einsatzes künstlicher Intelligenz in der Softwareentwicklung konnte man in den letzten Jahres einiges lesen, das meiste allerdings mit wenig Realitätsbezug. Das heisst aber nicht, dass es keine sinnvollen Anwendungsfälle gäbe, im Gegenteil. Nach und nach werden sie erkannt, ausprobiert, bewertet und veröffentlicht, so wie in diesem Fall: dem Einsatz von Vibe Coding-Prototypen statt Anforderungsdokumenten bei Google.

At @Google, we are moving from a writing‑first culture to a building‑first one.

Writing was a proxy for clear thinking, optimized for scarce eng resources and long dev cycles - you had to get it right before you built.

Now, when time to vibe-code prototype ≈ time to write PRD,…

— Madhu Guru (@realmadhuguru) July 29, 2025

Zum Kontext: Anforderungsdokumente (oder Product Requirements Documents/PRDs) sind in der Softwareentwicklung bisher ein notwendiges Übel. Sie sind abstrakt, können missverstanden werden und sind aufwändig in der Erstellung und Aktualisierung. Allerdings müssen Anforderungen irgendwo festgehalten werden, Inhalt, Intention und Kontext sind meistens zum umfangreich um ohne derartige Unterstützung im Gedächtnis zu bleiben.

Madhu Garu, der für Gemini zuständige Produktmanager bei Google, beschreibt im oben eingebetteten Post ein alternatives Vorgehen: anstelle eines Anforderungsdokuments präsentiert ein Produktmanager seinem Team einen digitalen Prototypen, also ein noch unfertiges, nicht integriertes und ggf. fehlerhaftes Stück Software, das aber die gewünschte Funktion bereits in einer so guten Form enthält, dass ein Entwicklungsteam sie nachbauen kann.

Dass Produktmanager oft nicht selbst programmieren können wird dabei umgangen, indem der Prototyp durch Vibe Coding erstellt wird, also dadurch, dass er einem KI-Programm beschrieben wird, das ihn dann programmiert (mehr dazu hier). Die Anforderung wird durch den Prototypen deutlich plastischer als durch eine blosse Beschreibung in textform, und (und jetzt wird es interessant) ist im Vergleich zu einem Anfoderungsdokument oft schneller zu erstellen.

Garu geht in den Kommentaren unter seinem Post noch auf weitere Aspekte des Vorgehens bei Google ein: so wird es auch dort nicht überall eingesetzt, bzw. vorgeschrieben, sondern nur dort, wo der Produktmanager es beherrscht und für sinnvoll hält, ob weitere Teams es übernehmen entscheiden sie selbst, Vibe Coding-Prototypen werden nicht auf Produktion deployed und für grössere oder abstraktere Themen ist weiterhin die Schriftform Standard.

Insgesamt eine spannender Erfahrungsbericht von einem Unternehmen, das schon mehrfach bewiesen hat, agile Entwicklungspraktiken zu beherrschen. Sowohl die Art des Einsatzes als auch die Art der Einführung dürften erkennbar dazu beitragen, dass die Kommunikation effektiver, das Feeback schneller und die Lieferzyklen kürzer werden. Eine empfehlenswerte Inspiration also, die man auch im eigenen Unternehmen bei Gelegenheit ausprobieren sollte.

Kommentierte Links (CXXVIV)

Grafik: Pixabay / Brian Penny - 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.

Emily Webber: The Scaling Teams checklist

Checklisten für die Skalierung von Entwicklungsorgseinheiten gibt es viele, sowohl als alleinstehende Werkzeuge als auch als Teil von Skalierungs-Frameworks (looking at you, SAFe). Diese hier von Emily Webber und Jamie Arnold ist also nichts grundsätzlich Neues, hat aber eine nützliche Erweiterung: die einzelnen Abschnitte sind mit Wenn-Dann-Bedingungen verbunden und zeigen so Abhängigkeiten auf.

David Pereira: Why Fail Fast Culture Doesn’t Fly In Most Places

"Fail early, fail often" oder das in seiner Bedeutung ähnliche "Move fast and break things" sind populäre Mantras in der agilen Bewegung. David Pereira weist darauf hin, dass das zwar grundsätzlich richtig ist, aufgrund der Stigmatisierung des Begriffs "Scheitern" aber nur schwer umzusetzen. Und er weist darauf hin, dass der Zweck des Scheiterns (das schnelle Lernen) auch anders zu erreichen ist.

Jenny Wanger: Product ops without permission

Die Ratschläge, die Jenny Wanger hier verfasst, sind zwar auf die Einführung von Product Operations ohne offiziellen Auftrag ausgerichtet, lassen sich aber auch auf andere Vorgehensmodelle übertragen (Agile without permission, DevOps without permission, etc). Ihre Kernbotschaft: die einzelnen Elemente lassen sich auch ohne Methoden-Label einführen, einfach weil sie Sinn ergeben und Mehrwert stiften. 

Falk Steiner: 20 Jahre unbemerkt - Programmierfehler sorgt für fehlende Lehrer.

Mal wieder ein bemerkenswertes Beispiel für die potentiell weitreichenden Folgen defekter Software: 20 Jahre lang wurden freiwerdende Lehrerstellen trotz vorhandenem Budget nicht besetzt. zuletzt waren es über 1400. Falk Steiner gelingt es dabei, die Ursachen und Wechselwirkungen nachvollziehbar zusammenzufassen. So ist es zwar weiter unglaublich, aber wenigstens nachvollziebar.

Maarten Dalmijn: If You're Using AI to Generate Requirements or User Stories You're Completely Missing the Point.

Zuletzt noch ein Link zu einem KI-Thema, bzw. zu einem anschaulichen Fall für eine falsche Art sie einzusetzen. Wie Maarten Dalmijn richtig schreibt: wenn man künstliche Intelligenz einsetzt um Vorgänge zu beschleunigen, die nicht der Engpass des Gesamtsystems sind, dann wird die Gesamtleistung dieses Systems nicht verbessert sonden verschlechtert. Damit ist niemandem geholfen.

Law of the second floor

Bild: Public Domain Pictures / Petr Kratochvil - CC0 1.0

Einige der "Gesetze", in denen Zwangsläufigkeiten und Regelmässigkeiten grosser Organisationen beschrieben werden, haben es in den letzten Jahrzehnten zu grösserer Bekanntheit gebracht, etwa Conway's Law oder Goodhart's Law. Heute soll es aber um eines der weniger bekannten gehen. Gefunden habe ich es im Blog des Agilen Otter, und es trägt den Namen TheLaw of the Second Floor, sinngemäss übersetzbar mit Das Gesetz der zwei Stockwerke.

Nobody two levels ABOVE OR BELOW you on the org chart really knows what your days are like

Law of the second floor

Auch das sinngemäss ins Deutsche übersetzt: niemand, der in der Hierarchie zwei Ebenen über oder unter Dir ist, weiss womit Du Deine Arbeitszeit verbringst. Dass diese "Gesetzmässigkeit" (bei der es sich eigentlich um eine häufig zu machende Beobachtung handelt) dann Gesetz der zwei Stockwerke heisst, liegt in der Gleichsetzung von Hierarchieebene und Stockwerk begründet, die sich tatsächlich in vielen Unternehmen so wiederfindet.

Wie alle Beobachtungen ist auch die, auf der das Gesetz der zwei Stockwerke beruht, erst einmal wertneutral, allerdings ist implizit bereits die Bewertung enthalten, dass die Unkenntnis der Situation des jeweils anderen zu suboptmalen Ergebnissen führen wird - in Ermangelung eines genauen Wissens werden Annahmen getroffen, die zu einem gewissen Anteil falsch sind, was wiederum dazu führt, dass darauf beruhende Anweisungen oder die Reaktionen auf diese es ebenfalls sind.

Ein scheinbar naheliegender Verbesserungsansatz wäre es, dieses Problem an seiner Wurzel zu behandeln, indem man allen Beteiligten die Situation der jeweils anderen nachvollziehbar macht. Das ist aber schwer bis unmöglich - unten in der Hierarchie sind Detailgrad und Focus hoch, oben ist der Detailgrad gering und an Stelle eines thematischen Focus tritt eine breite, abstraktere Sicht. In beiden Fällen sind Kontext, Terminologie, etc. hochgradig spezifisch und z.T. gegenläufig.¹

Versucht wird das trotzdem immer wieder, z.B. durch Mitarbeiter-Befragungen, Veröffentlichungen im Intranet, Townhall-Meetings und weitere Formate. Mehr als ein bestenfalls oberflächliches Verständnis entsteht dabei aber selten, alleine aufgrund des damit verbundenen Kommunikations- und Lernaufwandes, der den Beteilgten in der Regel unverhältnismässig erscheint und für den in den meisten Fällen auch gar nicht genug Zeit zur Verfügung steht.

Alleine diese Erkenntnis kann, wenn sie allgemein geteilt wird, zu deutlichen subjektiven und systemischen Verbesserungen führen. Zum einen, weil es die Annahmen und Erwartungshaltungen gegenüber anderen Personen realistischer macht, zum anderen dadurch, dass niemand mehr (irrigerweise) glaubt, im Zweifel bereits alles zu wissen, was für eine Entscheidung notwendig ist. Die gemeinsame Arbeit an übergreifenden Zielen kann dadurch deutlich erleichtert werden.

¹Während z.B. unten Detail-Kenntnisse für die meisten Jobs entscheidend sind, ist es auf der oberen Ebene aus Zeitgründen wichtig, Details eher zu vermeiden

Wie der Staat wieder handlungsfähig wird (III)

Bild: Wikimedia Commons / Anton Heiz - CC BY-SA 4.0

Unter den vielen Berichten über sich verzögernde Infrastruktur-Projekte ist dieser hier kaum aufgefallen: der Bau des Fehmarnsundtunnels (Teil der Fehmarnbelt-Querung) dauert mindestens drei Jahre länger als geplant. Auffällig dabei ist, dass ein Grossteil dieser Verspätung nicht etwa durch Probleme beim eigentlichen Bauvorhaben entsteht (das hat noch gar nicht begonnen), sondern durch Bürokratie: Ausschreibungsprozesse, zu beachtende Fristen, Einspruchsverfahren, Klagemöglichkeiten, etc.

Der Fehmarnsundtunnel ist dabei kein Einzelfall: wer mit Bauträgern und Behördenvertretern spricht bekommt zahllose derartige Geschichten zu hören, bei denen das eigentliche Vorhaben mehr oder weniger im Plan liegt, bei denen aber bürokratische Vorgaben immer wieder zu verzögertem Start oder zwischenzeitlichen Unterbrechungen führen - und das nicht etwa durch Behördenwillkür, sondern nur weil auch die sich an Gesetze und Vorschriften halten müssen.

Wie sehr es tatsächlich die Verwaltungsbürokratie ist, die alles verlangsamt, kann man an einem anderen Beispiel sehen. den LNG-Flüssiggas-Terminals, die ab dem Jahr 2022 an der Nord- und Ostseeküste gebaut wurden. Für deutsche Verhältnisse sind sie in atemberaubender Geschwindigkeit fertig geworden, zum Teil lag zwischen dem Beschluss des Vorhabens und dem Ende der Bauarbeiten weniger als ein Jahr. Und man kann jetzt bereits ahnen, wie das gelungen ist.

Das für diesen Zweck erlassene "Gesetz zur Beschleunigung des Einsatzes verflüssigten Erdgases" (LNG-Beschleunigungsgesetz) macht fast ausschliesslich Eines: es setzt andere Gesetze und Vorschriften ausser Kraft. Formulierungen wie "Abweichend von § X ..." oder "§ Y des Gesetzes Z ist nicht anzuwenden" ziehen sich durch seinen gesamten Text und machen deutlich klar, dass hier ein subtraktiver Wandel stattfindet. Mit anderen Worten: Verbesserung durch Weglassen.

Natürlich heisst das nicht, dass alle bisherigen Gesetze und Vorschriften sinnlos sind und abgeschafft werden sollten, derartige Kettensägen-Methoden gehören (wenn überhaupt) in ganz bestimmte Sektoren der Privatwirtschaft, die entfesselnde Wirkung eines Regulierungs-Rückbaus ist aber an diesem Fall mehr als deutlich zu erkennen. Wenn der Staat wieder handlungsfähig werden soll, ist das temporäre oder dauerhafte Ausserkraftsetzen also ein durchaus gangbarer Weg.

Mindestens für kriselnde Vorhaben von gesamtwirtschaftlicher Bedeutung, so wie die wie die Fehmarnbelt-Querung eines ist, könnte man die Erlassung von deregulierenden Beschleunigungs-Gesetzen zu einer der standardmässig zu erwägenden Optionen machen. Und wenn man in diesem Zusammenhang feststellen kann, welche anderen Vorgaben besonders verlangsamend sind, hätte man auch gleich eine Idee wo dauerhafte Abschaffungen oder Reformen Sinn machen könnten.

Das Effektivitäts-Framework von Tesla und SpaceX

Bild: CCNull / Marco Verch - CC BY 2.0

Es dürfte nur wenige Personen geben, deren Image sich in wenigen Jahren so stark gewandelt hat wie das von Elon Musk - vom ökologisch-liberalen Hoffnungsträger zum techno-faschischen Oligarchen. Was dabei in Vergessenheit zu geraten droht ist, dass Musk in seinen Unternehmen vieles umgesetzt hat, was aus "agiler Perspektive" als vorbildhaft gilt.Dazu gehört unter anderem auch das fünfstufige Effektivitäts-Framework von Tesla und SpaceX, der u.a. in seiner autorisierten eponymen Biografie beschrieben ist.

pic.twitter.com/EbATALczdf

— Startup Archive (@StartupArchive_) July 20, 2025

 

1. Question every requirement (make them less dumb)

Die konsequente Umsetzung dessen, was auch als maximizing the amount of work not done bekannt ist. Wichtig dabei ist als Voraussetzung, dass Anforderungen immer einer Person zuzuordnen sein müssen, bei der man sie hinterfragen kann. Und ebenfalls, dass dieses Hinterfragen nicht nur als Legitim sondern als sinnvoll und gewünscht wahrgenommen wird, da jedem bewusst ist, dass niemand (egal wer er ist) davor gefeit ist, Fehler zu begehen - und zwar auch dumme Fehler.

 

2. Delete as much process as possible - even if it is too much

Ein Grundsatz, der seit Musks Kettensägen-Bürokratieabbau sicher kritischer gesehen werden muss, der aber einen rationalen Kern hat: von vielen (Umsetzungs-)Prozessen weiss man erst ob sie verzichtbar sind, wenn man durch ihre vollzogene Abschaffung getestet hat ob sie fehlen würden - andernfalls wird sich immer jemand finden, der sie verteidigt (im Zweifel der, dessen Job die Prozess-Aufrechterhaltung ist). Und wenn sie wirklich fehlen, kann man sie ja erneut einführen.

 

3. Simplify and optimize

Ab hier wird das Vorgehen dem ähnlicher, das aus Scrum, Kanban & Co bekannt ist. Wichtig ist dabei aber, dass zuerst die beiden ersten Schritte durchgeführt worden sind, um zu verhindern, dass unsinnige Anforderungen umgesetzt oder sinnlose Prozesse optimiert werden. Ein bekanntes Beispiel für die danach folgende Vereinfachung und Optimierung sind die Fertigungsstrassen der neuen Tesla-Fabriken, die erst in Zelten gebaut und optimiert werden, bevor die (teure) Fabrik um sie herum gebaut wird.

 

4. Accelerate cycle time

Sobald ein Fertigungs- oder sonstiger Arbeitsprozess grundlegend eingerichtet ist kann er in seinem Ablauf beschleunigt werden, z.B. indem Arbeitspakete kleiner geschnitten werden, Kopfmonopole aufgelöst werden oder Routinen entwickelt werden. Das Ganze idealerweise auf Basis von Daten wie Durchlaufzeiten, Qualitätsschwankungen oder Abnutzungsraten. Und auch hier gilt: die vorherigen Schritte müssen vorher stattgefunden haben, sonst riskiert man, etwas Falsches zu beschleunigen.

 

5. Automate

Dass die Automatisierung von Prozessschritten erst ganz am Ende erfolgt, hat einfache Gründe: sie ist kostspielig, und sollte daher erst stattfinden, wenn möglichst klar ist, dass das was automatisiert wird wirklich sinnvoll und effektiv gestaltet ist. Und sobald die Automatisierung stattgefunden hat, sind die Anforderungen und Abläufe der Sichtbarkeit der Menschen entzogen, und damit auch dem kritischen Hinterfragen. Frei nach Thorsten Dirks: automatisierte Scheissprozesse sind zu vermeiden.

 

Wie oben gesagt, spätestens Elon Musks Tätigkeit für die US-Regierung, in der sich sein Effektivitäts-Framework wiedererkennen lässt, hat aufgezeigt, dass es nicht in jeden Kontext übertragen werden kann oder übertragen werden sollte. Gleichzeitig hat es seine Unternehmen aber unbestreitbar erfolgreich gemacht, bis hin zu zeitweisen Quasi-Monopolen auf ihren Märkten. Wie so oft gilt daher auch hier: bitte nicht unhinterfragt kopieren, sondern zuerst kritisch bewerten. Z.B. mit den eigenen Schritten 1 bis 3.

Flight Levels

Eine Gemeinsamkeit praktisch aller bekannten agilen Vorgehensmodelle ist, dass sie aus Amerika kommen und auch von dort angesiedelten Zertifizierungs- und Standardisierungs-Organisationen verantwortet und weitwerentwickelt werden. Es gibt aber Ausnahmen von dieser Regel, und eine davon kommt sogar ursprünglich aus dem deutschsprachigen Raum: die Flight Levels, entwickelt von Klaus Leopold aus der österreichischen Hauptstadt Wien.

 

Die zugrundeliegende Idee ist zunächst einfach: es wird davon ausgegangen, dass sich alle Arten von Arbeit, die in grossen Organisatinen durchgeführt werden, einem von drei Flight Levels (Flug-Höhen) zuordnen lassen. Operative Arbeit bildet das unterste Flight Level 1, teamübergreifende Koordination (möglichst End to End) das mittlere Flight Level 2, Strategie-Entwicklung und organisationsweite Zielsetzungen finden auf dem oberen Flight Level 3 statt.

 

Wichtig dabei ist, dass diese drei Flughöhen nicht (!) mit Hierarchieebenen verknüpft, bestimmten Organisationseinheiten zugeordnet oder auf eine andere Art und Weise geschützt oder exklusiv gehalten sind. Stattdessen kann und soll hierarchie- und einheitsübergreifend jeder eingebunden werden können, der zu einem Thema etwas beitragen kann, unabhängig davon wo in der Organisation er fachlich oder disziplinarisch verortet ist. 

 

Wie Vieles andere, das in der agilen Bewegung entstanden ist, ist diese Idee keine komplette Neuentwicklung, sondern findet sich in ähnlicher Form bereits an anderen Stellen, z.B. im St. Gallener Management-Modell. In der agilen Methodenwelt haben die Flight Levels aber eine spezielle Lücke finden und schliessen können: die der fehlenden Kanban-Skalierungsframeworks. Ursprünglich sind sie auch als Ergänzung des "Lehrstoffs" der Kanban University entstanden und wurden erst später eigenständig.¹

 

Dieser initiale Kanban University-Hintergrund ist auch die Erklärung dafür, dass die mit den Flight Levels verbundenen fünf Praktiken jedem Anwender von Wissensarbeits-Kanban bekannt vorkommen dürften. Es handelt sich um:

- Die Situation visualisieren
- Fokus setzen
- Agile Interaktionen durchführen
- Veränderungen messen
- Die Strukturen und Abläufe verbessern

Alles in allem also um einen kontinuierlichen Visualisierungs- und Verbesserungsprozess der Wertschöpfung, wie er für Kanban typisch ist.

 

Ebenfalls erkennbar aus Kanban übernommen ist der bewusste Verzicht auf einen formellen Rahmen aus vorgegebenen Rollen, Meetings und Vorschriften, an dessen Stelle der bewusste Start mit dem bestehenden Ist-Zustand tritt, der dann nach und nach optimiert werden kann. Daraus erklärt sich dann auch die Selbstbeschreibung als blosser "Denkansatz", der in bewusstem Kontrast zu den im Vergleich formalisierteren Ansätzen wie SAFe oder Scrum steht.

 

Interessant ist dabei, dass es ab der Trennung von der Kanban University (ca 2020) doch zu einer stärkeren Ausdifferenzierung und Vergrösserung der Flight Levels-Idee gekommen ist. Zwar nicht durch Meetings und Rollen, aber durch Erweiterungen wie die "Flight Items" genannten Arbeitspakete, die auf "Flight Routes" durch die Flight Level systeme fliegen, deren Analyse und Design zum Gegenstand von Werkzeugen und Praktiken wie z.B. der "Work Systems Topology" wird.

Im Zusammenhang damit sind schliesslich auch für die Flight Levels die für die agilen Frameworks typischen mehrtägigen Workshops entstanden, an deren Ende man sich einen farbigen Badge in den Lebenslauf einfügen kann, etwa "Flight Levels Professional" oder "Flight Levels System Architecture". Auf den Begriff der Zertifizierung wird dabei zwar bewusst verzichtet, die Art der Nutzung in Lebensläufen und Ausschreibungen ist aber sehr vergleichbar.

Trotz dieser offensichtlichen Gewinnerzielungsabsicht (die für sich genommen auch nicht verwerflich ist) hat sich Flight Levels in weiten Teilen der agilen Community bisher den Ruf eines irgendwie anderen, noch nicht komplett kommerzialisierten Vorgehensmodells erworben, nicht zuletzt wegen seines charismatischen Gründers Klaus Leopold, der es geschafft hat sich als einer der wenigen deutschsprachigen "agilen Thought Leader" zu etablieren.

Ob man damit tatsächlich etwas anfangen kann, liegt am Ende bei den eigenen Präferenzen. Wer offene Ansätze wie Kanban mag wird auch Flight Levels mögen, wer Wert auf stützende Rahmenbedingungen legt, wird eher mit den stärker aufformulierten Frameworks glücklich werden. Und wer aus der technischen Dimension der Agilität kommt wird den Ansatz mit freundlichen Interesse betrachten, ihn aber vor allem wegen seines Prozess-Minimalismus mögen. Jeder wie er mag.

 

¹Seit ca 2015 in Büchern und Lehrmaterial zu finden

Das morphende Daily

Bild: Unsplash / Carine L. - Lizenz

Es ist eine der klassischen Fragen, mit denen sich jede grössere Organisation früher oder später beschäftigt - wie schaffen wir es, dafür zu sorgen, dass mehrere zusammenarbeitende Teams unbürokratisch die notwendigen Informationen untereinander austauschen können? Formate dafür gibt es viele, vom Scrum of Scrums über die Gilde und die Community of Practice bis zur Management- oder Spezialisten-Abstimmung. Eines ist aber erstaunlich unbekannt - das morphende Daily.

Die Grund-Idee, die dieses Format von fast allen anderen unterscheidet, ist, dass kein zusätzliches Meeting eingerichtet wird, in dem die einzelnen Teams in Gänze oder durch Vertreter zusammenkommen. Stattdessen werden lediglich die normalen Daily-Termine der Einzelteams abgehalten, mit nur einer einzigen Besonderheit: sie finden sequenziell nacheinander statt, und zwar in ein und demselben (physischen oder digitalen) Raum.

Stellen wir uns der Einfachheit halber ein Projekt mit vier Teams vor. Von denen hält das erste sein Daily-Meeting um Neun Uhr ab, das zweite seines um Viertel nach Neun, das dritte um Halb Zehn, das vierte um Viertel vor Zehn (es sind also die agil-typischen 15 Minuten). Und wie es in vielen agilen und nicht-agilen Teams üblich ist, sind diese Meetings öffentlich - jeder der interessiert ist kann zu Besuch kommen, solange er nicht ablenkt, stört oder die Abläufe durcheinanderbringt.

Wie in diesem Szenario die einfachste Form der Informationsübermittlung aussehen könnte, erschliesst sich sofort - jedes Team kann einfach eines oder mehrere Mitglieder bestimmen, die während der gesamten (und mit einer Stunde noch recht überschaubaren) Dauer im Raum bleiben, den jeweils anderen Teams für Fragen zur Verfügung stehen und gegebenenfalls darauf aufmerksam machen können, was aus dem eigenen Team für die anderen relevant sein könnte.

Eine etwas strukturiertere, aber noch immer einfache Variante kann daraus bestehen, dass ein Team einem oder mehreren der anderen im Voraus übermittelt, welches von deren Mitgliedern es gerne am jeweiligen Tag als Gast bei sich haben würde. Das kann z.B. der Spezialist für ein bestimmtes Thema sein (der UX Designer, der Tester, etc.), zu dem aktuell von Abstimmungsbedarf ausgegangen wird. Ggf. kann er im Daily seines eigenen Teams auch bereits Vorklärungen vornehmen.

Auch für übergreifende Rollen, wie Projektleiter, Architekten, Kundenvertreter oder sonstige Stakeholder kann dieses Format geeignet sein. Alleine dadurch, dass sie während der Dailies im Raum bleiben, sind sie über alles Wesentliche aus allen Teams im Bilde, vom Arbeitsfortschritt über aktuelle Probleme bis zu zu klärenden Punkten. Und je nach Rolle können sie sich auch selbst daran beteiligen, z.B. dadurch, dass sie selbst das letzte der aneinandergereihten Dailies durchführen.

Ich habe dieses Vorgehen in verschiedenen Projekten mit bis zu acht Teams erlebt, und es hat in allen einen einfachen Informationsaustausch ohne zusätzliche Abstimmungs- und Koordinationsmeetings ermöglicht (zumindest auf Tagesbasis, wöchentliche oder monatliche Planungs- und Review-Termine sind nochmal ein eigenes Thema, selbst wenn man oft auch sie nach einem vergleichbaren Muster aufeinanderfolgend abhalten kann).

Ein spannendes Phänomen ist dabei, dass es nach einiger Zeit dazu kommen kann, dass die Grenzen zwischen den Dailies der Teams sich auflösen. Vor allem wenn es gelingt, dass Teams mit tendenziell grösseren Berührungspunkten direkt aufeinanderfolgen, kann es an den Schnittstellen zu kurzen Abstimmungen und Übergaben kommen, so dass ein fliessender Übergang ohne klare Grenzen entsteht, das morphende Daily eben, das durchgehend fortläuft und bei dem sich nur die Teilnehmer verändern.

Natürlich wird dieses Format nicht in jedem Kontext passen, und man sollte sich auch bewusst machen, dass bestimmte Voraussetzung zwingend erforderlich sind, etwa die Fähigkeit sich kurz zu fassen und auf das Wesentliche zu beschränken, oder die Fähigkeit auch in diesen kurzen Terminen auf unerwartete Entwicklungen einzugehen, selbst wenn der ursprüngliche Plan etwas anderes vorgesehen hat, das dann ggf. bis zum nächsten Tag warten muss.

Für alle, denen etwas daran liegt, dass mehrere zusammenarbeitende Teams unbürokratisch und ohne zusätzliche Meetings Informationen austauschen und Abstimmungen vornehmen können, ist ein morphendes Daily aber etwas, das man auf jeden Fall ausprobieren sollte, und das man möglicherweise bald so gut finden wird, dass man nicht mehr darauf verzichten möchte.

Now we've given them every freedom and they still don’t do what we want

Ich freue mich immer wenn ich auf jemanden verweisen kann den ich kenne, in diesem Fall auf Michael Mahlberg, bzw. auf seinen wie immer hörenswerten Vortrag auf der Konferenz Agile Meets Architecture 2025, der den wirklich schönen Titel trägt "Now we've given them every freedom and they still don’t do what we want".

Inhaltlich beleuchtet er die Rahmenbedingungen und der Führungsstile, deren Verständnis nötig ist, um zu wissen, wie man selbstorganisierten Teams eine Umgebung schafft, in der sie motiviert arbeiten und möglichst grosse Wirkung haben können (also das tun, was eigentlich jeder in seinem Beruf möchte).

Stakeholder

Bevor es losgeht muss ich mich kurz entschuldigen, und zwar für das Symbolbild auf dieser Seite. Aber was soll ich sagen, nach all den Jahren, in denen ich den Begriff so oft falsch geschrieben gesehen habe - es gibt Gags, die muss man mitnehmen. Aber genug davon, werden wir seriös. Wer irgendwo im agilen oder nicht agilen Produkt- und Projektmanagement unterwegs ist, wird an dieser Stelle bereits ahnen, um was es heute geht - die Stakeholder, wer sie sind und was sie tun.

 

Der Begriff ist natürlich nicht abgeleitet von dem Steak, sondern von dem Stake, einem dieser unglaublich vieldeutigen englischen Worte. Es kann (Wett-)Einsatz, Beteiligung, Wagnis, Risiko, Anteil oder Interesse bedeuten,¹ und wird in der Wirtschafts-Literatur häufig als "Interessenvertreter" übersetzt. Das ist generisch genug um jede mögliche Person oder Gruppen einzuschliessen, aufgrunddessen aber auch sehr vage. Es macht daher Sinn konkreter zu werden und häufige Stakeholder-Rollen zu beschreiben.

 

Interne Anwender

Die häufigste und offensichtlichste Stakeholder Rolle ist die derjenigen Personen, die ein Produkt benutzen sollen oder es bereits tun. Der Untertyp der internen Anwender arbeitet dabei im selben Unternehmen, das das Produkt auch entwickelt. Er ist damit ansprechbar und bekannt, kann aber oft zur Nutzung gezwungen werden, was die Beziehung zu ihm tendenziell einseitig gestaltet.

 

Externe Anwender

Im Gegensatz zum internen Anwender arbeitet der externe Anwender nicht im selben Unternehmen, das das Produkt entwickelt. Er kann durch seine Nutzungs- und ggf- Kaufentscheidung (bzw. durch seine Entscheidung, etwas nicht zu nutzen) sehr viel stärkeren Einfluss auf die Produktentwicklung nehmen, ist der Entwicklungsorganisation dafür aber vor allem aus der (fehleranfälligen) Marktforschung bekannt.

 

Käufer

Eine häufig vergessene, dafür aber sehr einflussreiche Stakeholdergruppe. Grosse Firmenanwendungen wie ein CMS, ein CRM oder ein ERP werden praktisch nie von den eigentlichen Anwendern eingekauft, sondern fast immer von einer zentralen Organisationseinheit, die oft andere Interessen hat als nur die Nutzerfreundlichkeit. Zum Beispiel einen niedrigen Einkaufspreis.

 

Verkäufer

In gewisser Weise das Gegenstück zum Einkäufer, im Gegensatz zu diesem aber in den meisten Entwicklungsorganisationen deutlich präsenter und einflussreicher. Klassische Interessen von Verkaufs-Abteilungen sind regelmässige neue Funktionen, das Einbauen von Sonderwunsch-Features ihrer Kunden und Vorführ-geeignete Showeffekte des Produkts.

 

Eigentümer

Mit dem Eigentümer ist hier der Inhaber der Firma gemeint, durch die das jeweilige Produkt entwickelt wird. Häufig ist der Eigentümer auch der Gründer, bzw. einer seiner Nachkommen. Immer wieder anzutreffen sind dabei die "kleinen Könige", die es gewohnt sind widerspruchslos zu führen, auf der anderen Seite aber auch sehr sozial eingestellte Menschen, denen familiäre Verhältnisse wichtig sind.

 

Inverstoren/Risikokapitalgeber

Vor allem im Startup-Umfeld anzutreffen, zum Teil aber auch in der Variante, dass älteren innovativen Unternehmen der nächste Wachstumsschritt ermöglicht wird. Das investierte Geld soll bei ihnen nicht sofort Rendite abwerfen, sondern sich eher mittelfristig vermehren - dann aber auch richtig. Zentrale Anliegen sind die Förderung von Innovation und der Aufbau skalierbarer Stukturen.

 

Shareholder

Wie der Name es sagt, handelt es sich bei diesen Stakeholdern um Anteilseigner börsennotierter Unternehmen, zum Beispiel Rentenfonds oder Vermögensverwalter. Von ihnen wird meistens ein möglichst stetiges Einkommen bei möglichst geringem Aufwand gewünscht, was in der Entwicklung bedeutet, die Produkte in einen stabilen Cash Cow-Modus zu bringen.

 

Interne Unterstützer/Sponsoren

Im gleichen Unternehmen angesiedelt, das das Produkt entwickelt, kann der interne Unterstützer oder Sponsor aus ähnlichen Motiven handeln wie der externe Investor oder Shareholder, kann aber auch politische Motive haben, zum Beispiel das an sich ziehen möglichst prestigeträchtiger Projekte oder das Aufbauen möglichst grosser eigener Entwicklungsmannschaften.

Interne Entwickler

Eine weitere häufig vergessene Stakeholder-Gruppe sind die internen Entwickler, also die, die das Produkt selbst bauen, testen und ggf. betreiben. Ein häufiges (und zu vielen anderen Stakeholdern gegenläufiges) Interesse ist die Investition von Zeit und Aufwand in Infrastruktur, Abbau technischer Schulden, Modernisierung, etc. Ein häufiges Problem ist, dass die Sinnhaftigkeit dessen nicht gut vermittelt wird.

 

Externe Entwickler

Egal ob einzelne Freelancer oder ganze Dienstleister-Teams - viele Entwickler sind nicht intern fest angestellt sondern "gemietet". Das kann zu sehr stark ausgeprägten Egoismen führen, von der Maximierung der "billable Hours" bis hin zum "Resume-driven Development", andererseits aber auch zu im Vergleich höheren Qualitätsansprüchen, um durch gute Arbeit eine Wiederbeauftragung zu sichern.

 

Interne Entwicklungspartner

Interne Entwicklungspartner sind im Einfachsten Fall andere Entwicklungs-Einheiten, mit denen man sich Produkte, Systeme, Kunden oder Vorgesetzte teilt. Im Fall ständig weiterentwickelter Produkte kommen ggf. auch solche dazu, die den Betrieb übernehmen, die für Support und Kundenservice zuständig sind oder die mit Hilfe des Produkts selbst eine Dienstleistung für einen Kunden erbringen.

 

Externe Entwicklungspartner

Externe Entwicklungspartner können kooperierende andere Firmen sein, die ein ihnen geliefertes (Teil-)Produkt in ihre eigenen Produkte integrieren (z.B. ein Betriebssystem in eine Hardware), es können aber auch solche sein, die selbst vorgefertigte Teilprodukte zuliefern, oder Open Source-Communities (wenn Teile des Produkts unter einer entsprechenden Lizenz erstellt werden).

 

Interne Regulierer

Zu diesen Stakeholdern können sehr unterschiedliche Personenkreise gehören, deren Gemeinsamkeit es ist, den Entwicklungseinheiten Vorgaben machen zu können. Die Software Architekten gehören etwa dazu, die Rechtsabteilung oder die Abteilung die das Corporate Design verantwortet. Je nach Einzelfall können zahlreiche weitere dazukommen.

 

Externe Regulierer

Im Wesentlichen verschiedene Gesetzgebende oder Gesetze durchsetzende Behörden. Das können auf internationaler Ebene untergeordnete Behörden der Europäischen Union, auf nationaler Ebene die Bundesanstalt für Finanzdienstleistungsaufsicht oder die Bundesnetzagentur, auf Landesebene der Landesdatenschutzbeauftragte, etc. etc. Sie alle können verbindliche Vorgaben erlassen und überprüfen.

 

Interne Anspruchsteller

Eine schwächere Variante der internen Regulierer. Anders als diese können sie zwar keine Verbindlichen Vorgaben machen, können aber auf Selbstverpflichtungen des Unternehmens aufmerksam machen und durch Thematisierungen in grösseren Runden Druck machen. Beispiele dafür wären die Gleichstellungs- und Nachhaltigkeitsbeauftragten.

 

Externe Anspruchsteller

Zu diesen Stakeholdern gehören zivilgesellschaftliche Gruppen jeglicher Art, etwa solche die Jugendschutz oder Umweltschutz als Ziel haben. Auch ihnen steht zwar kein unmittelbares Druckmittel zur Verfügung, durch Kauf- oder Boykottaufrufe, Demonstrationen, Öffentlichkeitsarbeit und ähnliche Massnahmen können sie aber durchaus Einfluss nehmen.

 

Wettbewerber

Nochmal eine Gruppe, an die man nicht sofort denkt, dabei eine durchaus einflussreiche. Durch Feature-Wettrennen, Copycat-Produkte, Preiskämpfe, besseres Design oder höhere Qualität können sie eine Entwicklungsorganisation beeinflussen und von ihr beeinflusst werden, wodurch sie definitiv die Kriterien erfüllen um zu den Stakeholdern zu gehören.

 

Geschäftspartner

Zu diesen letzten hier genannten Stakeholdern gehören alle, die zwar eigenständige Unternehmen sind, trotzdem aber zum Erfoolg eines Produkten beitragen können oder müssen. Das können Reparatur- und Vertriebspartner sein, Händler, Logistiker, Messeveranstalter, Werbeagenturen, Influencer, Reseller und noch zahlreiche weitere.

 

Und viele mehr ...

Diese Übersicht ist bereits lang, sie könnte aber vermutlich noch beliebig verlängert werden. Am Ende ist schliesslich auch die Anzahl potentieller Interessen an einem Produkt tendenziell unendlich, und damit auch die Anzahl der Interessenvertreter, bzw. der Stakeholder. Und genau wie Produkte und Märkte können auch Stakeholder sich ändern, es macht also Sinn, die immer wieder aufs neue zu analysieren, um zu wissen, wer sie sind, und wie man sich auf sie einstellen sollte.

 

¹Aber auch Pfahl, Stab, Stütze, abgegrenzter Bereich, Stollen, Halterung, Daube, Überwachung, Scheiterhaufen und Vieles mehr

Ein Bild sagt mehr als 1000 Worte (XLIX)

 

Kommentierte Links (CXXVIII)

Grafik: Pixabay / Brian Penny - 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.

Itamar Gilad: The Product Operating Model Explained

Seit der Begriff des Product Operating Model 2023 von Marty Cagan eingeführt wurde, gilt es in der Product Management-Community als anzustrebendes Zielbild. Für alle, die die Bücher und Blogposts von Cagan nicht in Gänze durchlesen wollen, hat Itamar Gilad die wesentlichen Punkte zusammengefasst. Praktisch aus meiner Sicht ist dabei vor allem die von ihm entwickelte grafische Darstellung, die einen schnellen und einfachen Zugang ermöglicht.

Liam Kane: An Agile Transformation Dashboard

Apropos grafische Darstellung. Liam Kane hat vier Kernelemente des agilen Arbeitens zu einem Dashboard zusammengefasst, mit dem sich der Fortschritt einer agilen Transformation verfolgen lässt: Agile Practice Adoption, Value Delivery, Team Health und Strategic Outcomes. Wie diese im Detail gemessen werden, kann (und sollte) im Einzelfall angepasst werden, als übergreifende und messbare Kategorien sind sie aber gut geeignet.

Mike Bowler: The big rewrite

Wer etwas Zeit in grösseren IT-Organisationen verbracht hat kennt die Situation, die Mike Bowler hier beschreibt - ein Bestandssystem ist schwer bedienbar, wartbar und weiterentwickelbar, also wird ein Ablöse-Projekt gestartet, dessen einziges Ergebnis ein neues schwer bedienbares, wartbares und weiterentwickelbares System ist. Wo das passiert ist, ist zwar der Code ausgetauscht worden, die Entwicklungspraktiken, die zu seiner schlechten Qualität geführt haben, sind aber geblieben.

Maret Kruve: ADEPT - The Product Discovery Framework that Fits on a Sticky Note

Was ist eigentlich aus der Steuererklärung auf dem Bierdeckel geworden, die uns mal versprochen wurde? Naja, so lange wir sie noch nicht haben nehmen wir stattdessen das Product Discovery Framework, das auf ein Post-It passt, entwickelt von Maret Kruve. Natürlich dient diese Grösse dabei nur dem Erklären der fünf Dimensionen Attractive, Doable, Effective, Practical und Targetable, im Detail ist es etwas grösser, aber immer noch schlank.

Celine Nguyen: The Perils of ‘Design Thinking’

Als letztes ein Longread. Celine Nguyen bespricht zunächst Maggie Gram's Buch The Invention of Design, leitet daraus aber eine grundsätzliche Kritik des Konzepts des Produkt-Designs ab. Nicht in dem Sinn, dass sie es für schlecht erklärt, sondern dahingehend, dass sie seine Begrenzungen und Risiken aufzeigt - vor allem solche, die entstehen, wenn versucht wird, Design Thinking und ähnliche Praktiken ausserhalb der Produktentwicklung anzuwenden.

Agilität, dort wo man sie nicht vermutet (III)

Dass die öffentliche Verwaltung an manchen Stellen agiler ist als man vermuten würde, habe ich schon an der einen oder anderen Stelle geschrieben. Ich muss aber zugeben, dass jeder neue Fall auch mich etwas überrascht, so viele sind es schliesslich auch wieder nicht. Die aktuelle Überraschung tritt dabei an einer besonders prominenten Stelle auf, nämlich in der Bundesregierung, genauer gesagt im neuen Bundesministerium für Digitales und Staatsmodernisierung (BMDS).

Die erste Anwendung agiler Praktiken findet dabei gleich im Rahmen des Organisationsaufbaus statt. Statt möglichst lange möglicht im Verborgenen an einem möglichst perfekten Organigramm zu arbeiten, das dann nicht mehr verändert werden soll, hat das BMDS bewusst einen noch unfertigen Entwurf veröffentlicht, in gewisser Weise ein MVP. Dadurch sollen möglichst viele der zukünftigen Mitarbeiter früh Wünsche und Feedback äussern können, die dann in spätere Versionen einfliessen können.

 

Und damit nicht genug - diese Transparenz und Offenheit für Rückmeldungen soll nicht nur einmal stattfinden sondern mehrfach, das Ministerium plant "die Umsetzung in eine feste Struktur [...] in Form eines iterativen Prozesses", es wird also mehrere Veröffentlichungs-, Feedback- und Ansassungs-Schleifen geben, bis irgendwann ein Organisationsaufbau in einer Form definiert worden ist, die eine zeit lang stabil bleiben kann (so ähnlich habe ich auch schon einmal gearbeitet).

Alleine das ist für eine Behörde bereits beeindruckend genug, bei der Süddeutschen Zeitung kann man aber nachlesen, dass noch weitergehende Organisationsdesign-Prinzipien umgesetzt werden sollen: in einer Abkehr von sonst üblichen Paradigmen sollen die entstehenden Abteilungen nicht in Form von Silos auf Fach- oder Aufgabenteilungs-Basis entstehen, sondern um so genannte "Missionen" gruppiert sein, also um konkrete Modernisierungs- und Digitalisierungs-Aufgaben.

 

Dazu sollen diese neuen Einheiten nicht einfach über längere Zeiträume vor sich hinarbeiten, sondern stattdessen in überschaubaren Zeiträumen kleinere, aber dafür fertige Ergebnisse abliefern. Die Rede ist dabei von "Projekten mit einer Laufzeit von maximal sechs Monaten". Derartige Intervalle wären sogar mit verschiedenen klassischen agilen Praktiken kompatibel, etwa den Objectives aus OKRs oder den Product Goals aus Scrum. Und im Vergleich zu vielen anderen Behörden sind sie bemerkenswert kurz.

 

Eher der Umbruchssituation geschuldet, trotzdem aber bemerkenswert ist der Improvisationsgeist, von dem die Süddeutsche Zeitung berichtet. Statt sich lange mit den in der öffentlichen Verwaltung legendär langwierigen und komplizierten Bestellprozessen aufzuhalten werden Büroausstattungen gebraucht gekauft oder geliehen, unbürokratisch verteilt und bei Bedarf zweckentfremdet. Und noch etwas erinnert mich an ein eigenes Erlebnis: die pragmatische Beschaffung von dringend nötigem Klopapier.

Ob sich der "agile Geist" in diesem neuen Ministerium halten wird, ist natürlich noch nicht absehbar. Bestenfalls wird er in die Organisationskultur übergehen, schlimmstenfalls wird er sich nach und nach verflüchtigen. Aber alleine dass Agilität an einem solchen Ort, an dem man sie nicht vermuten würde, möglich ist, ist schon für sich genommen eine bemerkenswerte Geschichte. Eine die man durchaus weitererzählen könnte, wenn wieder jemand undifferenziert auf Behörden schimpft.

Why We Confuse Building to Learn with Building to Earn

Ich bin ein Fan der Vorträge von Jeff Patton, zum einen wegen der inhaltlichen Tiefe, zum anderen wegen seines besonderen Stils, Life Visualisierungen für seine Ausführungen zu erstellen. In diesem Fall zum Thema des Minimum Viable Product (MVP).

Spannend an diesem Vortrag ist unter anderem, dass er durch die Erläuterung des MVP scheinbare Gewissheiten der agilen Produktentwicklung in Frage stellt, zum Beispiel die Definition of Done - aber nicht etwa, weil er in dieser Idee keinen Sinn sieht, sondern weil er aufzeigen kann, dass sie nur Teile dessen abdeckt, was man unter agil verstehen kann. 

How agile crossed the chasm

Grafik: Wikimedia Commons / Craig Chelius - CC BY 3.0

Die Geschichte der Agilität ist voller Missverständnisse, besonders dann wenn es darum geht, wie das, was wir heute die agile Bewegung nennen, entstanden ist. Das liegt zum Teil einfach daran, dass die "agiler Vor- und Frühgeschichte" der 80er und 90er Jahre mittlerweile schon etwas länger her ist, zum anderen aber auch daran, dass sie sich zu Beginn in den Schatten abgespielt hat, ohne Namen und ohne Bekanntheit. Und an dieser Stelle wird es interessant.

Bevor wir dazu kommen aber kurz zu den beiden verbreitetsten Missverständnissen über die Entstehung des agilen Produkt- oder Projektmanagements: das erste ist, dass sie 2001 in Snowbird, Utah entstanden sind, als dort das Manifest für agile Softwareentwicklung verfasst wurde. Das zweite erkennt zwar an, dass Frameworks wie Scrum, Crystal und XP deutlich älter sind als das Manifest, geht aber davon aus, dass ihre Erfinder erst in Snowbird ihre Gemeinsamkeiten erkannten (und einen Namen dafür suchten).

Dass die Wahrheit nochmal anders geartet war, kann man im Podcast The Pragmatic Engineer erfahren, genauer gesagt in der Episode TDD, AI agents and coding, in der Kent Beck zu Gast ist, der Erfinder von XP (Extreme Programming) und der erste Unterzeichner des agilen Manifests. Neben XP-Praktiken und seinen Erfahrungen mit dem Einsatz von künstlicher Intelligenz teilt er auch Geschichten rund um die Verfassung des besagten Manifests, unter anderem, das dieses einem bestimmten Zweck diente.

Und damit kommen wir zurück zur Zeit, in der die agile Bewegung keinen Namen und keine Bekanntheit hatten, denn laut Beck sollte die Zusammenkunft in Snowbird genau das ändern. Es war nämlich kein gegenseitiges Kennenlernen, das dort stattfand (fast alle Beteiligten kannten sich bereits) und auch kein Erarbeiten von Gemeinsamkeiten (das war bereits früher passiert, u.a. bei einer gemeinsamen Hurtigruten-Kreuzfahrt einiger Teilnehmer). Es ging um Marketing und Brand Building.

Die angehenden Verfasser des agilen Manifests waren sich bewusst, dass sie bereits über eine kleine aber treue Gruppe von Anhängern verfügten, der Grossteil ihrer Zielgruppe (Software-Entwickler und IT-Manager) aber noch nicht bereit war, sich auf die neuen Arbeitsweisen einzulassen. In Anlehnung an das Technology Adaption-Modell aus dem Buch Crossing the Chasm suchten sie nach einem Weg, um die Lücke zwischen den ersten Anhängern und der Mehrheit der Anwender zu überwinden.

"Agile" oder die anderen in Snowbird erwogenen Namen, wie "Adaptive" oder "Lightweight" waren bewusst gedacht als einfache, attraktive und wirkmächtige "Dachmarken", mit deren Hilfe es einfacher werden sollte, die verschiedenen dahinterstehenden Frameworks bekannt und populär zu machen und so dafür zu sorgen, dass möglichst viele Softwareentwickler zu deren Anwendern werden konnten, wollten und in ihren Firmen auch durften.

Die Ironie dieser Geschichte liegt darin, dass der gewählte Vermarktungsansatz am Ende zu erfolgreich war - zumindest in der rückwirkenden Betrachtung von Kent Beck. Dadurch, dass fast ausschliesslich die positiven Effekte im Mittelpunkt der Aussendarstellung standen, wollten plötzlich auch Menschen und Organisationen dieses Label tragen, die die notwendigen Kriterien gar nicht erfüllten. Hierin liegt sicherlich einer der Ursprünge von Cargo Cult Agile und dem agil-industriellen Komplex.

Wie es besser gegangen wäre hat im Übrigen ebenfalls Kent Beck gezeigt, und auch darüber berichtet er im Pragmatic Engineer-Podcast. Für sein eigenes Framework Extreme Programming hat er einen Namen gefunden, der einerseits gut vermarktbar ist, andererseits aber klar macht, dass es anspruchsvoll und anstrengend sein kann, so zu arbeiten. Man kann lange darüber spekulieren, welchen Weg die agile Bewegung wohl gegangen wäre, wenn man sie auf diese Weise vermarktet hätte.

Der Überbau von OKRs

Für sich genommen klingt die Idee der Objectives and Key Results (OKRs) einfach. Man setzt ein abstraktes, mittelfristiges Objective (z.B. Erschliessung eines neuen Kundensegments im nächsten Quartal) und verbindet es mit wenigen messbaren Key Results (z.B. X Nutzer nach dem ersten Monat, Y Wachstumsrate im 2. Monat, Z Prozent Verlängerungen nach der Probezeit). Eine Herausforderung, die dadurch entsteht ist aber die Verbindung der OKRs mit der übergreifenden Unternehmensstrategie.

 

Um klarer zu machen warum das eine Herausforderung ist: eine übergreifende Strategie setzt sich zusammen aus Entscheidungen, auf welche Märkte, Produkte, Preissegmente und Produktionsprozesse sich ein Unternehmen in der länger- und langfristigen Zukunft konzentrieren will, was in der Regel einen Zeithorizont von Jahren oder sogar Jahrzehnten bedeutet. Zwischen einer solchen auf Jahre ausgerichteten Strategie und den nur wenige Monate umfassenden OKR-Zyklen klafft eine Lücke.

 

Versucht man diese Lücke zu schliessen entsteht die nächste Herausforderung: so wie OKRs gedacht sind, sollten die Objectives keine bereits lange im Voraus festestehenden Teile eines Work Breakdown aus einem Strategie-Umsetzungsplan sein, sondern noch kurz vor jedem Zyklus verfasst oder angepasst werden können. Das Ziel sollte also sein, eine Verbindung zwischen Strategie und OKRs zu schaffen, die zwar für eine übergreifende Ausrichtung sorgt, dabei aber möglichst wenig einengend ist.

 

Wie das im Einzelfall aussehen kann hängt vom jeweiligen Kontext ab. Wenn der z.B. eher von Product Discovery geprägt ist, also von einer Neu- oder Weiterentwicklung mit schnellen Feedback-Zyklen, kann es Sinn machen, Outcome-orientierte längerfristige Ziele zu formulieren (z.B. "langfristige Power User werden für ihre Treue belohnt"), ohne vorzugeben, durch welche Massnahmen, mit welcher Belohnung oder oder in welchen Systemen das erreicht werden soll.

 

Wenn es dagehen eher um die kontinuierliche Optimierung etablierter Produkte oder Services geht, kann es ein guter Weg sein, North Star-Metriken zu definieren (z.B. je nach Produkt Anzahl der Buchungen, Interaktionsraten, Nutzungsdauern, etc) und deren dauerhafte und langfristige Optimierung anzustreben, auch hier ohne eine länger im Voraus verfasste Vorgabe, wie das stattzufinden hat. Und natürlich gibt es neben diesen beiden Kontexten noch viele weitere mögliche.

 

Da es auch im Umfeld der OKRs zur Entwicklung einer eigenen Fachsprache gekommen ist, gibt es auch für diese Verbindungselemente zwischen Strategie und Objectives einen eigenständigen Namen. Man spricht von "Moals",  wobei es sich um eine Abkürzung für "mid-term Goals" handelt, also um mittelfristige Ziele im Sinn von Jahreszielen, o.Ä. Wie immer im Fall solcher Begriffe kann man sich auch bei diesem über Sinnhaftigkeit und Originalität streiten, zumindest ist er aber OKR-spezifisch.

 

Ob man den Begriff benutzt oder nicht ist am Ende auch relativ egal, viel wichtiger ist, dass die Lücke zwischen Strategie und OKRs überhaupt geschlossen wird. Und eine letzte wichtige Faustregel kann man sich merken: immer wenn versucht wird, Prozesse und Formate rund um diese Verbindungsschicht vorzugeben (formalisierte Moal Plannings, zu befogende Moal Templates, etc) hat das nicht mehr viel mit der ursprünglichen Idee der OKRs zu tun, sondern ist Teil des agil-industriellen Komplexes.

Scrum Guide Expansion Pack

Bild: Unsplash / Olga Guryanova - Lizenz

Mit dem Scrum-Framework haben Jeff Sutherland und Ken Schwaber etwas Bemerkenswertes geleistet: es ist ihnen gelungen, das de facto-Standard-Vorgehen der globalen Software-Industrie zu entwickeln. Der Minimalismus, der die Stärke von Scrum bildet, ist dabei gleichzeitig seine Schwäche - es ist schnell zu verstehen, lässt dabei aber auch einen Freiraum, der mit komplizierten und umfangreichen Regelwerken gefüllt werden kann, von denen SAFe und Disciplined Agile (DA) die bekanntesten sein dürften.

Da ein Grossteil der agilen Community diese beiden Ansätze ablehnt, gibt es bereits seit langem den Wunsch, ihnen eine dem ursprünglichen Geist von Scrum eher entsprechende Erweiterung entgegenzusetzen, idealerweise beruhend auf bereits verbreiteten Praktiken. Large Scale Scrum (LeSS) ist vor diesem Hintergrund entstanden, hat aber nur einen eher inoffiziellen Status. Erst seit Juni 2025 gibt es eine quasi-offizielle Erweiterung, verfasst (u.a.) von Jeff Sutherland: das Scrum Guide Expansion Pack.

Dieses Expansion Pack (mit ca 50 Seiten deutlich umfangreicher als der 13-seitige Scrum Guide, aber auch deutlich schlanker als SAFe und DA) wurde neben Sutherland von John Coleman und Ralph Jocham mitverfasst und besteht aus vier Sektionen: der eigentlichen Erweiterung mit dem Namen Adaptation of: The original Scrum Guide und einem Appendix aus den drei Teilen MORE executive SUCCESS extract, Cynefin Framework Kind of Explanation unofficial & unauthorized und Emergent Strategy.

 

In die erste Sektion ist auch der eigentliche Scrum Guide eingebettet, um ihn zu ergänzen enthalten alle vier Sektionen weiterführende Erläuterungen, einige der erwähnten verbreiteten Praktiken und historische Hintergründe. Das ist zum Teil banal (etwa wenn erklärt wird, dass "self managing" ein von aussen kommendes Management ausschliesst) zum Teil aber auch durchaus aufschlussreich (z.B. dann wenn erklärt wird, welche Untergruppen die eher diffuse Gesamtgruppe der "Stakeholder" haben kann).

 

An einigen Stellen finden de facto Erweiterungen des Scrum Guides statt, so gibt es jetzt nicht mehr lediglich drei Artefakte (Product Backlog, Sprint Backlog und Increment) sondern mit dem Product ein viertes; aus der einen Definition of Done sind die Definition of Outcome Done und die Definition of Output Done geworden; zu den drei Rollen, bzw. Accountabilies (Developer, Product Owner, Scrum Master) kommt mit den Stakeholdern eine vierte.

 

Zu den aufgenommenen Praktiken gehören am prominentesten die Produkt Vision (die das Product Goal nicht ersetzt sondern ergänzt), die Akzeptanzkriterien (die nochmal aufgeteilt werden in die eigentlichen Akzeptanzkriterien und so genannte Outcome-Kriterien) und die häufigsten in Retrospektiven besprochenen Themen (u.a. Professionalität, Effektivität und Teamdynamiken), über den Text verstreut finden sich aber auch weitere, etwa Systems Thinking, (Product) Discovery und Beyond Budgeting.

 

Eher in den Berech der Nerd-Wissens gehören einige Exkurse zu historischen Begrifflichkeiten und Dokumenten. So werden die Scrum Werte Focus, Openness, Courage, Commitment und Respect aus dem amerikanischen Militär-Begriff OODA (Observe, Orient, Decide, Act) abgeleitet und gleich mehrere Absätze widmen sich dem wissenschaftlichen Paper The New New Product Development Game von 1986, das eine zentrale Inspirationsquelle für Sutherland und Schwaber war.

 

Im Gegenzug dazu gibt es mit einem eigenen Teil zum Thema der künstlichen Intelligenz (KI) auch etwas, das erkennbar von aktuellen Entwicklungen getrieben ist. Kurioserweise eingeordnet zwischen den Rollen, bzw. Accountabilies werden die damit verbundenen Möglichkeiten und Risiken herausgestrichen (und es wird hervorgehoben, dass der Scrum Master keine KI sein darf¹). Das ist nicht falsch, aber etwas willkürlich, mit gleicher Berechtigung hätte man z.B. auch Big Data oder Cloud mit aufnehmen können. 

Ob das Scrum Guide Expansion Pack weite Verbreitung finden und noch weiter modifiziert werden wird, wird sich zeigen, wahrscheinlich ist aber in Analogie zum eigentlichen Scrum Guide (den es nur ergänzt, aber nicht ersetzt) beides. Ob es sich als Ersatz oder Gegenmodell zu den kommerziell erfolgreichen und von professionellem Marketing unterstützen Ansätzen SAFe und DA durchsetzen wird ist dagegen weit weniger klar, das in den nächsten Jahren zu beobachten wird sicherlich spannend sein.

 

Auf jeden Fall wird man es aber gut nutzen können, um zu erkennen, wer sich wirklich für das Thema Scrum interessiert. Denn ganz sicher werden nus solche Personen bereit sein, die gesamten ca 50 Seiten durchzulesen. Alle anderen werden das vermutlich geflissentlich an ihren Scrum Master delegieren.

²Und der Product Owner auch nicht, und mindestens ein Entwickler auch nicht. Fun Fact: für die Stakeholder gilt das nicht, die könnten im Extremfall alle KI sein.

Agile Success Stories: ein wirklich crossfunktionales Team

Bild: Pexels / Ketut Subiyanto - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist schade, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Am Anfang von dieser hier stand wie so oft ein Frustrationserlebnis. Eine grosse Firma, bei der ich im Einsatz war, hatte sich in einem Pilotprojekt auf die Idee crossfunktionaler Entwicklungsteams eingelassen, in der Hoffnung, dadurch die alles verzögernden Warte- und Übergabephasen zwischen den bisherigen Spezialistenteams deutlich verkürzen zu können. Bis zu einem gewissen Grad war das auch eingetreten, allerdings bei Weitem nicht in dem von allen erhofften Ausmass.

Eine Untersuchung der betroffenen Einheiten und Prozesse konnte dann klar aufzeigen, woran das lag: das Team war nur crossfunktional innterhalb der Softwareentwicklung (Frontend, Backend, Data Science, UX), was aber bei weitem nicht alle Arbeitsschritte abdeckte. Das Produkt (ein Kundenservice-Chatbot) musste nach der Entwicklung noch zur Fachabteilung, um von der mit Daten versorgt und trainiert zu werden, um dann von der Rechtsabteilung freigegeben zu werden. Hier entstanden weiter Wartezeiten.

 

Auch Mitglieder dieser beiden Abteilungen in das crossfunktionale Teams aufzunehmen war die offensichtliche Lösung, führte aber zu Beginn zu heftigen Abwehrreaktionen; dafür gäbe doch gar nicht genug Zeit, und es gäbe zu viel Anderes zu tun, das wichtig wäre. Auch hier führte eine Nachforschung schnell zu einer Identifikation des eigentlichen Problems: die betroffenen Kollegen waren stark überplant und hatten nur wenige Stunden pro Woche für das Pilotprojekt zur Verfügung - deutlich zu wenig.

 

Es brauchte mehrere Wochen und Eskalationen bis ins Top-Management um dieses Problem zu lösen, aber am Ende stand ein deutlich besseres Setup. Aus der Fachabteilung wurden mehrere Mitarbeiter für vier Tage pro Woche exklusiv für das Projekt freigestellt, aus der Rechtsabteilung immerhin ein Kollege für drei halbe Tage pro Woche. Damit konnten sie in das jetzt wirklich crossfunktionale Team eingegliedert werden, an dessen Meetings teilnehmen und eng mit den anderen Teammitgliedern zusammenarbeiten.

 

Durch diese Neuorganisation trat dann endlich die angestrebte Beschleunigung ein. Durch die täglichen Abstimmungen war jetzt jederzeit klar, wann die Übergaben zwischen den Teilteams stattfinden würden, und durch die realistischere Kapazitätsplanung konnten sie auch fast immer sofort stattfinden. Die Durchschnittlsdauer der Warte- und Übergabephasen sank von Tagen und Wochen auf Stunden (und als Nebeneffekt konnten die Meetings entfallen, in denen die zu übergebende Arbeit verwaltet wurde).

 

Natürlich gab es noch weitere positive Effekte dieses Vorgehens, z.B. die oben erwähnte Aufdeckung der strukturellen Überplanung vieler Mitarbeiter, da schnellere Durchlaufzeiten durch crossfunktionalere Teams aber das Hauptziel der Umstellung auf agiles Arbeiten waren, steht auch das hier im Focus dieser "agilen Erfolgsgeschichte". Und darüber hinaus ist es ein gutes Beispiel dafür, wie weit wirkliche Crossfunktionalität gehen kann.

Der Change-Prozess als bewusste Machtkampf-Arena

Eine häufige Beschwerde bei Veränderungsvorhaben in grossen Organisationen ist, dass unverhältnismässig viel Zeit in Meetings aller Art verloren geht. Workshop folgt auf Workshop, Steuerungskreis auf Steuerungskreis, Entscheidungsrunde auf Entscheidungsrunde - nur damit am Ende ein Ergebnis steht, für dessen Festlegung bereits ganz am Anfang alle Informationen zur Verfügung gestanden hätten. Warum tut man sich das an?

Eine interessante Erklärung dafür bietet der Soziologie-Professor Stefan Kühl im wie immer hörenswerten Podcast "Der ganz formale Wahnsinn". Ihm zufolge dienen derartiger Meetings nicht nur der rationalen Entscheidungsfindung, sondern auch dem Austragen von Machtkämpfen, deren Stattfinden zu derartigen Anlässen nicht nur möglich, sondern sogar gewünscht ist, die dort aber nach Möglichkeit auch abgeschlossen werden sollen - etwas, was ich mehrfach genau so erlebt habe.

Um das zu verstehen holen wir zunächst etwas aus: Veränderungen führen in sehr vielen Fällen dazu, dass es Gewinner und Verlierer gibt. Ein Abbau von Hierarchien reduziert Bürokratie, verknappt aber dafür die Karriereoptionen; die Schaffung von Spezialistenlaufbahnen ermöglicht individuellen Statusgewinn, das aber auf Kosten der Gleichbehandlung in Teams; etc. etc. Das ist meistens schon früh erkennbar und löst bei den negativ Betroffenen die erwartbaren Widerstände aus.

Werden Veränderungen jetzt (zu) schnell beschlossen, finden diese Widerstände im Rahmen der bereits neu geordneten Organisation statt, was diese von Beginn an lähmen kann. Gelingt es dagegen, die Widerstände (und die Anstrengungen zu ihrer Überwindung) vor die Entscheidung zur Neuordnung zu legen, und zwar so, dass die Gewinnerseite des dadurch entstehende Machtkampfes diese Entscheidung prägen darf, dann kann die Startphase der neuen Organisation weitgehend ungestört beginnen.

Die verschiedenen Workshops, Steuerungskreise und Entscheidungsrunden bilden in dieser Betrachtungsweise eine Arena, in der die verschiedenen Parteien vor den Augen der restlichen Organisation gegeneinander antreten, einzelne Auseinandersetzungen gewinnen, andere verlieren, nach und nach ermüden, neue Kraft schöpfen, Bündnisse schliessen und Rückzugsgefechte führen, bis letztendlich eindeutig klar ist, wer sich in welchem Bereich durchgesetzt hat.

Am Ende dieser Vorgänge stehen gleich mehrere Ergebnistypen: zum einen die Entscheidungen der Machtkämpfe, und mit ihnen auch die über das Ausmass und die Weiterführung der Veränderungen, zum anderen aber auch eine Legitimation und Delegitimation von Standpunkten. Die Gewinner können sich zukünftig auf den langen und ausführlichen Entscheidungsprozess berufen, den Verlierern kann vorgehalten werden, dass sie trotz ausreichender Zeit keine Mehrheiten für ihre Ideen finden konnten.

Was mit dieser Art einer Change-Herbeiführung verbunden ist, ist natürlich das Risiko einer hochemotionalen Konfliktaustragung, da jede Seite befürchten muss, nach einer Niederlage auf unabsehbare Zeit kein Gehör für Ihr Anliegen mehr zu finden. Schlimmstenfalls kann sogar das Gegenteil des Angestrebten erreicht werden, einer belasteter statt eines unbelasteten Neustarts, nur mit einer Belastung durch Verbitterung und Verletzungen statt durch weitergehende Widerstände.

Um das zu vermeiden kann es sich anbieten, Veränderungen nicht in seltenen, grossen Programmen durchzuführen, sondern in einer stetigen Reihe von kleineren Vorhaben. Der Arena-Effekt verschwindet dadurch zwar nicht, dadurch dass die Auseinandersetzungen kleiner und reversibler werden, gehen aber die zur Schau Stellung und die potentielle Emotionalität zurück. Und als ein Seiteneffekt sind in jedem einzelnen Fall auch weniger Meetings nötig, was wiederum zu weniger Beschwerden führt.

Digitales Working Out Loud als Alternative zum Daily

Bild: Pexels / Polina Tankilevitch - Lizenz

In den meisten agilen Teams sind die Daily Meetings (Daily Scrum, Daily Standup, Daily Symc, etc) ein fester Bestandteil ihrer Arbeitsweise. In einzelnen Fällen stösst dieses Konzept aber an Grenzen, etwa wegen nicht gegebener gleichzeitiger Verfügbarkeit, wegen Introvertiertheit oder (bei remote-Arbeit) wegen schlechter Internet-Verbindung. Um trotzdem im engen Austausch bleiben zu können, gibt es für solche Teams eine mögliche Alternaltive: digitales Working Out Loud (WOL).

Um Missverständnissen vorzubeugen: bei Working Out Loud handelt es sich in diesem Fall nicht um die seit 2015 entwickelte formalisierte Social Learning-Methode gleichen Namens, sondern um die dahinterstehende, 2010 von Bryce Williams entwickelte Grundidee, die lediglich aus zwei Prinzipien besteht: die eigene Arbeit sichtbar zu machen und sie in Erzählform zu vermitteln. Diese Prinzipien lassen sich auch in Team-interne Kommunikation übertragen.

Um das (in einer nicht-verbalen Form) zu tun braucht es zunächst einen gemeinsamen digitalen Kommunikationskanal. Das kann in der rudimentärsten Form eine Whatsapp-Gruppe sein. in den meisten Firmen sind aber professionelle Tools vorhanden (Teams, Slack, etc.), in denen sich eigene Kanäle für ein Team anlegen lassen. In diesen Chat kann man dann alles eintragen, woran man gerade arbeitet. Damit ist bereits das erste Prinzip erfüllt, die Sichtbarkeit.

Das zweite Prinzip, die Erzählform, ist nötig um die Information über die eigene Arbeit mit dem nötigen Kontext zu versehen. "Ich arbeite an Komponente XY" würde z.B. nicht klar machen, warum diese Arbeit stattfindet. "Ich arbeite wie besprochen an Komponente XY, damit unser Hauptkunde rechtzeitig die Exportfunktion bekommt die wir ihm bis Ende des Monats versprochen haben" macht dagegen den Hintergrund und die Prioritäten deutlich klarer.

Wichtig ist dabei, dass diese Information im Voraus stattfindet. Falls eines der anderen Teammitglieder Einwände, Fragen, Hinweise oder Verbesserungsvorschläge hat, können die dann noch eingebracht werden bevor die Arbeit begonnen wurde. Das Risiko, versehentlich unnötige oder in Relation unwichtige Arbeiten zu beginnen wird so minimiert. Und natürlich kann der Chat bei Unklarheiten auch für schnelle Klärungen und Abstimmungen genutzt werden.

Mit ein bisschen Übung kann diese Art des Working Out Loud einen Grossteil der Kommunikation ersetzen, die sonst in einem Daily Meeting stattfinden würde. Bei entsprechender Nutzung können die ausgetauschten Informationen sogar noch weiter angereichert werden, etwa durch Links zu Anforderungen oder Build Reports, durch angehängte Dateien oder in den Text eingebettete Screenshots und Diagramme. An diesen Stellen kann ein Chatt sogar besser sein als ein Meeting.

Schlechter als in einem Meeting lassen sich in einem Chat dagegen Stimmungen, Emotionen und sonstige soziale Aspekte sichtbar machen. Schlimmstenfalls kann es sogar zu Konflikten kommen, da Sorgen, Ungeduld oder Verärgerung nicht erkannt werden. Ein weiterer wichtiger Punkt ist, dass digitales WOL eine ständige Beachtung des Chats erfordert, was ggf. störend für Konzentration und Produktivität sein kann und zu Stress führen kann.

Digitales Working Out Loud kann also eine brauchbare Alternative zum klassischen Daily Meeting sein, es kommt aber mit einem Preis, dessen man sich bewusst sein sollte. Wenn nicht die oben genannten Gründe (oder ähnlich schwerwiegende) gegeben sind sollte man daher vor einer Umstellung die Vor- und Nachteile gegenüberstellen, und ggf. in einer Testphase erproben, wie der neue Modus funktioniert und mit welchen Effekten er verbunden ist.