Trialog Teil 2 – Das up2U Protocol

Der zweite Teil unseres Trialogs, in dem Alexander Gerber, Björn Czybik und ich, über Komplexität und angrenzende Themen- und Fragestellungen diskutieren, fand am 02.10.2017 statt. Den ersten Teil können Sie hier verfolgen.

Ein kurzer Rückblick

Alexander reflektiert am Anfang unseres zweiten Trialogs noch einmal auf unseren ersten und dabei konkret auf meine Aussage „Was in einem Team vergemeinschaftet ist, hat keinen Wert mehr aufgeschrieben zu werden.“ Er spiegelt in diesem Kontext sein Vorgehen mit Dokumentationen im Rahmen von Projekten. Haben diese Mitschriften nur für ein Projekt Gültigkeit oder sind diese von ihm verinnerlicht, dann schmeißt er diese weg. Damit schafft er Ordnung für sich, was eine Wohltat ist, wie er es formuliert. Dieser Fakt an sich ist ihm durch die von mir getätigte Aussage explizit bewusst geworden und vor allem auch die Konsequenz dahinter. Schön. 🙂

Das up2U Protocol

Wir gingen dann schnell zum up2U Protocol über, ein Framework, welches Alexander für sich im Kontext von Handhaben von Komplexität erfunden hat. Über die Entwicklung dieses Protocols haben sich Björn und Alexander kennengelernt. So wie ich die Beiden verstanden habe, hat Björn einige wertvolle Impulse geliefert, die dann Alexander zur Finalisierung weiter verwendet hat. Den kompletten Trialog können Sie über einen Klick auf die untere Abbildung nachverfolgen.

Björn hat seine Sichtweise auf dieses Framework gespiegelt. Er hat eine Schrittfolgensequenz gezeichnet, die gemeinsam in einem Team ablaufen sollte, um komplexe Fragestellungen und Probleme zu lösen.

Der erste Schritt ist stets das Herstellen von Augenhöhe im Team. Damit stellt man sicher, dass wirklich JEDE Meinung und Sichtweise in den Prozess der Lösungserarbeitung einfließen kann. Diesen Punkt kennen wir wahrscheinlich alle aus eigener Erfahrung. Fühlt man sich in einer Gruppe von Menschen nicht gleichwertig zu anderen Gruppenmitgliedern, hält man sich eher zurück mit seinen Ideen und Gedanken. Man könnte ob dieser ja „verlacht“ werden.

Schritt 2 ist dann das Teilen von ALLEN Daten. Da zu diesem Zeitpunkt noch nicht bekannt ist, was das eigentliche Problem ist, da es noch nicht explizit definiert wurde, kann auch nicht klar sein, welche Daten (Skills, Kompetenzen, Erfahrungen, Wissen etc.) zur Lösung beitragen und welche nicht. Deshalb wäre es fahrlässig, zu diesem Zeitpunkt bereits Daten auszuschließen.

Im Schritt 3 wird dann der Scope definiert. Nun wird das Problem explizit und klar beschrieben. In diesem Schritt transformiert man das eigentlich komplexe Problem ganz bewusst und gewollt in ein kompliziertes. Man verlässt in diesem Schritt den roten Pfad des Frameworks und betritt den blauen. Die Farben rot und blau stehen hier für „komplex“ sowie „kompliziert“. Wenn mich nicht alles täuscht hat sich Alexander hier der Farbenlehre von Gerhard Wohland bedient. Seine Intention dabei war, so wie er es formuliert hat, dass man sich bei Verwendung der Farben nicht in einer Deutung der Begriffe „komplex“ und „kompliziert“ verstrickt und verzettelt und sich so auf das Wesentliche konzentrieren und fokussieren kann. Ich möchte also des Weiteren in diesem Beitrag auch diese Farbdeutung verwenden, also „rot“ für „komplex“ und „blau“ für „kompliziert“.

Warum ist es wichtig in diesem Schritt die Transformation von rot zu blau vorzunehmen? Man kann bekannte Methoden und Tools verwenden, um eine Lösung zu finden. Das Team hat eine vergemeinschaftete Sprache für die Problemlösung vorliegen. Im Schritt 2 wird also der Optionsraum an möglichen Lösungen aufgemacht. Er wird vergrößert. In diesem Schritt 3 wird dieser Optionsraum dann wieder verkleinert. Man möchte sich nun klar festlegen und alle Energie auf diesen fokussierten Optionsraum lenken. Man sagt ja auch des Öfteren, dass ein gut beschriebenes Problem die halbe Lösung darstellt. Und noch eines ist wichtig zu erwähnen. Da man Komplexität über unsere sprachlichen Mittel nicht vollständig erfassen kann, wir aber ein klar formuliertes Problem benötigen, ist die Transformation von rot zu blau zwingend notwendig. Dieser Mindset kommt hier zum Tragen.

In diesem Schritt 3 wird Sicherheit und Gewissheit erzeugt, allerdings künstlich, denn das eigentlich komplexe Problem erlaubt diese Gewissheit nicht. Dabei müssen die Menschen im Team an diese Gewissheit zu diesem Zeitpunkt fest glauben, da sie sonst nicht in die Lösungssuche kommen würden. Sie würden sich und ihre zur Verfügung stehenden Werkzeuge ständig hinterfragen, statt sie zu verwenden. Es ist ähnlich als wenn man einen Hammer und einen Nagel zur Hand hat, den Nagel eigentlich in die Wand schlagen möchte, und sich ständig die Fragen stellt, ob denn der Nagel groß genug ist für das Bild, der Hammer groß genug für den Nagel, die Wand grundsätzlich stabil genug, was passieren würde, wenn man vorbei schlägt usw. usf. Man würde ob des ständigen Grübelns wegen seiner gefühlten Unsicherheit nicht ins Tun kommen.

Nun werden im Schritt 4 Werkzeuge (Methoden, Tools, Prozesse, Wissen) definiert, die verwendet werden sollen, um dieses komplizierte Problem zu lösen. Dann wird das Problem gelöst, sowie anschließend die Lösung verprobt. Die Verprobung ist genau deshalb so wichtig, weil man ja nicht das eigentlich komplexe Problem, sondern das komplizierte gelöst hat. Nun muss verifiziert werden, in wie weit die komplizierte Lösung auf das ursprünglich komplexe Problem passt und in wie weit sich das initial komplexe Problem durch den Erkenntnisgewinn der durchgeführten Schritte und durch Einflüsse der Umwelt geändert hat. An dieser Stelle wird also wieder Ungewissheit und Unsicherheit zugelassen. Man bewegt sich dann wieder im roten Bereich.

Änderungsbedarfe, also die Ergebnisse der Verprobung, fließen dann in die nächste Iteration ein, wo am Anfang dieser neuen Iteration das Problem wieder aufgemacht wird. Ich bin also wieder im Schritt 1 angelangt und die Kette beginnt von vorne. Dieser Kreislauf läuft so lange, wie man noch Probleme zu lösen oder Bedürfnisse oder Wünsche zu befriedigen hat, der Änderungsbedarf also größer Null ist. Ist dieser gleich Null liegt Harmonie vor, wie Alexander anmerkt. Allerdings, da sich die Welt ja weiter dreht, und wie wir häufig betonen, das immer schneller geschieht, ist dieser Zustand wohl nur von kurzer Dauer. Änderungen bestehen und der Kreislauf geht von vorne los. Praktisch endet dieser Kreislauf also nur im Tod. Denn Leben heißt Problemlösen. Das ist quasi Sinn und Zweck des Lebens an sich. Und an dieser Stelle ist der Begriff nicht negativ konnotiert, wie so oft, wo man dann statt „Problem“ den Begriff „Herausforderung“ verwendet, was für mich nicht notwendig ist.

Wechselspiel zwischen Komplexität erhöhen und reduzieren

In diesem Framework erkennt man auch ein schönes Muster. Man muss im Rahmen von Problemlösen stetig und im Wechsel Komplexität erhöhen und reduzieren. Im Kontext von up2U könnte man auch sagen, dass man stetig zwischen dem roten und dem blauen Bereich hin und her switched, das aber bewusst und ganz fokussiert tut. Diesen Aspekt habe ich in meinem Beitrag Muss man einen Wettlauf mit der Komplexität eingehen? zum Thema gemacht und erörtert. Die relevante Frage ist dann, wann ist eine Erhöhung notwendig und wann eine Reduzierung. Das entscheidet der Mensch und keine Methode. Der Mensch ist und bleibt also verantwortlich für Erfolg und Misserfolg, nicht die Methode. Methoden müssen Werkzeug des Menschen bleiben. Häufig nehme ich anderes wahr, nämlich dass der Mensch zum Sklaven der Methoden mutiert.

Warum sind wir Menschen oft Sklaven der Methoden?

Alexander führt dazu seine Ideen aus. Seiner Meinung ist dies ein Relikt des Taylorismus. Kennzeichen ist, dass wenige Menschen im Unternehmen denken und viele Menschen das Gedachte ausführen. Ergebnisse des Gedachten sind dann „Strukturen im Außen“, wie ich sie im ersten Trialog bezeichnet habe, also Prozesse, Methoden, Rollen etc. Da das reine Ausführen des Gedachten eben in genau diesen Strukturen von statten gehen muss, erkennen sich viele Menschen als festen Bestandteil dieser Strukturen an. Sie nehmen keine ausreichende Unterscheidung mehr wahr. Sie sind also in ihrer Wahrnehmung Instrument dieser Strukturen und erkennen diese nicht mehr als Mittel zum Zweck, sondern als Selbstzweck. Denn ohne sie existieren sie ja nicht, können sie gar nicht, in ihrer Gedankenwelt.

Nun kann man natürlich fragen, warum wir es überhaupt so weit haben kommen lassen. Ich würde sagen, weil der Markt dieses Vorgehen früher nicht abgestraft oder teilweise gar befeuert hat. Wir hatten früher einen Verkäufermarkt. Es war klar wie ein Unternehmen Erfolg haben kann und was die Probleme, Wünsche und Bedürfnisse der Kunden sind. Diese bekannten Wünsche mussten nur schnell und kostengünstig befriedigt werden. Der Kunde hatte einen kleinen Optionsraum, was die Unternehmen sehr häufig im Bereich der Gewissheit und Sicherheit verweilen ließ, also im blauen Bereich. Ein Schwenk in den roten Bereich war nur selten notwendig. Damit mussten also die verwendeten Werkzeuge nur selten hinterfragt werden. Heute haben wir aber mittlerweile einen Käufermarkt. Der Optionsraum an Handlungen der Kunden und potentiellen Kunden für ein Unternehmen ist extrem groß geworden, was einen häufigeren Wechsel der Unternehmen auf den roten Pfad notwendig macht. Die derzeit etablierten Strukturen, die noch aus der Zeit des Taylorismus stammen, lassen genau diesen steten Wechsel zwischen rotem und blauem Bereich nur mäßig bis gar nicht zu. Details dazu können Sie gerne in meinem Gastbeitrag auf der microTOOL Seite namens Taylor hatte doch Unrecht erfahren.

Reine Komplexität und Kompliziertheit ist eine Illusion

Björn führt in diesem Zusammenhang aus, dass es klar sein muss zu betonen, dass es keine reinen komplizierten (blauen) oder keine reinen komplexen (roten) Probleme gibt. Im Roten gibt es blaue Anteile und anderes herum. Hier dazu gerne mehr von ihm. Es ist also die Fähigkeit von Nöten, den Zeitpunkt der Wechsel zu erkennen, diesen dann auch vollführen zu können und sich ganz bewusst für einen definierten Zeitraum in diesem zu bewegen. Gerade der letzte Punkt ist sehr entscheidend und hat etwas mit konsequenter Fokussierung zu tun. Es ist wichtig zu entscheiden, wann man Unsicherheit zulassen und aushalten muss (Schritte 1 und 2 des up2U Protocols), was natürlich auch Mut bedingt. Genau so wichtig ist es aber auch dann ab dem Schritt 3 des up2U Protocols sich nicht von Einflüssen von außen stören zu lassen, sondern konsequent am definierten Scope festzuhalten. Auch hier ist dann natürlich Mut und auch Ausdauer von Nöten, genau das auszuhalten.

Scrum vs. Wasserfall

Nun habe ich die Methoden Scrum und Wasserfall ins Spiel gebracht. Warum? Weil in meinen Augen der eigentliche Kern von Scrum nicht erkannt und deshalb oft eine Dichotomie zwischen Wasserfall und Scrum immer wieder zelebriert wird. Schade, denn wenn der eigentliche Sinn und Zweck einer Methode nicht verstanden wird, dann kann diese auch nur schwerlich passfähig verwendet werden. Diesen Fakt habe ich hier tiefer zum Thema gemacht. Ein Hauptgrund für das Nichtverstehen sind Rekursionen, die sich sowohl Scrum als auch das up2U Protocol zu Nutze machen. Der Output aus der Iteration n-1 wird zum Input der Iteration n, der dann wieder in dieser zu einem Output transformiert wird. Jeder Sprint, als Iteration der Methode Scrum, ist in diesem Sinne ein Wasserfall. Scrum bildet also eine Verkettung von ineinander verschmelzenden Wasserfällen ab.

Wann immer man Wert für andere Menschen generieren möchte, muss man stets den gleichen Zyklus in derselben Reihenfolge durchlaufen: Design (Welchen Bedarf oder Wunsch möchte ich decken? Welchen Wert möchte ich generieren? und Wie will ich diesen Wert erstellen?) → Umsetzung (ein Produkt oder Service herstellen, der für Andere diesen Wert darstellt) → Test (Laufen Produkt oder Service in meinen Augen fehlerfrei ab?) → Auslieferung (Sehen die Anderen den Wert im Produkt oder Service realisiert?) → Design → … Warum? Es macht wenig Sinn, etwas umsetzen zu wollen, wenn man nicht weiß was. Es macht wenig Sinn etwas testen zu wollen, wenn man nichts zum Testen bereit hat. Und es macht ebenfalls wenig Sinn „nichts“ ausliefern zu wollen.

Ich glaube an klare Abgrenzungen zwischen den oben aufgezeigten Phasen des Zyklus, nur eben halt in dafür zu definierenden Zeiteinheiten, die abhängig der Umwelt definiert werden müssen. Warum die Abgrenzung? Wegen klarer Fokussierung einer zu lösenden Fragestellung. Multitasking ist schädlich. Der Zyklus Design → Umsetzung → Test → Auslieferung → Design → … muss stets auf der relevanten Ebene betrachtet werden, womit letztendlich festgelegt wird, wie schnell sich dieser Zyklus drehen sollte. Im herkömmlichen Wasserfall-Modell dreht sich der Zyklus einmal je Projekt. Diese Ebene ist aber insbesondere dann, wenn je unsicherer und ungewisser die Umwelt ist, nicht passfähig. Dann benötigt man einen schneller drehenden Zyklus, also eine andere Ebene, auf der man den angesprochenen Zyklus betrachtet. Das könnte die Ebene der User Stories sein. Wichtig ist nur, dass auf der jeweiligen Ebene klare Abgrenzungen zwischen den Zyklusphasen herrschen.

Björn führt dann aus, dass er ein neues Modell kreieren möchte, um Wasserfall und Scrum miteinander zu versöhnen. Er spricht dann von Wassersprung, nicht mehr von Wasserfall. Er möchte damit den Entweder-Oder Denkrahmen, der es uns schwer macht, Wasserfall und Scrum versöhnlich miteinander im Einklang zu denken und danach zu handeln, aufbrechen. Ich bin gespannt.

Kommunikation ist Glückssache

Alexander bringt einen wichtigen Punkt ins Spiel, der gerade für Kommunikation essentiell ist, die Anschlussfähigkeit der hier formulierten Ideen und Gedanken in der Organisation. Er fragt mich, ob ich es als schwierig empfinde, diese Themen im Unternehmen im Daily Business zu platzieren? Ich denke ja. Ich habe für mich in den letzten 3 Jahren festgestellt, dass Kommunikation eine Kunst ist. Man könnte auch sagen, Kommunikation ist Glückssache, die eigentlich nicht funktionieren kann. Nur, sie läuft trotzdem immer und stetig ab, wenn mindestens 2 Menschen im Kontakt sind. Wir können nicht nicht kommunizieren.

Ich möchte in diesem Kontext gar nicht darauf eingehen, dass der Empfänger und eben nicht der Sender die Mitteilung im Rahmen der Kommunikation bestimmt. Zu diesem Zweck können Sie gerne hier nachlesen. Ich möchte eher auf Begriffe im Rahmen der Kommunikation eingehen. Kommunikation geht nur über Sinnlegung hinter Begriffen. 2 Menschen sollten beispielsweise erst dann den Begriff „Konzept“ in ihrer Kommunikation verwenden, wenn sie auch die gleiche Bedeutung hinter diesem Begriff „Konzept“ gelegt haben. Klar, sonst bauen sie ihre Kommunikation auf dem Nährboden des Missverständnisses auf. Was geschieht aber nun in Zeiten des Wandels, wenn die Bedeutungen hinter Begriffen aus der Vergangenheit stammen? Dann wird es schwer diese im neuen Kontext zu gebrauchen. Bleiben wir beim Begriff „Konzept“. Dieser Begriff ist durch die Wasserfall-Methode geprägt und teilweise verbrannt, jedenfalls in meiner Wahrnehmung. Viele Menschen legen viele Nachteile der Wasserfall-Methode in diesen Begriff. Menschen brüten monatelang Ideen und Gedanken aus und schreiben sie auf Papier nieder, ohne die Machbarkeit in der Umsetzung prototypisch zu verifizieren oder auch den „Kunden“ mit einzubinden, um stetig den Wert der Lösung zu hinterfragen.

Ich habe hier eine andere Sicht. Wie bei der Gegenüberstellung von Scrum und Wasserfalls ausgeführt, ist es wichtig, dass, bevor man etwas tut, denkt. Und ein Konzept ist für mich nichts anderes als das dokumentierte Ergebnis eines Denkprozesses, was benötigt wird, um sich mit anderen Menschen auszutauschen. Auch hier ist wieder sehr eindrucksvoll unser „Entweder-Oder“ Denkrahmen zu erkennen, den Björn ja mit seinem neuen Framework umschiffen möchte. Eine Methode ist grundsätzlich gut oder schlecht. Etwas dazwischen gibt es nicht.

Im Rahmen von Kommunikation muss man sich zu aller erst um die verwendeten Begriffe kümmern. Umdeutungen und Erläuterungen dieser ist der eigentliche Kern einer Transformation in den Unternehmen, meint Alexander. Dieser Fakt war unter anderem der Antrieb für ihn, das up2U Protocol zu entwickeln, womit wir wieder beim Thema dieses zweiten Trialogs wären und den Kreis geschlossen haben. Ergebnis des Protocols ist stets Gewissheit in drei möglichen Facetten. Entweder man hat im Team Gewissheit, etwas hinbekommen zu haben oder in der Zukunft etwas hinbekommen zu können. Das stellt grundsätzlich einen Wert für das Team dar. Es schweißt zusammen. Es gibt aber noch einen dritten und vierten möglichen Fall, der wertvoll für ein Team ist, nämlich die Gewissheit, nichts hingekommen zu haben und das wohl auch in Zukunft nicht zu schaffen. Dann kann man sich nämlich trennen und vergeudet keine Zeit und anderweitige Ressourcen.

Gewissheit ist wichtig. Danach suchen und streben Menschen. Auch wenn es nur beim Glauben daran bleiben kann.

Wow. Ich habe wieder viel mitgenommen. Danke Alexander und Björn. Ich freue mich auf unseren dritten Trialog.

Herzliche Grüße,
Conny

 

Bildnachweis

6 Kommentare
  1. Alexander Gerber
    Alexander Gerber says:

    Wie schon zuvor stellt Dein Artikel einen Mehrwert gegenüber dem unmittelbaren Gespräch zwischen uns dar.
    Aus der Reflektion und Zuordnung in diesem Artikel entsteht Erkenntnisgewinn. Auch für mich als Teilnehmer.
    Erneut, vielen Dank dafür, Conny!

    Die Sache mit den guten und schlechten Methoden stößt mir noch auf.
    Die Beurteilung ist mir zu subjektiv und relativ in dem jeweiligen Kontext.

    Ich möchte Methodenauswahl, deren Anwendung und deren Ergebnisbeurteilung gern objektiver sehen.
    Eine Methode ist an sich neutral – deklariere ich jetzt einmal.
    Sie kann nach den Regeln der Kunst und dem Stand der Entwicklung angewandt werden, wenn man sie beherrscht – oder dahinter zurückbleiben, wenn sich der, die oder die AusführendenInnen im Lernstadium befindet/n. 😉

    Die eigentlich entscheidende Frage ist doch, ob die Methode das Vorhaben, seinem gemeinsam beschlossenen, gemeinschaftlich verfolgten, zukünftigen Ziel näher bringt oder dazu nur mäßig oder komplett ungeeignet ist. Wenn ich nur eine Schraube und einen Hammer zur Verfügung habe, dann kann ich damit in Ermangelung von Alternativen mit einigem Geschick sehr wohl temporär passable Ergebnisse erzeugen. Ggf. muss ich die Werkzeuge und deren Anwendung im Nachgang anders verwenden.

    Bei der Softwareentwicklung sind das die sog. „Technischen Schulden“, die „Refactoring“ nach sich ziehen können – die „fachliche“ Funktion (Bild hängt an der Wand) bleibt dabei unverändert.
    Ist das jetzt nun gut oder schlecht? Ich denke, hier hilft es Herrn Boole zu bemühen. Funktion erfüllt – true/false?
    Wobei wir dann wieder beim Grundgedanken von Akzeptanztests und TDD sind.

    Ich bin gespannt auf unseren nächsten Trialog.

    Antworten
    • Conny Dethloff
      Conny Dethloff says:

      Moin Moin Alexander,

      erst einmal Dankeschön für die Blumen. 🙂

      Im Thema Methoden bin ich voll bei Dir. Eine Methode an sich ist weder gut noch schlecht. Einzig und allein der Mensch entscheidet über den Erfolg seiner Vorhaben, in dem er entweder passfähige oder eben nicht passfähige Methoden und Werkzeuge aussucht und verwendet.

      Bei Vorhaben, die mehr blaue Anteile haben als rote, bei Vorhaben also, wo Erkenntnisse aus den Naturwissenschaften nahezu 1:1 übertragbar sind, gehen wir viel bewusster und reflektierter mit uns und unseren Werkzeugen um. Man stelle sich in diesem Kontext folgende Situation vor. Ein Maler renoviert mein Haus und ich bin mit dem Ergebnis nicht zufrieden. Den Maler darauf ansprechend verweist er auf seine Pinsel und meint, dass er ja nichts dafür kann. Es waren die Pinsel. Skurril, oder?

      Ja genau. Bei Vorhaben, wo mehr rote Anteile zu finden sind, treffen wir solche Situationen und „Ausreden“ zu Hauf an. Dann haben sehr häufig die Methoden Schuld.

      BG, Conny

      Antworten
  2. Björn
    Björn says:

    Hallo Conny,
    vielen Dank. Der Artikel hat mir bereits neue Insights gebracht :-).

    Zum Reduzieren und Erhöhen von Komplexität: Ist es nicht eher das Wechselspiel zwischen rot und blau (komplex, kompliziert), anstatt das Wechselspiel zwischen reduzieren und erhöhen der Komplexität. Wenn ich mich nicht irre spricht die Kybernetik davon, dass man Komplexität nicht reduzieren kann. Sie existiert einfach. Wir können mit unserer Sprache, Modellen usw. immer nur einen Teil beschreiben.
    Es geht vielmehr um den bewussten Umgang mit dem Wechselspiel zwischen Rot und blau und dass wir unterschiedliche Dinge in den Bereichen brauchen (Rot – Frameworks, Heuristiken; Blau – Methoden, Techniken). Im roten Bereich Überblick haben, im blauen Bereich fokussiert Aufgaben rocken. Wir blenden im blauen Bereich rote Anteile aus, damit wir arbeiten können. Die Komplexität bleibt aber, nur betrachten wir sie für einen Moment nicht.
    Womöglich sind für mich die Begriffe reduzieren und erhöhen aktuell noch negativ belegt ;-).
    Herzliche Grüße
    Björn

    Antworten
    • Conny Dethloff
      Conny Dethloff says:

      Moinsen Björn,

      ich denke wir sind dicht beisammen.

      Ich konkretisiere mal meine These, dass man beim Problemlösen Komplexität abwechselnd erhöhen und reduzieren muss. Ich meine hier konkret die interne Komplexität im Unternehmen. Hier war ich zu ungenau. In dem an dieser Stelle in diesem Beitrag zugelinkten Artikel formuliere ich das ausführlicher. Die externe Komplexität der Umwelt bleibt davon unangetastet. Man könnte auch formulieren, dass dem Markt relativ egal ist, wie dieser im Unternehmen selbst betrachtet wird. Wir steuern stets gegen ein Modell der Umwelt oder des Marktes, niemals gegen den Markt oder die Umwelt an sich. Diese ist für uns nicht erkenn- und wahrnehmbar. Und genau dieses Modell wird durch uns definiert und gestaltet.

      Aus der Kybernetik ist ja auch der Spruch bekannt, dass man Komplexität nur mit Komplexität handhaben kann. Mit der von mir eingeführten Unterscheidung heißt es dann genauer.

      Externe Komplexität sollte man stets mit ausreichend großer interner Komplexität begegnen, wissend, dass die interne niemals so groß sein kann wie die externe. Deshalb lässt sich die externe Komplexität, also der Markt, auch niemals managen, sondern bestenfalls handhaben.

      Die interne Komplexität, oder auch die Fähigkeit der Menschen im Unternehmen mit der externen Komplexität umzugehen, ist gestaltbar. Das up2U Framework ist in meinen Augen genau dafür vorgesehen. Beim Übergang von „rot“ zu „blau“ fokussieren wir uns auf bestimmte Aspekte des Problems, welches der Markt oder die Umwelt uns stellt. Wir vernachlässigen bewusst bestimmte Einflüsse, Verbindungen, Faktoren etc. Damit engen wir unseren Handlungsspielraum ein und verringern unsere interne Komplexität. Man könnte auch sagen, wir erhöhen die blauen und verringern die roten Anteile.

      Beim Übergang von „rot“ zu „blau“ verringern wir unsere interne Komplexität. Beim Übergang von „blau“ zu „rot“ erhöhen wir unsere interne Komplexität. Und das unabhängig von der externen. Aber vielleicht ist es ja auch so, dass der Begriff „Komplexität“ und dann auch noch die Unterscheidung in „intern“ und „extern“ für zu viel Verwirrung sorgt, so wie Alexander im Trialog angemerkt, so dass man besser bei der Farbenlehre bleibt.

      BG, Conny

      Antworten
      • Björn
        Björn says:

        Perfektes Beispiel: du hast alle Daten geteilt, als Link, ich habe ihn nicht gelesen, somit nicht alle Daten und schon können Missverständnisse entstehen :-). Ja, interne und externe Unterscheidung ergibt auch für mich Sinn, wobei ich sogar in der internen Komplexität gedacht habe. Wir betrachten nur unsere innere Komplexität als Organisation (das wäre schön wieder blau – Scope definiert), aber das rot der Umgebung bleibt. Aus dem blau wird wieder rot und wir wenden das Up2U wieder an. Ein ständiges zoom in und zoom out.

        Ja, wir liegen dicht beieinander. Du hast sicherlich andere Themen im Hinterkopf als ich gerade :-). Freue mich aufs nächste Mal.
        HG
        Björn

        Antworten
  3. Alexander Gerber
    Alexander Gerber says:

    Schön rund ist es jetzt geworden.
    Ich gehe mit.

    Einer der Schlusssteine, bevor ich das Protokoll formuliert habe, war ein Vortrag von Alexander Krause.
    Da ging es beim Betrachten eines Product-Backlogs darum, komplizierte und komplexe Aufgaben zu klassifizieren.

    Die komplizierten konnten „im stillen Kämmerlein“ abgearbeitet werden, während die komplexen Aufgaben ein komplexes Lösungssystem (das Team und nicht nur eine Arbeitsgruppe) erfordern.

    Das up2U-Protokoll kann ausdrücklich bereits ab einer 1:1-Interaktion mit Konflikt-Potential und damit verbundener Ungewissheit verwendet werden.
    Daher verbinde ich rot eher mit Ungewissheit und blau mit Gewissheit, um mich nicht auf das Komplexitäts-Glatteis zu begeben.
    Aber, jeder wie er/sie es mag und braucht …

    Antworten

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.