Agile Entwicklung verspricht einen besseren Umgang mit Unsicherheit – und doch dominieren in vielen Projekten weiterhin detaillierte Pläne, Feinkonzepte und Architektur mit Big Design Up Front. Warum fällt es so schwer, loszulassen?

Diese Episode beleuchtet die psychologischen Gründe hinter dem Festhalten an Planung: das Bedürfnis nach Sicherheit, die Angst vor Chaos und die Illusion von Kontrolle. Und sie zeigt, welche Bedingungen nötig sind, damit Teams sich wirklich auf das Unplanbare einlassen können – mit Vertrauen, Mut und einer gesunden Fehlerkultur.

2025-05-23 Thumbnail

PeerTube Video - no Big Tech!

YouTube Video

Audio als Podcast

MP3 Download
Infos und Feeds zum Audio als Podcast

Hinweis: Die nachfolgenden Texte wurden mit KI erstellt und können somit Fehler enthalten.

Die Illusion der Kontrolle in Softwareprojekten: Warum wir trotz besseren Wissens an exzessiver Planung festhalten

In der Softwareentwicklung wissen wir seit Jahrzehnten, dass iterativ-inkrementelles Vorgehen und agile Methoden der effektivste Weg sind, um erfolgreiche Projekte durchzuführen. Dennoch sehen wir in der Praxis immer wieder übertriebene Planungs- und Kontrollversuche. Warum ist das so und was können wir dagegen tun?

Die rationale Perspektive

Aus rationaler Sicht ist die Evidenz überwältigend: Softwareprojekte lassen sich nicht vollständig im Voraus planen. Requirements ändern sich, neue Erkenntnisse kommen hinzu, technische Herausforderungen werden erst während der Implementierung wirklich deutlich. Das zeigt sich in praktisch jedem Projekt.

Auch andere Ingenieursdisziplinen arbeiten iterativ mit Prototypen. Sie bauen schrittweise Versionen, bis das finale Produkt die Anforderungen erfüllt. Der Unterschied ist nur, dass Prototypen dort oft deutlich teurer sind als in der Softwareentwicklung.

Selbst das vielzitierte Wasserfallmodell war nie als strikt sequentielles Vorgehen gedacht. Bereits in den 1960er Jahren war klar, dass Software iterativ entwickelt werden muss. Agile Methoden haben sich durchgesetzt, weil sie genau diesen Realitäten Rechnung tragen.

Die psychologische Dimension

Wenn die rationale Perspektive so eindeutig ist - warum halten wir dann trotzdem am zu detaillierten Plänen und der Illusion von Kontrolle fest? Die Gründe sind vor allem psychologischer Natur:

  1. Natürliches Kontrollbedürfnis: Menschen haben ein grundlegendes Bedürfnis nach Kontrolle und Vorhersagbarkeit. Die Vorstellung, nicht alles planen zu können, erzeugt Unbehagen.

  2. Sozialer Druck: In vielen Organisationen herrscht die Erwartung, dass “professionelle” Softwareentwicklung detaillierte Pläne und Architekturen erfordert. Wer das nicht liefert, gilt als unprofessionell.

  3. Absicherungsdenken: Ausführliche Planung dient oft der persönlichen Absicherung. Wenn etwas schief geht, kann man auf den Plan verweisen und Verantwortung abwehren.

  4. Politische Dimension: Softwareprojekte sind häufig Karrierevehikel. Der offizielle “Erfolg” kann wichtiger sein als das tatsächliche Ergebnis.

Die Rolle der Fehlerkultur

Ein Schlüsselfaktor ist die vorherrschende Fehlerkultur in Organisationen. Wenn Planabweichungen und Kursänderungen als “Fehler” gesehen werden, entsteht ein starker Anreiz, an ursprünglichen Plänen festzuhalten - auch wenn sie nicht mehr optimal sind.

Eine gesunde Fehlerkultur würde stattdessen Änderungen als normal akzeptieren und konstruktiv damit umgehen. Das erfordert psychologische Sicherheit: Die Beteiligten müssen Probleme und Änderungsbedarf ohne Angst vor negativen Konsequenzen ansprechen können.

Pragmatischer Umgang

Was bedeutet das für die Praxis? Zunächst müssen wir akzeptieren, dass der Wunsch nach Kontrolle natürlich und nachvollziehbar ist. Statt ihn zu bekämpfen, sollten wir:

In manchen Umgebungen mag es auch legitim sein, eine gewisse “Illusion der Kontrolle” aufrechtzuerhalten, während man schrittweise auf bessere Praktiken hinarbeitet. Wichtig ist das Bewusstsein, dass detaillierte Vorabplanung eine Illusion ist - und der pragmatische Umgang damit.

Fazit

Die Überwindung übertriebener Planungs- und Kontrollversuche ist weniger eine Frage rationaler Argumente als vielmehr eine psychologische und kulturelle Herausforderung. Nur wenn wir die zugrundeliegenden Mechanismen verstehen, können wir effektiv gegensteuern und eine gesündere Projektkultur etablieren.

Der Weg dorthin führt über kleine Schritte, psychologische Sicherheit und die Akzeptanz, dass Softwareentwicklung ein Lernprozess ist, der sich nicht vollständig kontrollieren lässt. Das mag unbequem sein - ist aber der einzige Weg zu nachhaltig erfolgreichen Projekten.

Folge 264 - Statt Agilität und moderner Architektur: Die Illusion von Kontrolle

Wichtige Keytakeaways:

  1. Die vollständige Planung von Software-Projekten ist nicht möglich - Änderungen sind unvermeidlich.
  2. Iterativ-inkrementelles Vorgehen und Agilität sind bewährte Ansätze im Software Engineering.
  3. Software-Entwicklung ist ein Lernprozess (Knowledge Crunching), nicht nur reine Umsetzung.
  4. Requirements können nie vollständig und fehlerfrei spezifiziert werden.
  5. Die Illusion der Kontrolle durch übermäßige Planung ist oft psychologisch motiviert.
  6. Eine gute Fehlerkultur ist wichtiger als perfekte initiale Planung.

Behandelte Kernfragen:

  1. Warum streben wir nach vollständiger Kontrolle in Software-Projekten?
  2. Wie geht man mit der Unsicherheit in Software-Projekten um?
  3. Warum funktionieren rationale Argumente für agiles Vorgehen oft nicht?
  4. Wie kann man eine bessere Fehlerkultur etablieren?
  5. Welche Rolle spielen politische Faktoren bei der Projektsteuerung?

Glossar wichtiger Begriffe:

Vollständige Transkription

Hinweis: Dieses Transkript wurde mit KI erstellt und kann somit Fehler enthalten.

Folge 264 - Statt Agilität und moderner Architektur: Die Illusion von Kontrolle

Ja, worum geht es eigentlich?

Iterativ-inkrementelles Vorgehen vs. Agilität

Also es geht halt für mich darum, dass wir eigentlich bei sowas wie einer Projektdurchführung von Software-Projekten, das ist ja eines der Themen, was im Titel angesprochen wird, in der Architektur, eigentlich wissen, dass wir iterativ-inkrementell vorgehen müssen, also schrittweise.

Definition iterativ-inkrementell

Das heißt, wir bauen erst mal ein kleines System, dann bauen wir schrittweise halt dieses System aus und bringen dabei halt öfter Dinge in Produktion und kriegen darüber irgendwie Feedback.

Das ist auch was anderes als Agil.

Definition Agilität

Agil ist ein Vorgehensmodell, wo meiner Ansicht nach Änderungen als treibender Faktor realisiert werden und nicht irgendwie als Störung oder Anomalie, wo ich also im Rahmen von irgendwelchen Iterationen den Plan ändern kann.

Das sind zwei unterschiedliche Dinge.

Iterativ-inkrementell bedeutet vielleicht, ich habe einen festen Plan, aber ich führe den eben schrittweise aus.

Und Agil würde bedeuten, dass ich Änderung willkommen heiße und dass halt für mich Änderungen wichtiger Treiber sind vom Vorgehen.

Unmöglichkeit vollständiger Planung

Eigentlich sollte es in gewisser Weise offensichtlich sein, dass man Projekte nicht vollständig planen kann.

Lernen aus Projekterfahrung

Meine Behauptung wäre, wenn ich halt ein Software- Entwicklungsprojekt durchgeführt habe und anschließend eine Retro mache und mir sage, okay, ich habe das halt am Anfang alles versucht zu planen.

Ich habe mir halt irgendwie überlegt, dass halt irgendwelche Dinge passieren werden und dass ich halt in irgendeiner Art und Weise vorgehen möchte.

Dann habe ich halt hoffentlich nach dem ersten Projekt in der Retro das Gefühl, ja gut, dass ich das geplant habe.

Das ist am Ende dann irgendwie deutlich anders gekommen, als ich irgendwie gedacht hatte.

Und darauf kann ja nicht die Reaktion sein, zu sagen, okay, ich sollte halt noch mehr planen, sondern Änderungen kann ich eben nicht antizipieren.

Ich kann auch nicht alles sozusagen vorhersehen.

Also müsste eigentlich die Konsequenz sein, schrittweise vorzugehen und eben damit umzugehen, dass halt Dinge sich sozusagen ändern.

Tasklog auf YouTube hat gerade geschrieben, Stakeholder gleich Manager aus Perspektive von Softwarearchitekten.

Stakeholder und Kundenbeziehungen

Nee, Stakeholder sind nicht unbedingt Manager, sondern das nennen wir auch Benutzer nicht.

Definition Stakeholder

Leute, die halt ein Stake haben, also die irgendwie ein Interesse haben an der Software, das ist halt mehr als nur die Manager.

Stakeholder muss mit viel Unsicherheit und Customer Collaboration über Contract, Responding to a change, or following a plan, wie handhabt man das?

Naja, also Customer Collaboration, dafür gibt es viele Möglichkeiten.

Dafür haben wir ja eben Sprint Reviews, diese ganzen agilen Vorgehensweisen.

Responding to a change, das sind auch agile Vorgehensweisen.

Im Prinzip ist es klar, wie man das tut.

Das ist ja genau einer der Punkte.

Agilität im Mainstream

Ich würde behaupten, kommt nachher irgendwie noch, dass das, was ich erzähle, eigentlich das ist, was im Mainstream von Softwareentwicklung angekommen ist.

Also es gibt mindestens halt Lippenbekenntnisse zur Agilität.

Wir hatten letzte Woche die Episode mit meinen Kolleginnen Tanja und Uwe, die im Prinzip auch nochmal gesagt haben, das ist halt das Verfahren, mit dem ich eben mit solchen Änderungen umgehe.

Es ist nur irgendwie so, dass der Begriff Agilität verbrannt ist.

Deswegen eben die Episode zur Post-Agilität.

Aber am Ende ist es eben so, dass diese Änderung oder Umgang mit Änderungen eigentlich klar ist und wir wissen eigentlich auch, wie wir das tun.

Wir gehen eben schrittweise vor und ändern dann halt jeweils den Plan.

Das Ganze ist halt meiner Ansicht nach wirklich überwältigend.

Also die Evidenz, dass man so vorgehen muss, ist überwältigend.

Vergleich mit anderen Engineering-Disziplinen

Ich hatte diese Episode gemacht mit dem Hillel Wayne über andere Engineering-Disziplinen.

Also die Frage war, sind wir eigentlich Engineers, also Ingenieure?

In Englisch heißt man ja Software-Engineers.

Und da ist eben die Frage, ob wir halt genauso vorgehen wie irgendwelche Mechanical-Engineers und Electrical-Engineers und was es da noch gibt, Civil-Engineers.

Und es stellt sich heraus, ja, sind wir halt.

Alle arbeiten in Iterationen und arbeiten genauso.

Prototypen und Iterationen

Und es wird eben schrittweise vorgegangen, was eben gerade nicht.

Und es werden beispielsweise Prototypen gebaut.

Man baut so lange Prototypen, bis man eine hohe Sicherheit hat, dass man das wirkliche Ding irgendwie hinbekommt.

Es ist nur irgendwie so, dass Prototypen für eine Leiterplatte oder für ein Auto deutlich teurer sind als das, was wir bei Software haben.

Aber das Vorgehen in Iterationen, worum es also geht, ist eigentlich etwas, was auch dort gemacht wird.

Und es gibt ja die Episode mit der Professor Christiane Floyd, die eben schon im Prinzip berichtet hat, dass halt aus den 60ern schon in der Praxis es halt ihr klar war, dass man anders vorgehen muss und dass man eben, also was heißt anders, dass eben aus der Praxis tatsächlich das Feedback kam mit, ich muss eben iterativ inkrementell vorgehen.

Ich kann nicht die ganzen Sachen damit durchplanen und muss eben so vorgehen, wie wir heute diskutieren.

Und mittlerweile ist es eben auch so, dass halt Agilität gewonnen hat.

Also der offizielle Weg ist eben Agilität.

Das ist der Mainstream.

In Wirklichkeit wird es nicht gelebt.

Das haben wir in der letzten Folge diskutiert.

Aber eigentlich ist das mindestens vom Lippenbekenntnis her klar.

Und auch solche Sachen, wie das eben eigentlich funktionierender Code, nicht Working Code, sollte halt irgendwie das sein, was zeigt, wo wir gerade stehen.

No Estimates Ansatz

Und wir hatten auch eine Episode zu No Estimates mit dem Mutti im Vorfeld der Agile Meets Architecture, der irgendwie sagt, wir brauchen noch nicht mal Dinge abzuschätzen.

Also was er berichtet hat, ist, dass in dem Projekt, in dem er sitzt, dieses Vorgehen ohne irgendwelche Schätzungen funktioniert und halt auch tatsächlich dazu führt, dass man halt Ergebnisse produziert, weil man sich eben nicht mit Schätzen auffällt, sondern eben Ergebnisse produziert.

Und wenn man sozusagen immer am wertvollsten arbeitet, dann ist eigentlich irgendwie alles gut.

Und das hat er sozusagen aus der Praxis berichtet und bedeutet, dass es Projekte gibt, in denen er aktiv ist.

Und das sind offensichtlich alle Projekte, in denen er aktiv ist, die halt dort entsprechend nach diesem Schema arbeiten.

Planungsexzesse in der Realität

In der Realität haben wir immer noch, ich würde sagen, Planungsexzesse teilweise, wo also tatsächlich versucht wird, Projekte runterzubrechen auf die kleinsten Details und das eben zu Ende zu planen.

Aber das fängt ja schon früher an.

Also schon der Versuch zu sagen, ich will halt einen bestimmten Scope in einer bestimmten Zeit mit einem bestimmten Team zu erledigen.

Das geht halt prinzipiell nicht, weil ich das eben nicht genau abschätzen kann.

Das wissen wir.

Wir wissen das schon seit Ewigkeiten.

Ich habe selber auch eine Episode gemacht zu dem Wasserfallmodell, dass das Wasserfallmodell möglicherweise gar nicht existiert.

Und nicht, weil das tatsächlich niemand jemals proklamiert hat.

Und das sagt ja irgendwie, dass ich sehr plangetrieben und nicht iterativ vorgehe.

Und wir wissen halt auch, dass die ersten größeren Projekte, ich habe über das SAGE-Projekt, glaube ich, in der Episode berichtet, das war das erste größere Projekt, wo viele Menschen daran gearbeitet haben.

Die Luftverteidigung der USA in den 50ern mit Transistorrechnern und Lochkarten, wie man sich das vorstellt.

Schon das hat eben ergeben, dass wir eigentlich schrittweise vorgehen sollten und eben Prototypen bauen sollten und das schrittweise hochskanieren sollten.

Und das Feedback aus dem Projekt war eben auch dieses öfter mehrere Iterationen machen.

Ich glaube, sie hatten nur zwei gemacht, den Prototypen und die wirkliche Implementierung.

Und sie hätten eigentlich im Nachhinein lieber mehr Iterationen gemacht.

Das wird kontrastiert in der Praxis mit genau so einem Ansatz, wo man versucht, nicht den Scope und den Termin festzumachen.

Das geht halt irgendwie nicht, weil ich kann das nicht abschätzen auf dem Detailierungsgrad.

Und selbst wenn, das ist halt keine sinnvolle Aussage, denn der Scope, den ich halt umsetzen werde, wird am Ende ein anderer sein als der, den ich ursprünglich geplant hatte, weil ich eben mit der Realität konfrontiert werde und da andere Wünsche kommen, andere Themen kommen, sodass sich halt der Scope ändern wird.

Also sprich, wenn ich tatsächlich das durchführe, was ich dachte, was am Anfang des Projekts sinnvoll ist, würde ich einen Fehlschlag erleiden, weil es sich eben während des Projektes herausstellt, dass ich andere Sachen machen muss.

Und da ist die Frage, warum ist das so?

Es gibt halt eine krasse, teilweise krasse Differenz zwischen dem, wie es sein sollte, wie wir wissen, wie es sein sollte, wie es funktioniert und dem, was umgesetzt wird.

Und dafür brauchen wir halt eine Erklärung.

Also das ist halt da das Thema.

Der Marc Emmer hat gerade geschrieben, wenn man mit Iterationen vorgeht, ist es dann nicht eigentlich ein Problem, wenn man vor dem Projektstart Teamanzahl und Scope nach Plan festlegt, spätestens bei Ausführung des Plans.

Naja, also die eine Behauptung ist halt, ich kann das zwar tun, aber wenn ich tatsächlich das umsetze, was ich am Anfang geplant habe und was der Scope ist, werde ich eine Enttäuschung erleben, weil die Leute eigentlich was anderes wollen.

Das hat zum Beispiel dazu geführt, dass der Chaos Report, der den Erfolg von Projekten ist, das halt auch umgestellt hat von einem Projekt, das dann erfolgreich nicht, wenn es den Scope liefert, sondern wenn die Kundinnen zufrieden sind.

Und das ist eben was anderes.

Und der andere Punkt ist, wenn ich einen festen Scope habe, kann ich trotzdem in Iterationen darauf hinarbeiten.

Und ich kann es doch nochmal wiederholen, das ist das, was alle Engineering Disziplinen machen.

Also wenn ich halt ein Auto bauen möchte, baue ich einen Prototypen und dann baue ich noch einen Prototypen und dann baue ich noch einen Prototypen und noch einen Prototypen, so lange bis halt irgendwann tatsächlich das Erste vom Band läuft.

Und das Erste, was vom Band läuft, wird wahrscheinlich auch nicht exakt dasselbe sein, wie das, was halt als Letztes vom Band läuft.

Das heißt, ich habe einen iterativen Prozess, der inkrementell das Ding hat irgendwie weiterentwickelt.

So arbeitet man eben in den Engineers Disziplinen und das ist eigentlich eben offensichtlich.

Und wie gesagt, da gibt es eben auch in unserer Branche überwältigende Evidenz, selbst für scheinbar festen Scope.

Mein Scope eigentlich mehr als Aufgabe, also das, was ich eben implementieren möchte.

Das ist eben der Scope, was ich letztendlich an Gesamtzahl an Funktionalitäten umsetzen will.

So würde ich das halt definieren.

Das ist also die Geschichte mit dem Plan und dem iterativen Inkrement, bzw. dem Nicht-Wasserfall-Vorgehen.

Und die andere Ebene ist die Architektur.

Ich glaube, es gibt immer noch so eine Vorstellung von einer Architekturphase.

Das finde ich eigentlich nicht schlecht.

Also jetzt nicht mal Gedanken darüber zu machen, wie ich im System strukturiere, was meine Herausforderung ist.

Das Problem ist halt dann, wenn ich sage, es ist schlecht, wenn sich diese Idee aus dieser frühen Phase später verwerfen muss.

Denn ich würde behaupten, das muss sich halt irgendwann, weil ich halt Dinge lerne und sich halt Dinge ändern.

Also deswegen mache ich ja iterativ inkrementelles Vorgehen, wie wir gerade eben diskutiert haben, oder eben sogar agiles Vorgehen, weil sich eben Dinge ändern werden.

Dann wäre es ein bisschen überraschend, wenn ich mich hinstelle und sage, das ist übrigens die Architektur.

Man sieht sich halt am Ende des Projekts das an und stellt fest, ja, das ist tatsächlich die Architektur und das ist irgendwie richtig gewesen.

Sondern man wird irgendwie etwas ändern müssen.

Und es gibt ja auch die entsprechende Propaganda dagegen.

Also Extreme Programming hat damals vor der Jahrtausendwende gesagt, dieses Big Design Upfront, also dieses übertrieben große Design Upfront als Gegenentwurf eben dargestellt, als etwas, was man eben nicht tun sollte.

Das heißt, die Abkehr davon ist eben etwas, was sozusagen programmiert wird.

Ich fand, ich hatte ja schon in der letzten Folge zum Thema sind wir Engineers gesprochen, ich fand dort spannend, dass eben andere Engineers sagen, dass wir durchaus ein bisschen mehr planen können, damit wir halt irgendwie nicht so einfach ins Chaos reintapsen.

Das bedeutet ja eigentlich, dass wir so ein bisschen, ja wie soll ich sagen, dass wir vielleicht eher zu wenig planen als zu viel.

Aber ich glaube, der Punkt ist halt immer noch, oder das spüre ich halt häufig in Trainings oder so, dass halt irgendwie so ein bisschen die Idee ist, wenn ich halt einmal eine Architektur festgeklopft habe, dann ist die halt so und dann bleibt die so.

Und wenn sie nicht so bleibt, dann habe ich halt ein Problem.

Und das finde ich halt tatsächlich schwierig und falsch.

Ich persönlich sehe eine Architektur als einen Snapshot.

Das heißt, ich habe einen Entwurf, den ich jetzt mache, zum jetzigen Zeitpunkt, von dem ich jetzt glaube, dass es sozusagen der richtige ist, den setze ich um.

Was halt wiederum bedeutet, ich will keine zukunftssichere Architektur.

Darüber habe ich auch eine Episode gemacht.

Ich verlinke das auch alles, weil ich halt glaube, dass halt zukunftssicher einen falschen Bias reinbringt.

Den Bias dahin zu sagen, ich will das halt bewahren und wenn ich es ändere, ist es halt ein Problem.

Ich glaube, dass wir Architektur nicht rechtzeitig ändern, ist eher schlecht und führt eher dazu, dass wir halt häufig diese eher suboptimalen Architekturen haben.

Und ich merke das halt manchmal, also da kommt manchmal so eine Frage mit, naja, aber wenn ich, ich erziele irgendwas über ein Architekturkonzept, baue eine Kontexte, was auch immer.

Und dann kommt dann die Frage, ja, aber wenn ich das jetzt mit dem Bau einer Kontexte nicht richtig gemacht habe, was denn dann?

Und in gewisser Weise ist das halt eine irritierende Frage, weil das Einzige, was ich halt darauf antworten kann, ist, naja, dann werde ich es wohl ändern müssen und dann werde ich wohl einen anderen Ansatz haben.

Also wenn ich es halt falsch gemacht habe und das irgendwie feststelle, dann werde ich wohl das umbiegen müssen und halt richtig hinbekommen müssen.

Ich habe das Gefühl, dass bei solchen Fragen mitschwingen, sag uns doch bitte, wie wir so eine Situation vermeiden.

Also nicht, sag uns eine geschickte Maßnahme, mit der wir halt auf jeden Fall zu einer richtigen Aufteilung im Bau einer Kontexte oder was auch immer kommen.

Wenn wir bei dem Beispiel bleiben, mit dem Bau einer Kontexte, das ist halt eine fachliche Aussage.

Wenn ich halt die Fachlichkeit falsch erfasst habe, kann es sein, dass irgendwie meine fachliche Aufteilung falsch ist, dann werde ich sie wohl korrigieren müssen.

Ich wüsste nicht, was die Maßnahme dagegen ist.

Und da gibt es, also anderes Beispiel ist halt diese Geschichte mit, ich will eine Architektur bauen, die halt möglichst gegen Änderungen resistent ist.

Finde ich auch schwierig, weil woher weiß ich, welche Änderungen kommen.

Also ist es, glaube ich, also man sollte sozusagen nicht die Augen verschließen.

Wenn ich halt sage, ich weiß, dass diese Änderung halt kommt, dann sollte ich mir überlegen, wie ich das umsetze.

Aber einfach zu sagen, ich will halt gegen Änderungen resistent sein, finde ich halt komisch, weil ich dann wahrscheinlich Flexibilität an der falschen Stelle hinbaue, weil ich eben die Änderungen nicht vorhersagen kann.

Und das stellt ja auch in Abrede, dass es halt besser ist, erstmal etwas zu bauen, dann zu schauen, ob sich das bewährt und dann die nächste Iteration zu bauen.

So wie es eben andere Ingenieure und Disziplinen auch machen.

Obwohl solche Sachen eben in der Praxis halt häufig tatsächlich irgendwie schief gehen.

Und gerade in Enterprise-Umgebungen kommen wir halt von dieser Idee, dass ich halt die Architektur festlege und dass die Architektur eben fest ist und unverrückbar, davon komme ich halt irgendwie nicht weg.

Das führt dann eben auch dazu, dass ich so eine übertriebene Architektur mache, die halt irgendwie alle Details festlegt, im Extremfall sogar mit einem Framework halt irgendwie erzwingt und die wird dann eben unterlaufen.

Die Probleme mit dieser Architektur, mit dem Architekturansatz werden dann nicht gemeldet.

Ich habe halt kein Feedback und das bedeutet letztendlich, dass ich eine zu detaillierte und halt nicht passende Architektur umgesetzt habe und eben dann sozusagen nicht lerne und halt dazu sehr versucht habe, das halt einmal festzuzogen.

So und jetzt ist halt die Frage, warum ist das so?

Also wir suchen jetzt eine Erklärung dafür, dass halt Menschen zu stark sagen, das ist die Art und Weise, wie ich das System umsetzen werde im Sinne eines Projektplans, beziehungsweise im Sinne einer Architektur, eben einen technischen Plan vorgebe.

Und dafür brauchen wir halt irgendeine Erklärung und ich glaube, das ist rational nicht erklärlich, denn meine Behauptung wäre, wenn ich halt die Retrospektive mache nach dem ersten Projekt, werde ich halt feststellen, dass in dem Projekt Änderungen gekommen sind, die ich halt nicht antizipieren kann, konnte.

Und das heißt also aus der persönlichen Erfahrung, mein zweites IT-Projekt sollte halt so sein, dass ich sage, ich kann es nicht detailliert planen, ich muss damit umgehen.

Und die Lehrmeinung, iterativ-inkumentelle Softwareentwicklung, Agilität, agile Architektur sagt ja auch, dass ich das so tun muss.

Das heißt also eine rationale Diskussion ist da halt irgendwie sozusagen da, aus der ergibt sich, dass das eigentlich halt klar ist, dass Änderungen sich nicht vermeiden, sondern dass ich damit umgehen muss.

Und das bedeutet, es muss irgendwie einen starken irrationalen Grund geben.

Also ich glaube nicht, dass wir das mit einer rationalen Diskussion erledigen können, sondern ich glaube, dass es einen irrationalen Grund geben muss.

Jetzt hat er halt der Task-Doc geschrieben, also es ist nicht planbar, weil man den Kontext nie vollständig kennen kann.

Würdest du mitgehen, dass ein Kontext besteht aus Design-Outcome-Forces und irgendwie andere Dinge?

Also ja, in gewisser Weise schon.

Ich kann den Kontext oder das, was ich umsetzen will, eigentlich nur schrittweise erfassen.

Und das bedeutet, ich muss halt irgendwie in Iterationen arbeiten.

Und ich kann es noch mal wiederholen, das ist eben etwas, wie wir allgemein überhaupt Dinge strukturiert bauen.

Also da sind wir nicht alleine, sondern das ist eben die Art und Weise, wie wir überhaupt irgendetwas auf die Reihe bekommen.

Das ist übrigens auch oft zitiert, das Beispiel Hausbau.

Also wer schon mal selber ein Haus gebaut hat, ich habe es nicht gemacht, aber ich habe es halt aus der Ferne gesehen in genügend Situationen, wird feststellen, dass der Bau am Ende nicht so gelaufen ist, wie man sich das ursprünglich vorgestellt hat.

Und das bedeutet, dass es halt irgendwie auch etwas ist, wo man halt meandert und halt irgendwie sagt, ich will halt das folgende Maß haben, feststellt, das geht halt nicht, weil die Fliesen sind nicht lieferbar oder nicht der Handwerker, der Handwerkerin hat folgenden Fehler gemacht oder was auch immer.

Und da muss man irgendwie nachjustieren.

Und das funktioniert eben bei Häusern genauso wie bei Software, würde ich behaupten.

Und wer sagt, dass man halt einen Hausbau perfekt planen kann, hat es halt irgendwie einfach noch nicht gemacht.

Also die Storys, die ich von Hausbau höre, sagen halt eher, dass es genauso strukturiert ist wie ein typisches IT-Projekt, nämlich irgendwie mäßig.

Also wir suchen irrationale Gründe dafür, dass das so läuft.

Und ich glaube, es ist in gewisser Weise menschlich, das Chaos sozusagen zu kontrollieren.

Also wenn ich irgendwie hingehe und sage, das ist etwas, was prinzipiell nicht planbar ist und was irgendwie schwierig ist und daraus die Konsequenz ziehe, dass ich halt mir das eingestehe, dann in gewisser Weise mache ich dann tatsächlich auch wohl möglicherweise einen Fehler.

Erstmal ist es halt so, dass Planung intuitiv ist. zu bekommen, wo ich eigentlich hin will und damit bin ich besser vorbereitet auf die Situation.

Aber das ist eben etwas, was ich halt überarbeiten werde.

Und wie gesagt, wurde hier als extrem versagt, dass man eigentlich Schätzungen zumindest hat keinen Sinn haben.

Mal kurz gucken, was der Marc M. geschrieben hat.

Genau, der schreibt, dass Teams erst mal entdecken, was sie bauen müssen und zum anderen eben tatsächlich das Bauen.

Und das ist halt genau das, worum es eigentlich geht.

Also, dass ich irgendwie erkennen muss, wo es hingeht.

So, und wie gesagt, der Gegenspieler ist meiner Ansicht nach eben dieser Drang nach Kontrolligkeit ist für natürlich und nachvollziehbar, dass man halt sagt, okay, ich fange jetzt irgendwie an zu planen und das impliziert halt, dass man es vielleicht dann auch mal übertreiben könnte.

So, der Christoph schreibt halt, oft besteht bei AuftraggeberInnen die Sorge, dass sich die Entwicklung ohne einen klar definierten Leistungsumfang unkontrolliert ausweiten könnte.

Ja, aber Agilität hat darauf ja eine Antwort.

Das heißt also, ich sage bei Agilität, ich liefere dir ständig Software, die hat funktioniert, die kannst du benutzen und ich baue die nur weiter, wenn du mir sagst, was ich als nächstes bauen will.

Und du kannst es jederzeit benutzen.

Und wer schon mal ein Softwareprojekt gemacht hat, der wird, glaube ich, dankbar, also wer schon mal ein Softwareprojekt gemacht hat, das am Anfang gesagt hat, wir planen genau das und dann irgendwie kurz vor Schluss des Projekts festgestellt hat, das kriegen wir halt nicht hin, sollte dankbar sein dafür, dass er halt Software bekommt.

Die hat tatsächlich funktioniert und die in Produktion nutzbar ist.

Und das ist ein Risikomanagement-Ansatz, der im Prinzip funktioniert.

Das heißt also, wenn ich einmal die Erfahrung gemacht habe, dass ich mit einem durchgeplanten Projekt genauso gegen die Wand fahre und das tue ich halt, müsste die Konsequenz sein, dass ich eben sage, super, bitte liefer mir das, was ich gerade brauche, das bringe ich in Produktion, damit kann ich arbeiten und dann lasse ich halt weiterarbeiten.

Und das, was ich aber in Produktion habe, das ist schon mal sicher da und das kann ich halt verwenden.

Das ist genau die agile Sache.

Aus irgendwelchen Gründen ist aber dann bei den Kunden eher die Vorstellung, ja, ich muss halt mehr planen und das noch sicherer machen und noch detaillierter planen.

Das ist halt genau der Vielplan.

Ich kann mir vorstellen, dass Purpose etwas ist, das man kontrollieren könnte.

Ja, also es gibt diese, ich habe leider es nicht geschafft, irgendwie dazu eine Episode zu machen, aber es gibt halt irgendwie diese Aussage, die sagt, Menschen können erst dann sinnvolles Feedback geben, wenn sie sozusagen etwas haben, was vor ihnen steht und dann können sie auf Basis dessen halt irgendwie sagen, nee, das ist halt nicht in Ordnung, ich brauche eigentlich das.

Das ist so ein bisschen wie dieses Apple-Phänomen, also ich wusste nicht, dass ich ein iPhone haben will, bis ich halt das erste Mal ein iPhone gesehen habe.

Das heißt, wenn man mich fragt, was möchtest du haben, na ja, ein Telefon mit Tastatur und ein paar tollen Features und ich würde eigentlich das iPhone haben wollen.

Das heißt, ich kriege das halt erst mit, dass das halt etwas ist, was ich haben will, wenn ich es gesehen habe.

Das heißt, dieses Sehen, interaktiv ausprobieren, das führt erst dazu, dass ich halt neue Requirements habe.

Das ist prinzipiell unvermeidbar und das kann ich halt nicht vorher antizipieren, weil ich halt die Software dafür benötige.

So, und ich glaube, also um sozusagen zurückzugehen zu diesem, warum planen wir denn doch oder warum haben wir so viel Architektur?

Ich glaube, dass man sozusagen das Gefühl haben will, dass man halt diese unklareren und risikoreichen Dinge durchdrungen hat und dann fühlt es sich halt weniger risikoreich an.

Und ich glaube, das ist halt für mich der wesentliche Treiber.

Ich fühle mich also wohler, weil ich halt irgendwie das geplant habe und ja das Gefühl habe, dass ich mich damit ernsthaft auseinandergesetzt habe.

Und der Plan wird ja auch funktionieren.

Mehr planen wird irgendwie besser sein.

Aber das ist eben eine Illusion und deswegen hatte ich diesen Begriff von dem Illusionen der Kontrolle.

Also ich versuche halt durch mehr Planung, durch mehr Architektur, durch mehr Architekturarbeit, durch das Antizipieren von möglichen Änderungen halt zu glauben, dass ich das kontrollieren kann.

Und dass ich halt diesmal die vielen Änderungen und das Chaos, was ich beim letzten Projekt erlebt habe, dass das nicht passieren wird.

Und das ist halt ein Trugschluss.

Ich muss halt eigentlich damit leben, dass ich eben nicht alles antizipieren kann und ich muss eben feingranular vorgehen und halt irgendwie iterativ irgendwelche Sachen bauen, von denen ich halt ein Feedback bekomme und dann weiter machen.

Also und ich vermute oder glaube, dass das in anderen Ingenieursdisziplinen auch nicht anders sein wird.

Ein erster Prototyp hat halt die Gefahr, dass er überhaupt gar nicht funktioniert.

Und dann brauche ich halt die nächsten, die nächsten und die nächsten, bis ich dann irgendwo an der Stelle angekommen bin, wo es sozusagen einigermaßen funktioniert.

Damit könnte man jetzt eigentlich die Episode beenden, weil ich habe irgendwie jetzt eigentlich gesagt, also diese Illusion der Kontrolle, was ja auch der Namensgeber ist.

Das ist der Grund, weswegen wir das tun.

Und in gewisser Weise hat das halt auch was für sich.

Dann haben wir eine halbe Stunde gewonnen.

Aber ich glaube, da gibt es halt noch weitere Aspekte.

Und ein weiterer Aspekt ist halt dieser soziale Druck.

Habe ich das überschrieben?

Das heißt also und das ist mir hat irgendwie passiert.

Vor längerer Zeit, vor langer Zeit, wo halt jemand auf Kundenseite gesagt hat und dann kriegen wir ja bestimmt noch ein Feinkonzept und wenn er kein Feinkonzept liefert, dann haben wir ja irgendwie noch ein ganz anderes Problem, wo dann, glaube ich, explizit oder implizit sozusagen impliziert wurde.

Wenn wir das halt nicht tun, dann sind wir halt irgendwie unprofessionelle Software Entwickler.

Und in dem Kontext war es halt so, dass wir bereits einen Prototypen geliefert hatten.

Also wir hatten schon eine erste Iteration, die halt wesentliche Konzepte und technische Risiken halt erledigt hatte, sodass das eigentlich schon in die iterative Richtung ging und eigentlich schon Vertrauensverhältnis da sein sollte.

Aber es wurde halt dadurch eben genau dieser soziale Druck aufgebaut.

Vielleicht auch so ein bisschen das, was der, was der Christoph Keime gerade eben gesagt hatte, in dieser Richtung nicht, dass halt im Kundenverhältnis dann solche Sachen auftauchen.

Und dadurch ist man jetzt mit dem Druck ausgesetzt, dass man halt dieses richtige, scheinbar ingenieursmäßige Vorgehen ja nun verfolgen muss.

Und wenn man das nicht tut, ist man eben chaotisch und unprofessionell.

Und dadurch kommt ein sozialer Druck zustande.

Und ich glaube, das führt dann auch zu einer Absicherungsgeschichte.

Also in der Situation ist es dann, glaube ich, sehr schwer zu sagen, wir machen halt kein Feinkonzept.

Wir implementieren jetzt erst mal die erste Iteration.

Daraus ergibt sich eine Architektur.

Wir machen uns natürlich Gedanken darüber, wie es langfristig aussehen soll.

Aber wir werden halt wahrscheinlich dieses Konzept mehrfach überarbeiten und da schrittweise vorgehen.

Und ich glaube, also wenn ich jetzt in einem Projekt, nachdem sich die ja prinzipiell nicht detailliert, meiner Ansicht nach, planen oder eine detaillierte Architektur umsetzen kann, wird wahrscheinlich auch mit viel Planung und Architektur rauskommen.

Ups, das ist jetzt krass und überraschend.

Also es gibt dieses Beispiel, wo eben ein Prototyp gebaut worden ist für eine schrittweise Migration.

Sehr teuer und dann eben sich sehr schnell herausgestellt hat, dass so eine schrittweise Migration, so wie man sich das überlegt hat, halt nicht sinnvoll war.

Weil man dann eben nicht konstant Geschäftswert generieren kann.

Und das war eigentlich das Ziel des Projekts.

Und das ist genau so ein Ups, da haben wir halt irgendwie überraschend jetzt festgestellt, dass wir halt das Projektziel, konstant Business-Wert zu generieren, mit dieser Art von schrittweiser Migration so nicht umsetzen können.

Wenn ich jetzt aber eben den Prototypen gebaut habe und eine exzessive Planungsphase, Architektur-Phase gehabt habe, kann ich halt sagen, aber ich habe mich ja professionell abgesichert und vorbereitet.

Und ja, also wenn ich da geschickt bin, kann ich irgendwie sagen, und diese Änderung oder dieses Thema konnte ich halt nicht antizipieren.

Das ist dann scheinbar besser, vielleicht individuell, also für den Menschen, der es halt tun muss, als wenn man irgendwie da weniger Planung gemacht hätte, das Problem vielleicht früher bekommen hätte und halt vielleicht auch früher gelöst hätte.

Und das ist ja wie so eine soziale Komponente.

Ich kann halt irgendwie sagen, ich habe mich halt damit intensiv beschäftigt.

Wir haben Prototypen gebaut, wir haben ganz viel uns überlegt und dann stellt man halt irgendwie fest, ja, das ist irgendwie schiefgegangen und dann ist irgendwie vielleicht sogar intuitiv der Weg nachvollziehbar, dass man sagt, naja, da muss ich mich beim nächsten Mal irgendwie noch stärker absichern und noch stärker schauen, dass ich eben nicht in so eine problematische Situation reinkomme.

Und das ist eben dann sozusagen der Punkt.

So und da irgendwie jetzt zu sagen, nee, also wir planen halt weniger und wir machen halt nur für so viel Planung, wie wir halt wollen und wir planen irgendwie nur die nächsten paar Iterationen und versuchen halt, darüber flexibel zu bleiben.

Das ist eben dann kontraintuitiv, das bedeutet auch, dass ich mich halt weniger absichere und er führt eben wie zu, glaube ich, Unsicherheit, die man hat, die man hat sozusagen abkönnen muss.

Also eben zu der Unsicherheit.

Haben wir denn an alles gedacht?

Nee, haben wir halt nicht.

Aber das kann ich prinzipiell eben auch nicht.

Was, wenn es halt nicht funktioniert?

Naja, da muss ich halt irgendwie nachsteuern.

Das kann ich halt, wenn ich es später mache, mehr Information machen, ist also eigentlich der bessere Weg, als zu versuchen zu antizipieren.

Und ich stelle mich, ich setze mich halt dieser Kritik aus mit, daran hätte man halt denken können, nicht?

Also das Projektziel mit der Architektur nicht vereinbar ist, also Geschäftswert schaffen, dass das nicht vereinbar ist mit dem schrittweisen Migrieren, das hätte man halt tatsächlich, das hätte man sich denken können.

Aber dann ist das nächste Thema, woran man irgendwie nicht denkt, wenn man das halt erwischt hat, dann hat man das nächste Problem.

Das heißt also, eigentlich muss man irgendwie sagen, nicht, ich kann halt nicht an alles denken.

Es ist nicht möglich, das halt alles vor Start des Projekts zu planen.

Ich muss mich halt mit einer gewissen Unsicherheit in das, reinbegeben in das Projekt und damit halt leben.

Und auch da ist halt so eine Illusion, nicht?

Es ist halt die Illusion, dass man hat das alles am Anfang irgendwie antizipieren kann und hat alle Änderungen, die halt kommen, sich halt überlegen kann.

Aber das ist irgendwie, und ich glaube, das ist wieder eine Sache, die eigentlich rational klar ist, aber wo es eben einem so dieses wohlige Gefühl gibt, dass man halt nicht sich angestrengt hat, wenn man eben diesen Weg von der teilweise existenten Planung halt geht.

Marc schreibt, man kann nicht das Leben kontrollieren, man kann nur die Rahmenbedingungen setzen.

Wenn man selbst keine Termine macht, dann setzen andere einen Kontrolltermin.

Wie gehe ich mit solchen Management Methoden um?

Ja, es gibt ja Progress, nicht?

Also ich sehe ja, was geliefert worden ist und das ist ja so ein bisschen der Punkt, weswegen ich halt der Meinung bin, dass das halt irrational ist.

Der Progress ist halt unabstreitbar.

Also Software in Produktion ist halt wirklicher Progress, weil Leute halt diese Systeme nutzen können und alles andere, dass sie genau dieser Indikator mit nicht nur Working Code ist halt ein Progress Indikator.

Das hat ja was für sich.

Also wenn ich eine Planung gemacht habe, weiß ich nicht, ob die Planung funktioniert, weil das ist eine Planung, das ist halt auf einem Stück Papier.

Code, die Menschen benutzen, da weiß ich, dass er funktioniert.

Meiner Ansicht nach ist also eine Risikovermeidung Strategie und das ist genau das, was Agilität sagt, möglichst schnell produktiven Code hinzubekommen.

Und das geht für Architektur eigentlich ähnlich.

Wenn ich halt die Architektur umgesetzt habe und irgendjemand benutzt sie und das läuft halt als Software, dann habe ich eben Feedback, dass ich einarbeiten kann in meiner Architektur und komme da schrittweise weiter und bin da halt schrittweise sozusagen sauber.

Und da habe ich ja was vorzuweisen.

Und also ehrlich gesagt, ist eben tatsächlich die Frage, warum halt ein Packen PowerPoint oder Architektur Dokumentation oder was auch immer Requirements oder ein Projektplan.

Warum hat irgendjemand, der schon mal ein Softwareprojekt gemacht hat, halt glaubt, dass das halt sagt, dass das erfolgreich sein wird?

Also das ist ja genau der Punkt, weswegen ich sage, es ist eben irrational, würde behaupten, spätestens beim zweiten Projekt weiß man halt, der ursprüngliche Plan funktioniert nicht und die ursprüngliche Architektur funktioniert nicht.

Ich würde behaupten, das kriegt man in einer Retro raus.

Aber ich lasse mich halt, lasse mich da auch gerne eines Besseren überzeugen.

Aber da würde mich halt das Projekt über interessieren, wo man irgendwie sagt, okay, cool, wir haben halt am Anfang geplant, hat alles super funktioniert, genauso wie wir geplant haben.

Toll, gibt es halt nicht.

So, ein Realist schreibt, deswegen kommitte ich mich nicht mehr auf Termine oder Zeiträume, wenn die von anderen festgelegt werden, laufen die halt auf, wenn es schief geht.

Ja, bin ich mir eben nicht so sicher.

Also das ist so eine Frage und ich glaube, über die kann man auch nochmal reden.

Ich habe die gar nicht so aufgenommen, aber das ist ein guter Punkt.

Die Umgebung, also eigentlich passt das zu dem sozialen Druck nicht, also die Umgebung sagt uns, wir wollen wissen, wann wir genau das geliefert bekommen.

Das ist dieser soziale Druck.

Und die Termine kann man ja tatsächlich kommitten, also ich kann ja sagen, dass ich zu bestimmten Zeitpunkten Software haben werde und dass die halt irgendwie in Produktion ist.

Und ich kann mich nicht auf den Scope kommitten, der aber eh etwas ist, was sich halt ändern wird.

So und von daher, diese Kombination aus Scope und festem Termin, das ist eben das, was halt teuflisch ist.

Die Termine alleine, da kann ich etwas machen und da kann ich auch irgendwie ein Ergebnis sozusagen vorweisen.

Eine Realist schreibt halt weiter und ich kommitte mich nur auf Funktionen und je kleinteiliger, desto besser die Kontrolle durch jene, die sie haben wollen.

Ja, also wir kommitten uns ja.

Also ich glaube, diese Episode mit Woody ist da irgendwie interessant, weil überhaupt jetzt irgendwie mal zu sagen, brauchen wir eigentlich überhaupt Schätzung?

Ist es nicht einfach so, dass wenn wir halt jederzeit an dem Wertvollsten arbeiten, dass wir dann eben das Ergebnis so schnell erreichen, wie wir es halt können?

Ist eine interessante Frage und ich weiß nicht, ob ich das hier im Stream schon mal erzählt habe.

Ich habe auf den XP Days in Stuttgart mit jemandem diskutiert, der von einem interessanten Phänomen berichtete, nämlich von dem Phänomen, dass er in diesem Projekt gesessen hat.

Es gab halt Andauerndeadlines und Zeitdruck und irgendwann war er der verantwortliche Manager und hat gesagt, ich weiß nicht, wie lange es dauert.

Und das war halt akzeptabel.

Also dann waren die Deadlines plötzlich weg und dann hat jemand anders die Rolle wieder übernommen und dann sind da plötzlich wieder Deadlines da gewesen.

Also die Frage ist halt, wie deadlineig diese Deadlines eigentlich sind.

Also muss ich und da ist vielleicht auch wieder die Illusion von Kontrolle.

Wenn ich jetzt also sage, zu diesem Termin möchte ich gerne das haben, habe ich halt eine Ansage gemacht und glaube, dass ich das kontrollieren kann.

Das ist aber etwas anderes als eine Deadline, die sagt, okay, wenn wir zum Start der Fußball-EM unsere Software nicht haben, dann ist unser Business Case weg.

Das ist was anderes.

Also da habe ich halt tatsächlich dann sozusagen eine harte Deadline und es kann gut sein, dass viele von den Deadlines eben auch wegen dieser Illusion von Kontrolle sind, um ja zu sagen, also das will ich jetzt und ich kontrolliere, ob das nicht passiert.

Und dadurch habe ich eben das Gefühl, diese problematischen Projekte halt sozusagen auf die Reihe zu bekommen.

Genau, da steht Funktion, aber wir reden ja von Modern Context, also wir reden halt von Scope, irgendwelche Funktionalitäten, whatever.

Genau, und da kommt jetzt übrigens, passt gut zu dem nächsten Punkt, den ich mir aufgeschrieben habe, diese scheinbare Kalkulierbarkeit, diese Geschichte mit den Festpreisprojekten.

Also es gibt ja irgendwie die Idee, dass ich eben sage, ich habe irgendwie einen Scope, das bepreise ich, dann implementiert das halt irgendjemand und dann habe ich eine Kontrolle.

Und das eine, was halt irgendwie zuschlägt, hatte ich schon gesagt, den Scope, den ich ausschreibe, ist wahrscheinlich nicht den Scope, den ich tatsächlich haben möchte.

Und das andere ist halt, das ist eben auch nur eine Illusion von Kontrolle, weil wenn man halt gefressen hat, dass die Requirements nicht vollständig und korrekt sein können und das können sie halt de facto nicht sein, dann bedeutet das halt, dass der Dienstleister, die eben, wenn der sozusagen fies ist, halt anfängt und halt sagt, okay, das stand halt in den Requirements nicht drin, das liefere ich gerne, das wird nur absurd teuer.

Sondern ist halt der Festpreis eine Illusion, die halt kassiert wird dadurch, dass eben der Scope eben nicht festlegbar ist und das arbeitet in diesem Fall für den Auftragnehmer, der es halt liefern soll zu einem festen Preis, in dem der Auftragnehmer halt sagt, das ist nicht Teil von dem Scope und das wird jetzt teuer.

Und dann ist das eben nicht kontrollierbar.

Also dann hat man eben diese Illusion von Kontrolle, weil dann das Budget überschritten wird oder man hat Software bekommt, die das Problem in Wirklichkeit nicht löst.

Und das, deswegen ist das eben genau eine Illusion von Kontrolle.

Genau, Mark schreibt, es gibt Ausschreibungen und es gibt doch auch Abnahmen.

Das ist doch schlussendlich wirklich etwas, das ich kontrollieren kann.

Ja, ich kann kontrollieren, ob die Software halt die Requirements erfüllt, die ich halt irgendwie bei der Ausschreibung abgegeben habe.

Das sind aber dann eben nicht die Requirements, die ich eigentlich in Wirklichkeit brauche.

Und dann habe ich halt sinnlose Software.

Das bringt mir also dann nichts.

Und dann habe ich eben die Change Requests und die werden dann teuer.

So eben der Punkt.

Also außer du bist halt in dem Projekt, das halt als erstes schafft, die Requirements vollständig widerspruchsfrei und korrekt aufzuschreiben.

Dann würde ich halt von dem Projekt gerne mehr hören, weil mich würde interessieren, wenn man das dafür nicht triviales Projekt hinbekommt.

Also funktioniert üblicherweise nicht.

Ich glaube, es gibt noch ein weiteres Thema, warum diese diese Illusion von Kontrolle etwas ist, was hat angestrebt wird.

Und das habe ich mir aufgeschrieben als ein fundamentales Unverständnis darum, worum es bei Softwareentwicklung eigentlich geht.

Also wir kennen ja Industrie.

Also ich kann jetzt in den Laden gehen und kann mir ein Auto kaufen.

Das wird halt im Extremfall sogar für mich produziert.

Und das ist fest bepreist.

Und die Firmen, die das machen, können das auch klar kontrollieren.

Und da gibt es ein industrieller Fertigungsprozess, der ist vorhersagbar.

Und letztendlich baue ich dann eine Fabrik, die diese Autos fabriziert. die Fabrik.

Denn was wir bauen, ist Software, die eben Dinge unterstützt, automatisiert, Geschäftsprozesse unterstützt, sowas.

Und ein Geschäftsprozess ist ja beispielsweise, bauen wir mal ein Auto und die Fabrik setzt eben diesen Geschäftsprozess um.

Das ist das, was wir bei Softwareentwicklung machen.

So die Vorhersage darüber, wann die Fabrik fertig ist, ist wieder schwierig und die sind irgendwie auch Einzelstücke, genauso wie Häuser eben typischerweise Einzelstücke sind.

Softwareentwicklung als Lernprozess

Und ich habe eine Episode gemacht, wo ich eben auch gesagt habe, dass halt Softwareentwicklung eigentlich eher Lernen ist.

Das ist also ein Lernprozess und das klang vorhin auch in den Fragen irgendwie schon an.

Also das heißt, ich lerne was über die Domäne, ich lerne was über das Problem, ich lerne was über die Technologien.

Ich habe auch technologischen Fortschritt, da muss ich dann irgendwie auch was über den technologischen Fortschritt lernen, nicht die nächste Version von meinem Framework.

Ich lerne was über die Architektur, ich lerne was über Architekturvorgehensweisen.

Das heißt, nicht nur die Anforderungen und die Domäne sind Dinge, die ich kennenlerne, sondern auch Sachen darüber hinaus.

Knowledge Crunching

Und Domain-Driven Design beschreibt sich selber halt auch als Knowledge-Crunching im Gegensatz zu Number-Crunching.

Also Crunching ist eben so, was ich nicht zermahlen oder so.

Und Number-Crunching ist das, was halt Supercomputer tun, dass sie halt irgendwie nicht Zahlen zermahlen und da halt irgendwie tolle Berechnungen machen, für Wetterfeuersorge oder was auch immer.

Und die Aussage von Domain-Driven Design aus dem originalen blauen Buch ist eben, dass wir Knowledge-Crunching machen, dass wir also sozusagen Wissen verarbeiten.

Das Wissen über die Domäne versuchen wir zu strukturieren und daraus eben eine Software zu bauen.

Und das impliziert ein Lernprozess, der halt unterstützt wird durch solche Verfahren wie kollaborative Modellierung, also Event-Storming oder so, wo ich ja Menschen zusammenzwinge, TechnikerInnen und Domain-ExpertInnen, die gemeinsam dann eben die Domäne kennenlernen sollen.

Und das ist eben ein, also die Domain-ExpertInnen wissen, was da draußen fachlich passiert.

EntwicklerInnen, TechnikerInnen lernen das, können es strukturieren und geben vielleicht auch Feedback, das bei den Domain-ExpertInnen zur Reflexion führt.

Also warum ist denn das so?

Welchen Sinn hat das?

Das kann dazu führen, dass man es näher erläutert oder dass man halt realisiert, dass die Prozesse eigentlich unsinnig sind und so weiter und so weiter.

Und Lernen, würde ich behaupten, lässt sich halt nicht wirklich planen.

Ich weiß ja nicht, was ich am Ende gelernt haben werde und wie die Domäne und die idealen Dinge sozusagen aussehen.

Das ist ja irgendwie ein strukturierter Prozess, der dazu führen soll.

Das bedeutet, dass das Ergebnis halt inhärent unsicher ist und das entzieht sich dann eben in gewisser Weise eben einer Planung.

Also wenn wir gemeinsam loslaufen und versuchen, das irgendwie zu entdecken, wie die Domäne aussieht, wie wir sie umsetzen können, dann können wir nicht sagen und lass uns das bitte so und so schnell machen oder beschleunigen oder sowas, sondern das ist eben ein Lernprozess und der ist eben nur bis zu einem gewissen Maße lernbar.

Jetzt ist halt die Frage, also soweit ist das ja sozusagen eine philosophische Geschichte, die halt irgendwie im Prinzip sagt, das was wir tun entzieht sich eben einer Kontrolle, einer detaillierten Planung und benötigt halt iterativ-inkrementelles Vorgehen.

Ich will irgendwie Architektur iterativ-inkrementell verbessern, will da irgendwie besser werden.

Auch beim Vorgehen will ich das halt irgendwie und das ist so das, wo es irgendwie hingeht.

Und jetzt ist die Frage, wie kommen wir dahin, dass wir das in einer größeren Zahl von Projekten umsetzen.

Und eine Möglichkeit wäre ja jetzt eine rationale Diskussion zu führen, also zu sagen, hör mal zu, guck dir die Episoden an, die ich gemacht habe über das Wasserfallmodell, das eben nicht existiert.

Guck dir die Episode darüber an, wie Engineering tatsächlich funktioniert.

Guck dir diese ganzen Sachen an, auch das Interview mit der Professor Christiane Floyd.

Und nicht stelle halt irgendwie fest, dass wir halt iterativ-inkrementell vorgehen müssen und dass wir eben das nicht komplett vollständig planen können.

Ich glaube, dass das nicht hilft, weil ich glaube, dass der Hauptmotivator dafür, dass das halt immer noch passiert, ein psychologischer sein muss.

Diese rationale Diskussion dauert für mich zu lange an.

Also die Frau Professor Floyd hat halt in den 60ern mit dem Thema angefangen, das heißt, das Thema ist irgendwie älter als ich.

Ich schlage mich jetzt irgendwie immer noch damit herum.

Das heißt also, diese rationale Diskussion, da müssten wir halt schon lange durch sein.

Also das müsste halt irgendwie sozusagen gefressen sein.

Ich glaube, das ist ein psychologisches Spiel.

Die erste Sache, die für mich halt immer wichtig ist, und deswegen summiere ich auch so ein bisschen, ich habe das Gefühl, nachdem ich ein bisschen über die Episode nachgedacht habe, dass die Episode so ein bisschen aufsummiert, was halt in verschiedenen anderen Episoden halt ich implizit gesagt habe, aber nicht so explizit.

Also ich habe gesagt, nicht Softwareentwicklungslärmprozess, es gibt das Wasserfallmodell nicht, ich will keine zukunftssicheren Architekturen.

Und ich glaube, die habe ich halt alle deswegen gemacht, weil ich halt eigentlich möchte, dass wir in unserer Community jetzt erst mal festhalten, wir müssen damit rechnen, dass das, was wir als Plan haben, sei es ein Architekturplan oder halt ein Vorgehensplan, revidiert werden muss und dass wir das halt ändern müssen.

Und dass eben ein Plan, der Wasserfall macht, der so sagt, wir haben halt Requirements und das setzen wir halt irgendwie um und die Requirements bleiben sozusagen fest, dass der halt irgendwie absurd ist und dass das halt auch niemals irgendjemand sinnvoll fand.

Und das ist erst mal etwas, was wir sozusagen in unserer Community klar bekommen müssen.

Und da gibt es halt glaube ich noch ein wichtiger Punkt, das ist halt diese Geschichte mit dem, was ist exzessiv.

Also es ist glaube ich dumm zu sagen, ich hacke jetzt mal los.

Und das wird schon funktionieren.

Das heißt, Planung und irgendwie sich eine Idee entwickeln und das Thema irgendwie durchdringen, macht halt Sinn.

Und ich finde da halt irgendwie interessant, dass halt eben Hillel in seiner Episode gesagt hat, dass wir eher da vielleicht auf der Seite sind, gerade im Architektursektor, ich weiß nicht, wie es halt im Planungsbereich und bei der Realität aussieht, aber gerade im Architektursektor vielleicht irgendwie diejenigen sind, die halt irgendwie weniger Plan haben oder zu wenig Plan haben, aber sei es drum.

So, wenn wir aber jetzt feststellen, dass das das Problem ist, was wir in der Branche haben, dass wir also dazu tendieren, übertrieben viel Aufwand zu betreiben in diese Bereiche, dann bedeutet das, dass wir auf diese psychologische Ebene wechseln müssen und halt schauen müssen, was da halt los ist.

Also jetzt muss ich mal sehen, was hat Tasklog geschrieben?

Vorschlag, wenn die Ausschreibung und die Abnahme für ein SCS wäre, der ein Request abarbeiten soll, würde ich als Vertragsansatz eine allgemeine Anforderung definieren können, wenn bei der Ausschreibung alles Domänenwissen mitgeliefert wird.

Ja, geht halt nicht.

Das ist ja der Punkt, nicht?

Also ich behaupte ja eben, also das ist genau einer von den Punkten, die ich halt irgendwie gerne mal festhalten würde, von denen ich halt glaube, dass wir uns die halt mal, also nicht, das ist etwas, was halt allen Leuten ja professionelle Software entwickeln, klar sein soll, man kann nicht Requirements ausführlich, fehlerfrei, widerspruchsfrei, eindeutig formulieren.

Es geht halt einfach nicht.

Es ist etwas, wo ich halt die revidieren muss und wo halt Missverständnisse drin sind und wo ich halt irgendwie schauen muss, dass ich mit Menschen darüber rede und ein Feedback bekomme.

Wenn wir das könnten, wäre das Problem alles gelöst.

So, was steht da noch?

Ich glaube, das ist ein extrem spannender Punkt.

Inwieweit kann ich Domänenwissen selbst ausliefern, so dass die Architekten oder Programmierer das nur noch umsetzen müssen?

Kann ich nicht, deswegen gibt es kollaborative Modellierung, die halt sagt, man sperrt die Menschen halt direkt in einen Raum und sorgt halt, also nicht in einem virtuellen Raum, sorgt halt dafür, dass die halt irgendwie miteinander reden können.

Wenn wir halt das Domänenwissen formal korrekt aufgeschrieben haben, weil das Programm und dann ist die Sache halt irgendwie durch.

Das heißt also, wenn wir dazu in der Lage sind, das halt auszuliefern, das Domänenwissen und das irgendwie fehlerfrei und so weiter zu machen, dann sind wir eigentlich schon bei dem Programm.

Und dann möchte ich also ein Reddit schreiben, Storytelling ist für mich eines der besten Tools, um gemeinsam mit Strehkultern AG Software zu entwickeln.

Scope ist ständig verhandelbar und anpassbar.

Event-Storming gehört im Jahr auch dazu und nicht agile Planung und so.

Und die Strehkulter wissen, wie viel Zeit sie in Scope investieren wollen.

Also das ist, glaube ich, auch ein wichtiger Punkt, Scope festzulegen.

Das ist halt auch etwas, was Zeit kostet, dass wir diese neue Estimates folgen.

Christoph Keimel bestätigt mich gerade so ein bisschen.

Sehr guter Punkt, das deckt sich auch mit meiner Wahrnehmung.

Ich komme mit rationalen Argumenten auch nicht weiter.

Für mich ist dann eigentlich der Punkt sowas wie, also ich habe mir aufgeschrieben, im Kern eine vernünftige Fehlerkultur.

Also was das hier bedeutet ist, wenn ich jetzt sage, das ist der Scope, das ist die Architektur, dann wird das insofern fehlerhaft sein, als dass ich es anpassen muss.

Wenn ich jetzt bei der Anpassung zu hören bekomme, du hast einen Fehler gemacht, das ist für mich großer Quatsch, bitte mach das beim nächsten Mal nicht.

Sorg dafür, dass ich da sofort den richtigen Ansatz bekomme.

Dann ist das kontraproduktiv.

Besser ist es zu sagen, okay, schön, dass wir es jetzt gemerkt haben.

Lass uns umplanen und schauen, was wir tun können.

Das ist, glaube ich, der Kern der ganzen Geschichte.

Das heißt, ich muss eine solche Umgebung feststellen.

Dazu gehört für die Leute, die es sagen, die sagen, wir haben ein Thema und das passt nicht, die müssen Mut haben, das zu sagen.

Es muss diese Psychological Safety geben, also die psychologische Sicherheit.

Also eine Umgebung, wo ich mir das Gefühl habe, dass ich es sagen kann und nicht idealerweise mit dem Feedback, danke, dass du es gesagt hast und schön, dass wir darüber reden und nicht einen Schmerzensschrei oder sowas, sondern eben sowas in der Richtung.

Sonst komme ich in den Bias, das Vorgehen, was ich gewählt habe zu verteidigen und als sinnvoll und erfolgreich darzustellen, was bedeutet, dass es eher diese Anpassung verzögern wird.

Das führt, glaube ich, in vielen Fällen dazu, dass eine Architektur nicht passt, weil ich sie eben nicht angepasst habe.

Anders gesagt, und ich glaube, das ist auch ein wichtiger Punkt, wir müssen uns eingestehen, dass diese Kontrolle anzustreben eine natürliche und nachvollziehbare Reaktion ist.

Ich habe einmal diese Geschichte mit dem Feinkonzept erzählt, wo dieser soziale Druck bestanden hat und wo ich auch den Bedarf verspürt habe, so ein Feinkonzept zu schreiben.

Ich bin grundsätzlich einfach nicht der Mensch danach, der es tun würde.

Ich merke es auch sonst, dass es schwierig ist, mit dieser Unklarheit zu leben.

Es ist einfach schwierig, in der Umgebung zu sein und zu sagen, ja, ich weiß, dass ich das alles nicht weiß.

Ich weiß, das ist super kompliziert und schwierig.

Ich weiß, dass ich es nicht durchdrungen habe.

Ich mache jetzt trotzdem weiter und ich gestehe mir halt ein, dass ich erst mal etwas produzierendes ausprobiere und dann mit dem nächsten Schritt weitergehe.

Das ist etwas, was viel unangenehmer ist, als sich hinzustellen und zu sagen, ich plane das und ich denke das durch, weil ich ja dadurch auch keinen Vierschlag produziere.

Also den Plan, den ich aufstelle, aber nicht durchführe, kann nicht schief gehen, weil der steht auf dem Papier.

Der andere Gedanke, der mir dabei kommt, ist, ist das mit dieser Illusion der Kontrolle eigentlich überhaupt ein Fehler?

Also einmal ist es halt so, dass ich mich dadurch absichere.

Das hatte ich ja bei diesem sozialen Druck gesagt.

Ich kann dann irgendwie sagen, okay, in dieser Umgebung, in der die Fehlerkultur schlecht ist, ich habe es halt probiert.

Ich habe halt geplant.

Ich habe mir halt echte Gedanken gemacht, dass es schief gegangen ist.

Liegt nicht an mir.

Und ich glaube, dass man mir dann eigentlich keinen Vorwurf machen kann, sondern dass ich mich sozusagen rational eben da verhalte.

Und das ist halt so ein bisschen auch der andere Punkt.

Also die andere Frage, ist das eigentlich überhaupt ein Fehler?

Also ich bin jetzt in einer Umgebung, in der ich Software entwickeln muss.

Diese Umgebung ist in einer bestimmten Art und Weise strukturiert.

Also zum Beispiel eine schlechte Fehlerkultur.

Und er verlangt halt von mir als Architekt, dass ich mich halt in einer bestimmten Art und Weise eben da verhalte und halt irgendwie absichere.

Und dann ist so ein bisschen die Frage, ob ich nicht in der Situation bin, wo ich eigentlich nur die Wahl habe zu sagen, ich arbeite so.

Also ich biete die Illusion der Kontrolle.

Oder ich kann das Projekt nicht durchführen.

Oder dritte Option, ich ändere halt die Kultur des gesamten Unternehmens, in dem ich irgendwie arbeite.

Und wie soll ich sagen, also in der optimalen Welt würde ich versuchen, die Kultur zu ändern von dem Unternehmen, in dem ich arbeite, um dafür zu sorgen, dass ich eine vernünftige Fehlerkultur habe.

Aber ich kann sozusagen niemanden strikt daraus drehen, wenn die Person sagt, ich will halt irgendwie Software entwickeln.

Das bedeutet, ich entwickle jetzt Software.

Und das eben so in einer Art und Weise, dass es halt in der Umgebung, in der ich mich wiederfinde, funktioniert.

Und das bedeutet, ich biete halt diese Illusion der Kontrolle, obwohl ich weiß, dass es eben nur eine Illusion ist.

Finde ich einen nachvollziehbaren Ansatz, weil ich eben tatsächlich auch nicht so ganz sicher bin, was denn eigentlich die Alternative ist.

Die Alternative wäre halt, das Unternehmen und die Umgebung grundsätzlich zu ändern.

Und ja, das kann ich halt parallel tun.

Also insbesondere ich als Berater werde dafür eigentlich auch bezahlt und mache das halt auch sehr gerne.

Aber ich finde es halt auch okay zu sagen, ich will halt einfach Software entwickeln und das ist es halt.

Es ist über das Formular noch ein Hinweis eingegangen.

Da war der Hinweis, der Grund, warum rationale Argumente keine Berücksichtigung finden, ist, dass Softwareprojekte oftmals mehr politisch als inhaltlich getrieben sind.

Also die Fachlichkeit hat eine untergeordnete Rolle.

Das finde ich, ist ein guter Punkt und den hatte ich jetzt sozusagen nicht aufgeschrieben.

Also es sind, ja, tatsächlich ein sehr guter Punkt.

Also die Frage ist halt, ob ein Softwareprojekt, also ein Softwareprojekt hat scheinbar die Aufstellung oder die Ausrichtung hat, Software zu entwickeln und zu produzieren, aber es ist halt gleichzeitig ein Karrierevehikel.

Also jemand, der ein Softwareprojekt erfolgreich gemacht hat, wird dann möglicherweise befördert, bekommt dann irgendwie mehr Geld, was auch immer.

Und es gibt dann eben, das hat irgendwie Konsequenzen.

Also das hat die Konsequenz, dass zum Beispiel sehr viele verlieren, wenn ein Projekt offiziell zum Misserfolg erklärt wird.

Dass bestimmte Leute aber gewinnen, wenn ein Projekt zum Misserfolg erklärt wird.

Und das führt dann eben genau zu so Spielchen, die halt das Projekt nicht unbedingt sehen als etwas, wo am Ende Software rauskommen soll, sondern eben als ein politisches Vehikel.

Und dann ist eben tatsächlich die Software gar nicht so sehr das Ziel, sondern eben zum Beispiel einen offiziellen Erfolg zu produzieren, worüber in Wirklichkeit vielleicht irgendwie alle wissen, dass es ein Misserfolg ist.

Und das ist dann eben auch eine Umgebung, in der ich mich vielleicht so verhalten muss oder sollte, um eben zu sagen, also ich habe hier jetzt irgendwie alle Vorkehrungen getroffen, das hat schiefgegangen, das ist nicht mein Problem.

Also ich habe halt genau das geliefert, was ich damals wollte.

Was wolltet ihr denn überhaupt?

Sondern habe ich eben genau das Projekt halt in dem Sinne, also als politisches Vehikel erfolgreich beendet.

So, jetzt steht hier noch, also Tasker hat geschrieben, ob es Ausschreibungen gibt, auch in der IT, ja, also gibt es.

Und Fast-Post-Politik gibt es halt irgendwie auch.

Ist Fehlerkultur ein Umgebungsvariable im Sinne von psychologischer Sicherheit?

Indem ich mich ändere, dann ändere ich meine Umgebung.

Ich finde es schwierig, weil nicht also in einer Umgebung mangelnd auf der Fehlerkultur Fehler zuzugeben kann, sondern, wie nennt man das, karriere- limitierende Aktion sein.

Ich weiß nicht, ob ich es halt machen würde.

Es macht natürlich irgendwie Sinn.

Besondere Führungskräfte können da halt auch aktiv was tun.

Ob man das jetzt generell macht, weiß ich nicht.

Und, wie soll ich sagen, also, das ist vielleicht auch noch ein Punkt.

Ich möchte jetzt, also wir haben jetzt eine Menge an Erklärungsmodellen dafür, warum das so läuft.

Und eben insbesondere haben wir den Hinweis, dass das nicht unbedingt rationale Erklärungen sind.

Das muss ja nicht unbedingt heißen, dass wir sofort eine Lösung haben.

Und wenn wir aber jetzt nicht wissen, was eigentlich die Mechanismen sind und warum das halt irgendwie so läuft, wie es läuft, dann haben wir, glaube ich, eine deutlich schlechtere Chance, auf eine Lösung hinzuzuarbeiten.

Und deswegen ist das, also, ja, ich glaube, dass es halt gut ist, in diese Richtung mit Fehlerkultur und Umgebung zu investieren.

Das macht halt irgendwie Sinn.

Aber eigentlich ist das erstmal der Punkt, um zu sagen, dass die Herausforderung wird erwischt.

Gut, dann schaue ich nochmal.

Also, ich habe sonst, glaube ich, keine Fragen gesehen.

Nee, das ist halt soweit.

Dann würde ich sagen, soweit erstmal.

Vielen Dank für die Diskussion und für die Beiträge.

Ich denke, es wird nächste Woche eine Episode geben, obwohl es ein Brückentag ist.

Und das Thema ist allerdings noch offen.

Und ansonsten wünsche ich schon mal ein schönes Wochenende.

Und vielen Dank, dass ihr da wart.

Und sozusagen bis zum nächsten Mal.

Bis dann.