Wie organisiert man Komplexität? Zu dieser Frage gibt es ja einiges an Literatur und die agilen Methoden sind nichts anderes als eine Antwort auf die Frage nach der Organisation von Komplexität. Das Problem dabei ist, dass alle diese Methoden von einer relativ losen Koppelung der Akteure und Prozesse ausgehen. Nur dann ist die notwendige Flexibilität zur Reaktion auch gegeben. Gleichzeitig gehört auch eine hohe Fehlerakzeptanz dazu, den das Kernprinzip all dieser Methoden ist ja die kontinuierliche Verbesserung der Abläufe und Prozesse bei gleichzeitiger, laufender Anpassung der Strurkturelemente an sich verändernde Rahmenbedingungen.
Was mir jedoch bei aller Freude an agilen Methoden und bei längerem Nachdenken etwas schwer im Magen liegt, ist die Anwendung solcher Methoden im Hochrisikobereich, in dem – naheliegenderweise – eine sehr enge Koppelung der Prozesse und Abläufe, ja sogar Verantwortlichkeiten, zu den Kernprinzipien der Vermeidung von Sicherheitsrisiken gehört.
Sind agile Methoden überhaupt geeignet, in diesen Bereichen Anwendung zu finden? Können sie überhaupt in eng gekoppelten Strukturen ihre Wirkung entfalten und wollen wir das überhaupt? Ich tue mich gerade schwer, bei dem Gedanken in einem Kernkraftwerk, in dem – bereits technisch bedingt – die Prozessabläufe, Verantwortungskette und auch die technischen Abläufe so eng gekoppelt sind, dass nur die geringste Störung in den enggekoppelten Abläufen eine Katastrophe provozieren kann, einen agilen Ansatz vorzustellen.
Sind also agile Konzepte nur in einem Umfeld mit lose gekoppelten Systemen anwendbar? Mit dieser Frage muss ich mich wohl näher auseinandersetzen …
Agilist aus Überzeugung - Lean-Enthusiast und Kanban-Fan - Veränderungsbegleiter - Dipl.-Verw.Wiss. - MBA - 🇮🇪 Irland-Fan - Mitgründer Forum Agile Verwaltung
Alle Beiträge von Thomas Michl anzeigen
Veröffentlicht
8 Kommentare zu „#Gedankenblitz: Komplexität, agile Methoden und enge Koppelung“
Oh, da gibt es auch „einiges an Literatur“. Standardwerk ist wohl der Karl Weick mit „Das Unerwartete managen“. Er spricht von HPO – high performance organizations. Kernkraftwerke gehören dazu, aber auch das Chirurgenbusiness („wrong side surgery“) oder das Pilotenbusiness. Und Konzentration auf Fehler ist genau eine der (bei Weick fünf) Grundpfeilern von Hochrisikounternehmen. Auch bei James Reason („Human Errors“) findest Du vieles darüber. Ich halte mich in Projekten lieber an die HPO- und Fehlerforschung als an agiles Vorgehen, obwohl beides verwandt ist. Wenn Du Weick oder Reason liest, wirst Du als Agilitätsexperte immer wieder ausrufen: „das ist genau agiles Vorgehen!“. Für mich sind die Erkenntnisse der HPO- und Fehlerforschung aber subtiler und sogar spannender.
Irgendwo in der Mitte fragte ich mich, was denn dieser Hochrisikobereich sei und dachte noch so „Tot ist tot,“ Das Beispiel mit dem Kernkraftwerk bestätigte diesen Gedanken dann. Beim Kernkraftwerk fällt mir die Lösung aber einfach. Einfach darauf verzichten, dann gibt es auch nicht dieses Problem.
Klingt vielleicht nicht so nach einer Antwort mit der man weiter kommt, aber ich frage mich schon, warum man es auf der einen Seite Risiko nennt und dann doch wieder so tut als dürfte der Fail nur ja nie eintreten. Wenn man ein Risiko eingeht, muss man auch bereit sein zu verlieren. Wenn man nicht verlieren darf, kann man das Risiko nicht eingehen.
Schöner Einwand. Ich habe das Beispiel mit dem Kernkraftwerk übrigens gewählt, weil da die Dramatik der engen Koppelung besonders gut (und einfach) darstellbar ist. Man muss sich allerdings schon die Frage stellen, ob man überhaupt im Hochrisikobereich tätig wird, wenn die Folgen eines Fehlers so dramatisch sind … ist der Supergau passiert, lässt er sich nicht mehr rückgängig machen oder korrigieren.
Es geht hier ja nicht um die Kernkraft. Das ist nur einer von vielen HPO. Auch Feuerwehr oder Anlagenbetrieb (thermische Kraftwerke, chemische Fabriken, Bergbau) gehören dazu. Es geht doch hier um die Frage, wie solche Systeme angesichts menschlicher Grenzen betrieben werden können.
Fehler brauchen überhaupt nicht dramatische Konsequenzen zu haben. Ich schätze, dass ein Pilot innerhalb einer Flugstunde im Schnitt 10 Fehler macht. Dennoch setze ich mich in eine Flugzeug. Wie Reason zeigte, kommt es nur zu einem GAU, wenn mehrere Sicherungen gleichzeitig versagen oder sich mehrere gleichzeitige Fehler kumulieren.
Da Beispiel mit dem Piloten ist ähnlich wie da Beispiel mit dem Kernkraftwerk. Die Prozesse sind eng gekoppelt. Deshalb mehrfache Sicherung, um das Risiko oder besser Fehler entweder zu vermeiden oder Systemausfälle durch Fehler deutlich zu verringern. Gleichzeitig sind die Abläufe und Prozesse extrem durchnormiert z. B. klare Leitlinien, Checklisten zur Vorbereitung u. ä. um die Risiken zu minimieren. Insgesamt ein vergleichsweises restriktives Gesamtsystem.
im Zuge meines Buchkonzeptes „Fail fast“ geht es um das Scheitern… und da passt das ganz gut hin. Es gibt Innovationsbereiche, da ist frühes Scheitern wichtig. Es gibt aber auch laufende Prozesse da ist Scheitern teuer.
Sinnvoll ist es, das eine vom anderen zu unterscheiden.
Toms Gedankenblog 
Oh, da gibt es auch „einiges an Literatur“. Standardwerk ist wohl der Karl Weick mit „Das Unerwartete managen“. Er spricht von HPO – high performance organizations. Kernkraftwerke gehören dazu, aber auch das Chirurgenbusiness („wrong side surgery“) oder das Pilotenbusiness. Und Konzentration auf Fehler ist genau eine der (bei Weick fünf) Grundpfeilern von Hochrisikounternehmen. Auch bei James Reason („Human Errors“) findest Du vieles darüber. Ich halte mich in Projekten lieber an die HPO- und Fehlerforschung als an agiles Vorgehen, obwohl beides verwandt ist. Wenn Du Weick oder Reason liest, wirst Du als Agilitätsexperte immer wieder ausrufen: „das ist genau agiles Vorgehen!“. Für mich sind die Erkenntnisse der HPO- und Fehlerforschung aber subtiler und sogar spannender.
LikeGefällt 1 Person
Danke für den Hinweis – muss ich mir mal näher ansehen. Ich habe wohl noch zu sehr Charles Perrow im Hinterkopf.
http://de.wikipedia.org/wiki/Charles_Perrow
LikeLike
Irgendwo in der Mitte fragte ich mich, was denn dieser Hochrisikobereich sei und dachte noch so „Tot ist tot,“ Das Beispiel mit dem Kernkraftwerk bestätigte diesen Gedanken dann. Beim Kernkraftwerk fällt mir die Lösung aber einfach. Einfach darauf verzichten, dann gibt es auch nicht dieses Problem.
Klingt vielleicht nicht so nach einer Antwort mit der man weiter kommt, aber ich frage mich schon, warum man es auf der einen Seite Risiko nennt und dann doch wieder so tut als dürfte der Fail nur ja nie eintreten. Wenn man ein Risiko eingeht, muss man auch bereit sein zu verlieren. Wenn man nicht verlieren darf, kann man das Risiko nicht eingehen.
LikeGefällt 1 Person
Schöner Einwand. Ich habe das Beispiel mit dem Kernkraftwerk übrigens gewählt, weil da die Dramatik der engen Koppelung besonders gut (und einfach) darstellbar ist. Man muss sich allerdings schon die Frage stellen, ob man überhaupt im Hochrisikobereich tätig wird, wenn die Folgen eines Fehlers so dramatisch sind … ist der Supergau passiert, lässt er sich nicht mehr rückgängig machen oder korrigieren.
LikeLike
Es geht hier ja nicht um die Kernkraft. Das ist nur einer von vielen HPO. Auch Feuerwehr oder Anlagenbetrieb (thermische Kraftwerke, chemische Fabriken, Bergbau) gehören dazu. Es geht doch hier um die Frage, wie solche Systeme angesichts menschlicher Grenzen betrieben werden können.
Fehler brauchen überhaupt nicht dramatische Konsequenzen zu haben. Ich schätze, dass ein Pilot innerhalb einer Flugstunde im Schnitt 10 Fehler macht. Dennoch setze ich mich in eine Flugzeug. Wie Reason zeigte, kommt es nur zu einem GAU, wenn mehrere Sicherungen gleichzeitig versagen oder sich mehrere gleichzeitige Fehler kumulieren.
LikeGefällt 1 Person
Da Beispiel mit dem Piloten ist ähnlich wie da Beispiel mit dem Kernkraftwerk. Die Prozesse sind eng gekoppelt. Deshalb mehrfache Sicherung, um das Risiko oder besser Fehler entweder zu vermeiden oder Systemausfälle durch Fehler deutlich zu verringern. Gleichzeitig sind die Abläufe und Prozesse extrem durchnormiert z. B. klare Leitlinien, Checklisten zur Vorbereitung u. ä. um die Risiken zu minimieren. Insgesamt ein vergleichsweises restriktives Gesamtsystem.
LikeLike
HPO – auch besser HRO: High Reliability Organizations
LikeGefällt 1 Person
Hallo Thomas,
im Zuge meines Buchkonzeptes „Fail fast“ geht es um das Scheitern… und da passt das ganz gut hin. Es gibt Innovationsbereiche, da ist frühes Scheitern wichtig. Es gibt aber auch laufende Prozesse da ist Scheitern teuer.
Sinnvoll ist es, das eine vom anderen zu unterscheiden.
Das in aller Kürze.
Lg
Patrick Koglin
http://www.agile-is-limit.de
LikeLike