# Ein Projekt liefert. Ein Experiment klärt. _10. Juni 2026_ #agil #newwork #leadership Als Christian und ich vor mehr als vier Jahren die erste Folge unseres [Podcasts](https://open.spotify.com/show/6II3r9LZW5rbeqmDxCsDAh?si=1019c9d1f708474b) aufgenommen haben, gab es keinen Plan. Kein Konzeptpapier, keine Zielgruppenanalyse, kein Redaktionskalender. Nur eine Verabredung: Wir fangen an und schauen, was passiert. Zur Folge 100 haben wir uns alte Ausschnitte angehört. Da waren die selbstgesungenen Intros, die zum Glück keine Zukunft hatten. Die Phase der Kompaktfolgen. Livestreams, ein Live-Kommentar zum Apple-Event, ein gemeinsam kalibrierter Regenmesser. Vieles davon haben wir wieder beendet. Nichts davon stand je in einem Plan. 160 Folgen später frage ich mich: Hätte uns ein detaillierter Plan weitergebracht? Ich glaube nicht. Er hätte uns am Anfang vermutlich aufgehalten. ### Der vertraute Reflex In Organisationen beobachte ich oft das Gegenteil. Auf wachsende Unsicherheit reagiert man mit mehr Planung, mehr Dokumentation, mehr Kontrolle. Das klingt nach Sicherheit, macht Systeme aber häufig anfälliger. Detaillierte Fünfjahrespläne versprechen eine Gewissheit, die sie nicht halten können. Die Landkarte ist manchmal schon veraltet, bevor alle sie verstanden haben. Warum halten wir trotzdem daran fest? Eine mögliche Antwort: weil es in der Vergangenheit funktioniert hat. Wer lange das Richtige tut, kann blind dafür werden, dass sich die Wirklichkeit verändert hat. Genau das ist die Erfolgsfalle. Strukturen und Prozesse sind so gut an ein früheres Modell angepasst, dass jede Abweichung von diesem Modell zur Bedrohung wird. Zugespitzt gesagt sind viele organisatorische Regeln eingefrorene Annahmen aus der Vergangenheit. Sie entstanden unter bestimmten Bedingungen, wurden zur Gewohnheit und gelten heute als Tatsache, obwohl sich ihre Voraussetzungen längst verändert haben können. Das Problem ist nicht die Erfahrung. Das Problem beginnt dort, wo Erfahrung nicht mehr überprüft wird. ### Kein kleineres Projekt Ein Experiment ist kein kleineres Projekt. Der Unterschied liegt im Zweck: Ein Projekt soll etwas liefern. Ein Experiment soll etwas klären. Klassische Projekte messen Erfolg an der Umsetzung. Wurde der Termin gehalten? Das Budget? Der vereinbarte Umfang? Ein Projekt kann all das erfüllen und trotzdem am wirklichen Bedarf vorbeigehen. Die bessere Frage lautet deshalb nicht nur: Was haben wir geliefert? Sie lautet: Was wissen wir jetzt, was wir vorher nicht wussten? Ein praktisches Werkzeug dafür ist das Denken in Minimum Viable Products, kurz MVPs: möglichst kleine Versuche, mit denen sich eine wichtige Annahme unter realen Bedingungen überprüfen lässt. Dabei geht es nicht darum, unfertige Produkte abzuliefern. Wie im [[Design Thinking]] gilt: Ein Prototyp verkörpert nur die Aspekte, die es zu testen gilt. Es geht darum, früh zu lernen, bevor die eigenen Annahmen schneller altern, als die Organisation lernen kann. In der [[Agilität|agilen Produktentwicklung]] gibt es dafür eine Kurzform, die mir hängen geblieben ist: so schnell und so günstig wie möglich scheitern. Unsere Kompaktfolgen waren so ein Versuch. Thematisch fokussierte Folgen im Wechsel mit dem gewohnten Format. Wir haben sie eine Weile produziert, beobachtet, wie sie ankommen, und sie wieder eingestellt. Der Versuch hat seine Aufgabe erfüllt: Wir wussten danach mehr über unser Format als vorher. ### Auf die Funken achten Wenn die Richtung unklar ist, hilft es, nicht alles auf eine Idee zu setzen. Stattdessen mehrere kleine Versuche mit überschaubarem Einsatz starten, wie Testballons in unterschiedliche Richtungen. Und dann beobachten: Wo reagiert das System? Wo entsteht echtes Interesse? Welche Idee erzeugt Resonanz? Danach braucht es Disziplin. Ideen, die keine Reaktion auslösen, dürfen früh enden. Nicht weil sie schlecht waren, sondern weil der Versuch seine Aufgabe erfüllt hat. Das schützt vor der Sunk-Cost-Falle: Je mehr Zeit, Geld und persönliches Ansehen in einer Idee stecken, desto schwerer fällt es, sie aufzugeben, selbst wenn die Fakten längst dagegen sprechen. Ein Experiment darf enden. Genau darin liegt sein Wert. ### Was ein gutes Experiment auszeichnet Drei Eigenschaften haben sich für mich als entscheidend erwiesen. **Klein und kurz:** In Wochen denken, nicht in Monaten. Wenn ein Versuch ein halbes Jahr dauert, ist er vermutlich kein Experiment mehr, sondern ein Projekt. Damit geht der Vorteil verloren, schnell und mit begrenztem Risiko zu lernen. **Messbar:** Vor dem Start eine Hypothese formulieren und festlegen, woran eine relevante Reaktion zu erkennen ist. Nicht zuerst fragen: Was werden wir bauen? Sondern: Was werden wir nach dem Versuch wissen? **Transparent:** Über gescheiterte Versuche ebenso offen sprechen wie über erfolgreiche. Ein negatives Ergebnis ist kein Makel, wenn es eine Annahme geklärt und größere Fehlinvestitionen verhindert hat. Erst wenn Erkenntnisse geteilt werden, kann eine ganze Organisation von ihnen profitieren. [[Retrospektiven]] geben diesem Teilen einen festen Ort. Ein Experiment ohne Erkenntnis ist nur Beschäftigung. ### Führung schafft den Raum Damit diese Arbeitsweise trägt, braucht es psychologische Sicherheit. Menschen müssen Zweifel äußern, Fehler ansprechen und unfertige Gedanken teilen können, ohne dafür abgewertet zu werden. Fehler werden dann kein Skandal, sondern ein Anlass, genauer hinzusehen. Ein sicherer Raum ist aber keine Komfortzone. Führung braucht auch eine Alarmfunktion: regelmäßig den Status quo hinterfragen, besonders jene Abläufe, die niemand mehr erklären kann. Welche Annahme steckt hinter dieser Regel? Würden wir heute noch einmal genauso entscheiden? Nicht aus Misstrauen. Aus Aufmerksamkeit. ### Anfangen statt warten Vielleicht kennst du das aus deiner eigenen Organisation: Der nächste große Wurf wird geplant, während sich die Welt darunter weiterdreht. Für mich heißt das: nicht auf den perfekten Plan warten. Er kommt nicht. Lieber ein kleines Experiment starten, beobachten, was die Wirklichkeit darauf antwortet, lernen und anpassen. Mehr investieren erst dann, wenn ein echter Funke zu erkennen ist. Unser Podcast hatte nie einen Plan. Aber er hatte bereits über 160 Gelegenheiten, etwas zu lernen. _Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt._ ### Weitere Artikel - [[Agilität]] - [[Prinzipien des Agile Systems Engineering]]