Conny Dethloff

Komplexität verspeist Methodik, immer und überall | Ein Gastbeitrag von Conny Dethloff

Das Frönen von Agilität in Unternehmen nimmt in meinen Augen in letzter Zeit immer skurrilere Züge an. Es ist so, als würden wir vor jeder Mahlzeit das Besteck bewundern und darüber debattieren, wie schön glänzend dieses doch ist, bevor wir uns ans Essen heranmachen. Mit diesem heutigen Beitrag möchte ich Agilität und damit einhergehend Methoden ein wenig entmystifizieren.

Ein kleines Gedankenexperiment
Stellen wir uns vor, Außerirdische besuchen uns auf der Erde und sehen uns Menschen das erste Mal Fahrradfahren. Sie kennen keine Fahrräder und schon gar nicht das Fahren auf diesen. Sie denken: „Wow, das Teil hat nur 2 Räder und die Menschen kippen nicht um. Wahnsinn.“ Sie beobachten uns, wie wir dieses Kunststück wohl fertig bringen. Dabei beobachtet einer der Außerirdischen, wie Menschen beim Treten immer wieder abwechselnd aus dem Sattel gehen und sich dann wieder hinsetzen, und denkt sich: „Das ist es. Geheimnis gelüftet.“ Er erfindet auf Basis dieser Erkenntnis eine Methode, wie man ab sofort Fahrradfahren muss, und lehrt das seinen Kollegen.

Mittlerweile haben sie dieser Methodik dann auch einen Namen gegeben und feiern diese regelmäßig ab. Sie fragen uns Menschen im Kontext des Fahrradfahrens nach dieser Methodik und wir gucken sie nur schmal an, da wir diese Methode nicht kennen, ja, noch nie von ihr gehört haben. Die Außerirdischen wundern sich, dass wir trotzdem Fahrradfahren können.

Erkennen Sie die Parallelen zu Agil? Was wäre jetzt, wenn wir den Begriff „Fahrradfahren“ mit „Agilsein“ tauschen? Es verhält sich in meinen Augen ähnlich. Man schaut in die Unternehmen hinein, die erfolgreich sind. Man beobachtet so allerhand, was sie tun, welcher Prozesse und Methoden sie sich bedienen etc. Versucht man, das Beobachtete aber zu beschreiben, wird es schwierig, da man den eigentlichen Kern eben nicht greift, warum diese Unternehmen erfolgreich sind. Prozesse und Methoden machen Unternehmen nicht erfolgreich, sondern die Menschen in den Unternehmen, die sich dieser Prozesse und Methoden bedienen.

Gründe für Erfolg in komplexen Umgebungen kann man nicht beschreiben, bestenfalls beobachten. Dann fällt es aber schwer, diese Gründe für sich zu adaptieren, da man dafür das Beobachtete beschreiben müsste. Ich habe diesen Fakt mal am Thema Führung gespiegelt und dort die These formuliert, dass nur schlechte Führung beschreibbar ist, da diese Widersprüchlichkeit negiert.

Agilität hat in erster Linie nichts mit Methodik zu tun
Genau. Bei Agilität geht es in erster Linie um die Geisteshaltung der denkenden und handelnden Menschen. Sie möchte das gerne weiter fortführen. Immer wieder höre ich Fragen wie:

  1. Wie oft müssen wir denn nun einen Stand-Up im Team durchführen, wirklich täglich?
  2. Wie lange sollte dieser dauern?
  3. Dürften wir einen Sprint auch auf 3 Wochen ansetzen?

Solche Art von Fragen bezeichne ich stets als kontextlos, da sie mit dem eigentlichen Sinn, der hinter Agilität steht, nichts gemein haben. Um den Vergleich zum Fahrradfahren noch einmal herbeizurufen. Es ist so, als wenn mein Sohn beim Erlernen des Fahrradfahrens mich gefragt hätte, nach wie vielen Minuten er denn nun aus dem Sattel gehen sollte und nach wie vielen Pedalumdrehungen er sich wieder hinsetzen dürfte.

Die Kernfragen hinter Agilität sind die Folgenden:

  1. Wer ist unser „Kunde“?
  2. Welche Bedürfnisse und Wünsche hat unser „Kunde“ und wie erkennen wir schnell Änderungen in diesen?
  3. Über welche Services und Produkte können wir diese Bedürfnisse und Wünsche schnell erfüllen und warum kann das Niemand besser als wir?
  4. Wie können wir uns als Team stetig im Sinne der Antworten der obigen Fragen verbessern?

Hört man jemals die Frage „Müssen wir agil sein?“, sollte man bedenken, dass der Fragende eigentlich „Was bedeutet agil?“ fragen wollte. Hat man Agilität verstanden, weiß man, dass die Frage nach dem „ob“ ähnlich irrelevant ist, wie die Fragen „Müssen wir regelmäßig Nahrung zu uns nehmen?“ oder „Ist es wichtig zu atmen?“

Agilität ist nichts Statisches und kann nur mittels agiler Denk- und Handlungsweisen eingeführt werden. Agilität kann also nur agil eingeführt werden. Ein Widerspruch? Na klar. Es dreht sich hierbei ja um Lebendigkeit. Der Weg ist hier das Ziel. Agilität an sich darf nie das Ziel sein, sondern nur Mittel zum Zweck.

Eine Methode ist weder agil noch nicht agil. Eine Bewertung über Adjektive ohne Kontext, in diesem Fall die Bewertung einer Methode, ist stets sinnentkoppelt. Kontextlos gibt es keinen Unterschied zwischen agil und nicht agil. Auch hier wieder ein eingängiges Beispiel, diesmal aus der Welt des Sports. Ein Turner ist beweglich. Ergibt es deshalb Sinn, jeden Fußballer, nur weil er nicht so beweglich ist wie ein Turner, als nicht beweglich zu titulieren? Nein, natürlich nicht. Denn es ist essentiell, wie viel Beweglichkeit überhaupt sein muss, um erfolgreich in der jeweiligen Sportart zu sein. Und das ist der Kontext, den ich hier ins Spiel bringe.

Über Methodik kann man Komplexität nicht handhaben
Es geht um das Auswählen einer passenden Methode. Ein Hammer ist ja auch nicht deshalb als Werkzeug grundsätzlich unbrauchbar, nur weil ich mit diesem keine Schrauben in die Wand drehen kann. Und genau für das Wählen dieser Methode ist der Mensch verantwortlich, um es klar zu sagen. Nur weil man im Projekt oder übergreifend im Unternehmen feststellt, dass man nicht agil genug ist, sollte man niemals die Methode, wie beispielsweise „Wasserfall“, dafür verantwortlich machen. Denn auch mit dieser Methode kann man agil sein.

Das Auswählen der passfähigen Methode geht nur über die passende Geisteshaltung. Agilität hat nichts mit der eingesetzten Methode zu tun, sondern einzig und allein mit der Geisteshaltung der Menschen, die ein Problem lösen.

Nur leider schlägt uns hier allzu oft der von mir wahrgenommene Methodizismus, dem wir Menschen erlegen sind, ein Schnippchen. Er hindert uns daran, den eigentlichen Sinn hinter Agilität zu entdecken. Darauf gehe ich nun ein, in dem ich den in der folgenden Abbildung gezeigten Teufelskreis des Methodizismus näher beleuchte.

Teufelskreis Methodizismus

Teufelskreis Methodizismus

Komplexe Probleme sind formal-logisch nicht beschreibbar, da Komplexität Widersprüchlichkeit impliziert, diese aber im Rahmen unserer Logik ausgesperrt ist. Methoden basieren nun einmal auf Logik. Würden Methoden widersprüchlich sein, würden wir diese negieren, da wir ihren Mehrwert nicht sehen. Um also Methoden als Lösung heranziehen zu können, müssen wir komplexe Probleme in komplizierte transformieren. Diese Transformation ist für uns so normal geworden, dass wir darüber schon gar nicht mehr reflektieren. Die gefundene Lösung, die ja auf dem transformierten komplizierten Problem beruht, wenden wir dann auf das komplexe Problem an. Dabei begehen wir einen Kategorienfehler. Mit Begehen dieses Kategorienfehlers sind wir einem Teufelskreis aufgesessen. Teufelskreis deshalb, weil wir es hier mit einer sich selbst verstärkenden Schleife zu tun haben. Wir merken, dass die gefundenen Lösungen sehr häufig nicht die Probleme lösen. Logisch, sie haben ja aufgrund der vorgenommenen Transformation nichts miteinander zu tun. Das befeuert in uns die Unsicherheit, die wir ja eigentlich durch den Einsatz von Methoden beim Lösen von Problemen überwinden wollen. Also wird unser Verlangen nach noch mehr Methodik und noch mehr Standards immer größer. Dabei werden unsere Probleme nicht gelöst, sondern noch verschärft.

Ich möchte hier noch einmal betonen, dass ich kein Gegner von Methoden bin. Ganz und gar nicht. Wir sollten uns beim Lösen von Problemen nur wieder mehr vertrauen, also mehr fühlen und denken. Wir suchen viel zu oft die Lösung im „Außen“, als erst einmal im „Innern“. So wird der Mensch Werkzeug der Methode. Methoden verhindern eine Verantwortungsübernahme für Misserfolg und stehen damit dem Lernen im Wege. Methoden sollen Mittel sein, niemals Zweck.

Fahrradfahren, um auf das Beispiel vom Anfang zurück zu kommen, lernt man durch Fahrradfahren. Eine wichtige Regel, der wir im privaten Leben normalerweise unreflektiert Folge leisten, im beruflichen Kontext allerdings häufig nicht. Hier steht uns der Methodizismus im Weg. ETWAS lernen, in dem man genau dieses ETWAS tut, scheint für uns widersprüchlich, da logisch wegen der Rückbezüglichkeit nicht abbildbar, und deshalb in Form von Methoden nicht beschreibbar.

Agilität kann man also nur einführen, indem man agil ist. Die japanische Philosophie, auf der ja größtenteils die Ideen und Gedanken hinter Agil beruhen, geben auch hier Aufschluss darüber, liegen aber oft im blinden Fleck unseres Denkens und Handelns. Die dortige Kampfkunst kennt drei Stufen des Lernens (Shu-Ha-Ri), die ein Schüler von den Anfängen bis zur Meisterschaft seiner Kunst durchläuft.

  1. „Shu“, als erste Stufe des Lernens bezeichnet, bedeutet so viel wie „erhalten oder gehorchen“. Man lernt, indem man stur gegebenen Regeln folgt. Ich spreche hier auch gerne von einem kontextlosen Befolgen von Prozessen.
  2. „Ha“, die zweite Stufe, lässt sich übersetzen mit „(auf)brechen, frei werden, abschweifen“. Hier geht es darum, die kontextlosen Regeln und Standards zu interpretieren und auf den Kontext abgestimmt zu variieren. Dazu gehört also, den Sinn und Zweck der einzusetzenden Methoden zu verstehen, um so über das reine Befolgen dieser hinaus zu kommen.
  3. „Ri“, als dritte und höchste Stufe, schließlich bedeutet „verlassen, trennen, abschneiden“. Hiermit ist gemeint, die gegebenen Muster hinter sich zu lassen, um, von eigenen Impulsen gesteuert, eigene Wege zu gehen. Die Erfahrung und das Beherrschen der Regeln ist dabei die Voraussetzung, um sich als Mensch im jeweiligen befindlichen Kontext unabhängig von Methoden zu machen.

Im Rahmen der dritten Stufe hat man also so viel Methodenkenntnis erlangt, dass man diese im Sinne des Erfolgs bewusst nicht mehr einsetzt. Wir Menschen der westlichen Gesellschaft bleiben häufig auf der ersten Stufe „Shu“ stehen, da der Übergang von der ersten Stufe zur zweiten durch die durchgeführte Transformation von „komplex“ zu „kompliziert“ (Abbildung oben) beim Lösen von Problemen im Wege steht.

 

Autorenprofil
Conny Dethloff ist im Februar 1974 geboren. Im Jahre 1999 hat er sein Studium als diplomierter Mathematiker abgeschlossen. Direkt im Anschluss ist er beruflich in die Wirtschaft eingestiegen, bis Ende 2011 als Unternehmensberater mit dem Schwerpunkt Unternehmenssteuerung und -planung in verschiedenen Industriezweigen. Derzeit ist Conny Dethloff als Manager im Bereich Business Intelligence bei der OTTO GmbH & Co. KG tätig, wo er maßgeblich die digitale Reise von OTTO im Zusammenhang mit Daten und BI vorantreibt. Seine Erkenntnisse in diesem Kontext beschreibt er u.a. in mehreren Blogs: Logbuch der Reise des Verstehens, Plattform der Unternehmensdemokraten und auf der Lean Knowledge Base.

5 Gedanken zu „Komplexität verspeist Methodik, immer und überall | Ein Gastbeitrag von Conny Dethloff

  1. Uli

    Großartiger Beitrag! Eine kleine Ergänzung zur Parallele Fahradfahren: Die agilen Methoden sind nur die Stützräder beim Fahrrad – sehr hilfreich am Anfang, aber irgendwann werden sie überflüssig. Allerdings nur, wenn mein Kind das Ziel hat, irgendwann selbständig ohne Hilfe zu fahren. Ansonsten wird es sich weiterhin auf die Stützräder verlassen.
    Für mich heißt das beim Einführen agiler Methoden: Immer wieder den Beteiligten (vor allem auch den Führungskräften) deutlich machen, was das Ziel ist, nämlich das Erreichen der dritten Stufe – „Ri“.

    Gefällt 1 Person

    Antwort
    1. Conny Dethloff

      Danke für die Antwort.

      Zum Thema Radfahren. Meine Tochter hat mit Stützrädern Fahrradfahren gelernt, mein Sohn dann 3 Jahre später ohne. Warum? Meine Frau und ich haben wahrgenommen, dass meine Tochter sich beim Übergang von „mit …“ zu „ohne Stützräder“ wahnsinnig schwer getan hat, weil sie in den ersten Tagen und Wochen des Erlernens von Fahrradfahren das Gleichgewichthalten in die Verantwortung der Stützräder gelegt hat. Und dann waren sie auf einmal nicht mehr da.

      Auch daraus kann man sicherlich einige Erkenntnisse im Umgang und Einsatz von Methoden und Tools beim Problemlösen ziehen. Oder?

      Gefällt mir

      Antwort
  2. Rafael Gebert

    Ein sehr schöner Beitrag, vor allem der Hinweis, dass Agilität eben nicht eine reine Methode ist, sondern eine Einstellung. In vielen Gesprächen und Projekten habe ich dies erlebt und verstehe daher die Problematik und die Irritation von vielen Projektverantwortlichen, die versuchen, Ihr Unternehmen oder Projekt „agiler“ zu machen. Ich schließe mich Uli an; agile Methoden sind die Grundlage, um unsere innere Einstellung zu ändern und anschließend selbstständig und losgelöst von diesen die komplexen Probleme angehen zu können, frei dem Sprichwort: „Erzähle mir und ich vergesse. Zeige mir und ich erinnere mich. Lass es mich tun und ich verstehe.“

    Gefällt mir

    Antwort
    1. Conny Dethloff

      Danke für die Antwort.

      Ja genau. Ich glaube ganz fest daran, dass man nur dann eine Methode versteht, wenn man die Situation und auch die Gedankengänge des Erfinders der Methode nachvollzogen hat. Dann versteht man nämlich erst den Kontext des Entstehens der Methode. Und nur wenn man Verständnis über eine Methode erlangt hat, kann man diese auch passfähig, weil in den richtigen Kontexten, einsetzen.

      Gefällt mir

      Antwort
  3. Aplikmuj

    Agil verbreite sich da es (wieder mal) an der Zeit war die Hinwendung zu Methoden in den 90ern bottom up zu überwinden. Agil hat zwei wesentliche Merkmale

    a) Herauslösen der Softwareentwicklungsorganisation und die Ausrichtung noch deren Bedarfen
    b) Fokus auf das fertige Ergebnis

    Die Prozessmethoden der 90er und auch Projektmanagement haben genau das Gegenteil verfolgt.

    Softwareentwicklung ist stark mit der Verbreitung von Agil verbunden.

    Die Fragen im Artikel der ‚Kunden‘ kommen entspringen der Idee, dass man bspw. Softwareentwicklung und Engineering genauso wie eine Industrielinie entlang eines Unternehmensmodells top-down könnte orchestrieren und Budgetierung gezielt dematerialisieren.

    Die Dematerialisierung passiert eher wie in einer klassischen Sicht auf eine Industrieline, dass der Kollaps in eine Allmende (Zustand in dem sich Investition nicht mehr rechnet) schlagartig passiert und zeitgleich mit massiver Dematerialisierung von Arbeit in der einstigen Linie.

    Solche Linien setzen vorklassische (Selbstständig), Manufaktur bis kleinen Mittelbetrieb Strukturen frei die dann zu einem etwas höheren Preisindikator auf gehobenen technologischen Niveau den Bedarf decken.

    Die grobe Daumen mal Pi Anwendungen liegen auf der Hand
    1) normale Arbeit die grundsätzlich andere Ziele verfolgt als ‚zur Arbeit‘ gehen. (Kent Beck)
    2) Kanban. Die Ergebnisse stehen fest, aber nicht die Reihenfolge der Fertigstellung. Deswegen braucht der Mitarbeiter (Betonung auf Arbeiten vs. am Betriebsgelände zu verweilen) die Möglichkeit seinen Zeitrahmen im Fall von Urgenzen flexibel auszuweiten. Wenn das Ende absehbar ist und ein (Teil)ergebnis fertig wird reps. werden soll muss man Vollgas geben können
    3) Projekt. Es ist klar wie das Ergebnis aussieht, aber nicht klar er die fertiggestellten Ergebnisse liefert.
    4) Scrum. Keiner weiß was das Ergebnis sein soll und schon gar nicht der Kunde und damit ist sonnenunklar wer was in welcher Zeit liefert. Durch Hütchenspielerein wird noch probiert dem Entwicklung im Rahmen der Umkehrung der Kunden/Lieferantenbeziehung die Zeitschätzung zu entlocken. Die Projektmanager in 3 wollten das durch Fragen ermitteln :). Hinzu kommt jetzt die Eliminierung von 40% zuviel geschätzt und drücken der Zeitrahmen welche zum genialen Schluss führte, dass in der Regel mehr Stunden anfallen und damit besser man sich eine Off-Shore organisiert aka. Research.

    Ich rechne Scrum zu agil hinzu, auch die Anwendung davon heute vielerorts mit den dahinterstehenden Ideen wenig zu tun hat. Die meisten Methoden in der IT scheitern an der Verbreitung als Muster und auch Prozesse zu taylorn (maßzuschneidern) löst das Problem nicht. Overhead im Umfeld von Arbeit ist immer übel (herbeiorchestrierte Scheinarbeit), aber hat der irrtümlichen Anwendung per se nichts zu tun.

    Die Priorisierung im Kanban ist ein Rückfall von 2) auf die Prioritätensteuerung in Queues in 1).

    agil: bottom up und liberal. Alles andere sind Versuche marxistischen Unsinn top-down in der Entwicklung zu verankern. Agile ‚Methoden‘ sind nicht abgespeckte Prozessmethoden der 90er die aus für heutige Verhältnisse und damals in Europa nicht anders wurden versucht zu verbreiten. Agil war die Reaktion drauf.

    Der Irrsinn in Deutschland war der German Scrum. Darunter versteht man die versammelten Versuchte anhand der vermeintlichen Erkenntnisse aus Artefakten den vermeintlichen ‚lean‘ anmutenden Standardprozesse zu optimieren und oder zu taylorn. Die Zahlen gewonnen aus Scrum Artefakten sagt allein etwas über die lebbaren Performance im Rahmen eines Teams unter sonst gleichen Bedingungen in der Zukunft aus.

    Ich persönlich mache einen Kanban und wenn es großer wird das gute alte Hermes aus der Schweiz. Ich bin nicht agil sondern mache Kaizen und an sich radikal. Wer aus dem bei dem ein Verbesserungswürdiger Zustand eintritt kann zum besten Zeitpunkt, nämlich jetzt wo das Problem auftritt, eine Verbesserung umsetzen. Die Rolle des Scrummasters wird eher auf Bedarf zeitnah im Team abgebildet. Unsere Entwicklung ist eher pragmatisch, komponentenorientiert usw… (typische Schlagwörter aus dem Kaizen Umfeld). Ein gelebter Prozess muss mit der Umsetzungstechnologie auch zusammenpassen.

    Der Enterprise Scrum führt am Ende zu dem Product Owner gefallene Wegwerfsoftware die mit möglichst wenig Aufwand erstellt werden soll. Während hingegen ein passend gelebter Scrum ähnlich wie bei der legendären Planung der Geburtstagsparty eher durch die Nebel von Avalon wird gewatet bis die Sonne scheint.

    Es spielen ja Teamdynamiken auch mit. Gute Teams schaffen 3 Projekte und lösen sich dann auf.


    Woher sollen das die jungen Menschen wissen. Als die IBM Hosts/Mainframes und die großen UNIX Linien kollabierten wurde stillschweigend zwischen Businesses und den Herstellern vereinbart, dass die Programmier Schuld sind. Der notwendige Schritt damals wäre gewesen die Server in Rechenzentren bei den ‚Big Vendors‘ reinzustellen. Das ging nicht.

    Sonst hätte der Glaube an das Industriemodell und die IT einen riesen Reputationsschaden erlitten. Mit der Einführung der Rollen, Methoden, Systemsicht und Modellierung sollten Programmierer rehabilitiert werden. Damals kamen auch die Prozessmodelle auf mit denen versucht wurde top-down und mit Budgets die gelebte Realität in eine formale Hülle zu pressen.

    Die Rollen sind bspw. der Software Entwickler als aufgemotzer Programmierer, Architekt, Designer, Berater usw…

    Mit Technical Debt geht oft einher die altbekannte und liebgewonnene Schuldzuweisung auf einen ‚Programmierer‘ in einer spezifischen Rolle.

    Die IBM Mainframes wurden praktisch temporär in der Abteilung als Server dezentralisiert und dann wieder konsolidiert zuerst in den Serverraum, das Rechenzentrum (on premise) und jetzt wieder off premise. Der Unterschied ist, dass die Hardware und Softwarebestandteile von unterschiedlichen Herstellern kommen. Auch aus dem Grund kommt es zu einer Überlagerung von Peer To Peer und serverzentriert welche sich wieder auflöst.

    Das ganze hat sich noch vermischt mit dem PC der viele Produkte aus der realen Welt dematerialisierte (bspw. Uhren). Der PC Applikationen wanderten auf ein Schnurlostelefon Tablet oder das Smartphone und teile der Logik wurden in die Errichtung befindlichen Rechenzentren ausgelagert.

    Mit den Clouds sind diese verwirrten 3 Dekaden mit ca. 2015 vorbei. 3 Lost Decades.

    Daraus ergeben sich zwei Chancen. Programmierung wird eher wieder ein normale Arbeit in Unternehmen die Software entwickeln und die Businesses und der top-down Orchestrationswahn sind endgültig Geschichte. Auf der anderen Seiten wird die Arbeit der Programmierer wieder mathematisch und technischer (Computer Science). Es stellt sich mir die Frage ob ‚agil‘ sich halten wird und ob nicht die alten Probleme welche die Softwareentwickler plagten jetzt die Businesses wird treffen für alle die dazu verdonnert werden mit Spezialsprachen Aufgaben eigenständig zu adressieren.

    Eines ist sicher. Wenn die Prediger von Methoden am Horizont erscheinen, dann ist das aktuell gelebte Paradigma schon Vergangenheit resp. reif zur Ablöse ;).

    Gefällt mir

    Antwort

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

w

Verbinde mit %s