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

• Beitragsbild und Bild im Text: https://unsplash.com/ am 13.10.2017