Surviving Complexity

Surviving
Complexity
http://slideshare.net/johannhartmann
Dienstag, 24. Juni 14
Hallo! Das da ist Rex Kramer, Gefahrensucher aus dem Kentucky Fried Movie.
Der Johannes meinte auf einer der letzten Konferenzen zu mir „kannst du nicht mal sowas
wie den Talk „Management Brainfucks“ bei uns machen, aber ohne das wort „Fuck“ zu
erwähnen. Da habe ich ja gesagt, klar immer, wenn Judith auch da ist sowieso. Ich weiss gute
Gesellschaft zu schätzen. Aber das Thema in 25 Minuten - das ist eine
Gefahrensucheraufgabe.

!Consultant
„Manager“
Hacker
Eine Präamble vorweg: ich bin kein Consultant, ich berate nicht und will auch gar nicht
beraten. Ich bin Gründer, Geschäftsführer und CTO eines Softwaredienstleisters mit knapp 80
Kollegen, habe in diesem Kontext auch Erfahrungen als Gründer einer Security-Firma und
Early-Seed-Investor bei Firmen wie Swoodoo oder Makara. Unternehmer oder, mir persönlich
am liebsten, Hacker ist treffender. Ich komme also aus der Realität, auch wenn ein paar der
kommenden Slides ein bischen theoretisch sind. Vor ein paar Jahren habe ich einen Workshop
auf der Webinale über DevOps mit BDD gemacht :-)

Die wichtigste
Nebenrolle zu
Judiths Talk.
ManagementDienstag, 24. Juni 14
Judith und ich haben schon aus Versehen Vorträge zusammengehalten, und sind gerne auf
den gleichen Themen unterwegs - so auch heute. Netterweise kommen wir immer von
unterschiedlichen Seiten bei den gleichen Themen an. So auch heute :-).
So ein bischen doppelt ist drin, aber das mache ich ganz schnell :-).

Die ﬁeseste
Branche der WeltDienstag, 24. Juni 14
Wir sind erwiesenermassen die ﬁeseste Branche der Welt.

39%
in Time, Scope &
Budget
Schauen wir uns doch mal unsere Branche an - wir ITler liefern, wenn man dem Standish
Group Chaos Report trauen darf, nur in 39% der Fälle das, was wir versprochen haben zum
richtigen Zeitpunkt, mit den versprochenen Kosten. Das ist mal unglaublich, dass wir damit
durchkommen und bislang keiner auf die Idee kam, einfach mal die ganze Branche zu feuern.
Ist es bei Euch deutlich besser? Das ist der Lake Wobegon Effekt, 80% aller Leute halten sich
für überdurchschnittlich.

Häuﬁg
20 %
Selten oder Nie
50 %
Gelegentlich
30 %
Ebenfalls aus dem Chaos Manifest 2013: Es wird nicht besser wenn man anschaut, was wir da
meist verspätet oder nie liefern - die Hälfte aller Features wird selten oder nie genutzt. Es
gibt nur 20% Features, die wirklich oft genutzt werden.

Brooks‘s Law
Adding manpower
to a late software project
makes it later.
Jetzt könnte man sagen, wir sind schlicht alle inkompetent. Aber das stimmt nicht, wir sind
nur komisch. Wer kennt Brooks‘s Law? Wer glaubt, dass es zutrifft?
Auch hier verhält sich Software sehr seltsam. Ich habe 5 Leute, die in 1 Monat 20 Features
schaffen. Wenn ich da noch 5 Leute dazustelle, dann schaffen die 10 nur noch 18? Sollte hier
nicht zumindest was Dreisatz-ähnliches gelten?

Wie lange brauchen
100.000 Zeilen Code?
> 20Personen: 8.9Monate
<= 5Personen: 9.1Monate
Aus einer Studie von Doug Putnams QSM über mehr als 500 Projekte: Teams mit weniger als
6 Personen brauchen im Mittel nicht nennenswert länger als Teams mit über 20 Personen, um
100.000 Zeilen Code zu erstellen.

Pair-Programming
1+1 = 3?
Der Dreisatz geht in der Softwareentwicklung noch weiter kaputt, wenn man sich zum
Beispiel Dinge wie Pair Programming anschaut. Das wird durch beliebige Studien unter Labor-
wie Realbedingungen belegt, Pair Programming ist produktiver als die Entwicklung von 2
Personen jeweils alleine.

50Dienstag, 24. Juni 14
Noch seltsamer wird es, wenn man sich die Performance von Teams anschaut - eine einfache
Arbeitsgruppe, bei der man nicht Zusammenarbeitet ist zB effektiver als ein Team im
entstehen - dafür kann ein sehr gut funktionierendes Team auch Faktor 50 über dem
Branchenschnitt ( Borland / Bell Labs) produktiv sein. Es kann aber auch sein, dass man auf
Höhe des Pseudoteams bleibt.

Wie soll man so etwas
bitteschön managen?!Dienstag, 24. Juni 14
Wenn man sich diese Dinge anschaut fragt man sich natürlich - wie soll das bitteschön
gemanaged werden? Wie soll man damit umgehen?

Das wollte auch diese Firma wissen.

Dave Snowden
Und die hat diesen Menschen beauftragt, das herauszuﬁnden. Er kommt aus Wales und
forscht an der Komplexitätstheorie im Bereich Sensemaking. Wie cool ist das bitteschön. Und
weil es wirklich dafür sorgt, dass viele Dinge auf einmal Sinn ergeben, geh ich da auch noch
mal drauf ein :-).

Study the
actual,
not the
„ofﬁcial“
management practice
Und IBM hat ihm einen sehr schönen Auftrag gegeben:
die echten Managementmethoden, die praktiziert wurden, und nicht die offiziellen
anzugucken. Und da gab es ein interessantes Ergebnis. Mit einem interessanten Namen.

Komplex Kompliziert
Chaotisch Einfach
Verwirrung
Und so sieht das aus.
Und mit diesen Quadranten kam Herr Snowden am Ende heraus
Er sagt: Manager nehmen ihre Arbeitswelt als komplex, kompliziert, chaotisch oder einfach
wahr. Und je nach Wahrnehmung agieren sie anders.

Einfach
Der Zusammenhang zwischen
Ursache und Wirkung ist bekannt,
vorhersagbar und wiederholbar.
Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine
Überraschungen zu erwarten. Hier weiss ich alles, was ich wissen muss.

Einfach
Beispiele:
Email schreiben
Browser bedienen
Es ist keine Rückfrage notwendig
Im Software Development gibt es kaum Beispiele für solche Tätigkeiten, selbst ein CRUD oder
ein zusätzliches Formular braucht Rückfragen. Für Entwickler sind E-Mail schreiben und
Browser bedienen solche Tätigkeiten.

Einfach
Erkennen
Kategorisieren
Reagieren
Best Practice
Weil man auf bekanntem Gelände ist kommt man gut und planbar voran. Das sind genau die
Tasks, die wir gut schätzen können, ohne erst groß speziﬁzieren und planen zu müssen.
Also arbeitet man nach dem System erkennen - kategorisieren - reagieren. Das Reagieren
ergibt sich zwangsläuﬁg aus dem Kategorisieren, und es gibt eine bekannte Best Practice, wie
zu reagieren ist.

Kompliziert
Ursache und Wirkung sind über
Zeit und Raum getrennt, aber
nachvollziehbar und
wiederholbar.
Wenn ich im komplizierten Quadranten bin ist es nicht mehr trivial, aber machbar. Es ist
besser, wenn ich eine Ausbildung und/oder Erfahrung mitbringe. Wird auch Knowable
genannt, man kann es also sicher wissen, wenn man will. Hier gibt es Dinge, die ich anfangs
noch nicht weiss, in die ich erst Gehirnschmalz stecken muss.

Beispiele:
Formulare / Reports
Layout
Es kann immer wie geplant umgesetzt
werden.
KompliziertDienstag, 24. Juni 14
Für solche Tätigkeiten brauche ich spezielles Knowhow und ich muss recherchieren. Es ist die
Domäne von Experten und ausgebildeten Personen. Wenn ich mich mit dem Thema
auskenne, und wenn ich mich vorbereite kann ich die Aufgabe verbindlich in der erwarteten
Zeit umsetzen.

Erkennen
Analysieren
Reagieren
Kompliziert
Good Practice
Bei solchen Problemen gehe ich nach Erkennen - Analysieren - Reagieren vor. Das heisst,
dass ich in Analysieren Zeit stecken muss, bevor ich reagieren kann. Und dass es keine Best
Practice gibt, sondern nur gut practice - denn die konkrete Reaktion ergibt sich aus dem
Vorwissen und der Analyse, und beides kann sich unterscheiden.

Chaotisch
Der Zusammenhang zwischen
Ursache und Wirkung ist nicht
erkennbar.
In Chaotisch wirds gemein. Es gibt keinen erkennbaren Zusammenhang zwischen Ursache
und Wirkung. Man weiss nicht, was kommt, und man weisst dementsprechend auch nicht, wie
man sich vorbereiten soll.

Beispiele:
Heisenbugs
Hackereinbruch
„Hoffentlich bringt das jetzt was.“
ChaotischDienstag, 24. Juni 14
In der Praxis gibt es auch regelmässig solche Situationen. Es gibt keine Sache die man tun
könnte die wahrscheinlich zu einem Erfolg führt. Sondern ich probiere einfach Dinge aus und
gucke, ob sie geholfen haben.

Handeln
Erkennen
Reagieren
Chaotisch
Novel Practice
Und genau so ist der Vorgehen - Ich mache etwas - quasi ohne Nachdenken zuvor - und
erkenne, was es bewirkt hat, und reagiere dann darauf. Shotgun-Debugging oder Chicken
Voodoo sind Antipattern in der Softwareentwicklung, die darauf basieren. Ich probiere
einfach solange, bis es funktioniert.

Komplex
Im Nachhinein ist ein
Zusammenhang zwischen
Ursache und Wirkung erkennbar.
Es ist nicht vorhersagbar, aber eine
Wiederholung kann passieren.
Komplex ist gemein. Im Nachhinein kann ich den Zusammenhang zwischen Ursache und
Wirkung nachvollziehen. Vorher kann ich die Wirkzusammenhänge nicht sehen, und
dementsprechend nicht mit Ihnen planen. Aber ich verstehe sie, während ich im komplexen
System agiere.

Beispiele:
Schachspiel
Innovative Software
! Kleine Software
Ich weiß noch nicht, was am Ende
genau herauskommen wird.
KomplexDienstag, 24. Juni 14
Komplexe Tätigkeiten sind unser tägliches Brot in der IT. Das gilt aber auch für die Business-
Seite, speziell im Umgang mit Menschen und Märkten.

Probieren
Erkennen
Reagieren
Komplex
Emergente
Praktiken
?
In einem komplexen System probiere ich etwas aus, erkenne die Wirkung und reagiere
darauf. Aber ich habe einen vorteil gegenüber der chaotischen Welt, und es haben sich
bestimmte Praktiken bewährt, nämlich emergente. Emergent heisst: von alleine entstehend,
auftauchend oder wachsend. Aber warum ist das so?

Komplexe
Adaptive
Systeme
Das liegt am Verhalten von komplexen Systemen, konkret an komplex adaptiven Systemen.
Was ist so ein System?

Komplex
Einfach
Einfach
Chaotisch
Einfach
Komplex
Kompliziert
Komplexe Systeme bedeutet, dass ich verschiedene Komponenten habe, die autark agieren.
Diese Komponenten können selbst simpel sein, oder komplex. Oder Chaotisch.
Wenn ich das jetzt vorhersagen sollte würde ich mir jedes Teil angucken und daraus die
Summe ausrechnen.

Einfach
Einfach
Chaotisch
Einfach
Komplex
Kompliziert
Aber genau das kann ich nicht - denn die Elemente selbst sind vernetzt und reagieren
aufeinander.

verstärken
dämpfend
Einfach
Einfach
Chaotisch
Einfach
Komplex
Kompliziert
Diese Beziehungen können verstärkend wirken, oder auch Abschwächend. Es kann Zyklen
geben, die deutlich mehr Verstärkung erzeugen. Und es gibt Schleifen.
Und genau auf die Weise entstehen Schmetterlingseffekte, bei denen durch kleinen
Ressourcenaufwand erhebliche Wirkung erzielt wird.

Einfach
Einfach
Chaotisch
Einfach
Komplex
Kompliziert
Daneben gibt es auch Einﬂüsse von aussen, auf die Ebenfalls reagiert wird und die das
Verhalten der einzelnen Elemente und des Gesamtsystems beeinﬂussen. Damit das System
auf Ausseneffekte reagieren kann müssen diese gleich schnell oder schneller durchgeführt
werden können.

!
"
#
$
%
&
Workﬂow Engine
ORM
User Management
Business Objects
E-Commerce-Module
Software
Web Frontend
Software selbst ist ein komplexes System. Gerade in der Entwicklung, wenn noch nicht klar
ist, wie alle Teile genau aussehen könen bzw welche Konsequenzen die Interaktionen haben.

Team
Scrummaster
Product Owner
Senior Dev
Junior Dev
QA
User Experience
Und natürlich das Team selbst ist zB eins. Es gibt Leute die sich in Kooperation verstärken, es
gibt Leute, die sich ausbremsen. Es gibt Momente, in denen es unglaublich gut läuft. Wer
trifft die Entscheidungen in einem Team?

Ein klassisches Beispiel für ein Komplexes Adaptives System ist eine Ameisenkolonie. Die
einzelne Ameise versteht nicht die ganze Kolonie, und kann auch nicht einordnen, welche
Rolle sie im Gesamtsystem spielt. Die Intelligenz ﬁndet nicht im Individuum statt, sondern im
System - im Verhalten der Gesamten Kolonie - statt.

Masterplan.
Reaktion auf
Umgebung
Es gibt also keinen Masterplan, über den das ganze System funktioniert - sondern die
einzelne Ameise reagiert auf ihre Umgebung, und arbeitet im Sinne von Cyneﬁn simple -
erkennen von Quantitäten oder Qualitäten von Sinneseindrücken, dann wird ein einfacher
Ablaufplan abgespult. Trotzdem ist die Ameisenkolonie als ganzes im Stande, eine grössere
Struktur zu bilden und komplizierte Prozesse am Leben zu erhalten.

Hierarchie.
Selbstorganisation
Die Organisation entsteht durch die Aktionen, die Reaktionen und die Kooperation von
Leuten. Es gibt keine Hierarchie, bei der irgendjemand eine Entscheidung trifft, die dann an
andere zur Umsetzung übergeben wird. Weil niemand das Gesamtbild haben kann, kann auch
niemand alleine eine gute Entscheidung treffen.

Schon 10% dynamische Anteile
ergeben ein komplexes System.
Gerhard Wohland nennt das in seinen Denkwerkzeugen „Rot“ für dynamische und „Blau“ für
steuerbare Prozesse, in Cyneﬁn gesprochen simpel oder kompliziert.

Komplex Kompliziert
Chaotisch Einfach
Probieren
Erkennen
Reagieren
Erkennen
Analysieren
Reagieren
Handeln
Erkennen
Reagieren
Erkennen
Beurteilen
Reagieren
Verwirrung
Schauen wir noch einmal auf das Diagramm von vorhin. Neben den 4 Kategorien gibt es noch
eine fünfte - hier schwarz und nämlich Verwirrung. Verwirrung entsteht dann, wenn man die
bevorzugten Methoden eines Quadranten benutzt, aber die Realität um einen herum sich
anders gestaltet.

Standardverfahren
Standardprozesse
Handlungsanweisungen
Dokumentation
Fixer Baukasten
Einfach
Best Practice
Strategien:
Wenn er denkt er wäre in einer einfachen Welt, dann fordert er die Regeln der Welt an. Man
erkennt es: Standardverfahren/prozeduren, Handlungsanweisungen, Dokumentation, ﬁxe
Baukästen, generatoren und module als Lösungen für _alles_.
Baukästen sind gut für die simplen Teile, aber nicht für komplexe Systeme.

Strategien:
Kompliziert
Wasserfall
Detailliertes Pﬂichtenheft
Micromanagement
Meilensteinplan
Agil zum Reporting
Feste Ziele
Good Practice
Wenn er denkt er wäre in einer komplizierten Welt, und man könnte alles im vorhinein wissen
oder Fragen, dann möchte er Planen, Messen, Kontrollieren und Steuern. Und man sieht dort
Dinge wie wasserfalliges Vorgehen, die Fragen nach Pﬂichtenheften als Dokumentation des
vollständigen benötigten Wissens etc.

•Detaillierter Spielplan
•Milestones Tor 1 (Minute 20),
Tor 2 (Minute 40), Gegentor (Minute 60)
•Der Trainer gibt
detaillierte Anweisungen
•Spieler haben nur
Verantwortung für ihren Bereich
•Jahresbonus für Ballkontakte und Km
Kompliziert
Aber nehmen wir mal ein Beispiel aus einer anderen Welt - die gerade aktuell ist,
Entschuldigung für das Foto von 2012. Wer glaubt an einem WM-Titel, wenn Deutschland so
spielt?

•Selbstorganisiert
•Team!
•Adaptiv
•Cross-Funktional
•Emergente Praktiken: 5-3-2, 3-4-3
Komplex
Stattdessen verhält sich das Fussballteam fast lehrbuchmässig wie der Umgang mit Komplex-
Adaptiven Systemen. Sie sind selbstorganisiert - der Trainer schreit zwar vom Rand, wird
aber nur wahrgenommen wenn der Spieler selbst hinguckt. Er analysiert dafür die ganze Zeit
den Gegner, die Mitspieler und verfolgt den Ball. Es werden Dinge probiert, nach Instinkt, und
Dinge die funktionieren werden wiederholt.

Warum wollen Manager
komplexe Aufgaben
kompliziert lösen?
Wie komplexe Systeme bzw. komplexe-Adaptive-Systeme funktionieren wissen wir eigenlich
seit Mitte der achtziger Jahre. Und seit Mitte der neunziger Jahre wissen wir auch, wie das
Management von solchen Systemen geht. Trotzdem versuchen wir es immer anders. Warum
ist das so?

Gerhard Wohland gibt eine Begründung dafür, und nennt ihn die Taylor-Wanne. Bis zum
Anfang des 20. Jahrhunderts konnten wir fabelhaft mit Komplexität umgehen, weil wir
handwerklich arbeiteten. Mit der Industrialisierung gab es auf einmal eine andere
Erfolgsgeschichte - die Managementseite, die komplizierte Aufgaben übernahm und die
ausführende Seite, die simple Aufgaben übernahm. Das war eine Erfolgsgeschichte. Leider
hat aber genau bei der IT und später dann mit Netz und Globalisierung bei anderen das
Gegenteil eingesetzt - es gibt wieder mehr Komplexität. Aber wir sind noch die alte
Erfolgsgeschichte gewöhnt, auch wenn sie heute nicht mehr funktioniert. Unternehmen, die
mit Komplexität umgehen können üben genau den Marktdruck aus, die die klassischen
Unternehmen erleiden müssen.

Need for
Closure
Unser Gehirn möchte nicht mit vagen, unbestimmten und sich ändernden Dingen zu tun
haben, wie ein komplexes System sie mitbringt. Es möchte verlässliche Antworten und
Lösungen wie simple Systeme mit Best Practices und komplizierte Systeme mit Good Practices
erzeugen.

Kontrollillusion
Daneben ist unser Gehirn nicht für Komplexität ausgelegt. Unsere Heuristiken wollen etwas
anderes. Zum Beispiel die Kontrollillusion: wir glauben Dinge steuern zu können, die faktisch
praktisch nur zum kleinsten Teil von uns gesteuert werden. Das gilt nicht nur für Lotto, das
gilt auch für Management von IT-Projekten.

Extrinsic
incentive bias
Der extrinsic incentive bias zeigt, dass wir zwar bei uns selbst im Regelfall intrinsische
Motivationen unterstellen, bei anderen aber denken, dass sie extrinsisch motiviert sind.
Dementsprechend vertrauen wir selbstorganisierten Themen nicht so richtig, sondern möchte
lieber selbst steuern. Wer hat einen Jahresbonus?

Bitte kein
Komplex!
Unser Gehirn möchte also nicht komplex, sondern bevorzugt andere Varianten.

Surviving
ComplexityDienstag, 24. Juni 14
Aber wie gehe ich mit Komplexität um? Was sind emergente Praktiken, die häuﬁg
funktionieren? Hier gehe ich schnell durch, damit es irgendwie zu schaffen ist.

Surviving
„When we created
Scrum we did not talk
about Lean, we talked
about complex
adaptive systems.“
Jeff Sutherland
Tatsächlich kommt zB explizit Scrum aus der Diskussion komplexer Adaptiver Systeme.

Development
Surviving
Agile Methoden:
Extreme Programming
Scrum
Crystal Clear
Feature Driven Development
Die agilen Methoden sind emergente Praktiken. Dinge, von denen man durch Erfahrungen
und Experimente in der Praxis festgestellt haben, dass sie oft funktionieren.

Surviving
•Funktionieren häuﬁg, nicht immer
•Funktion startet & endet spontan
•entstehen durch Praxis
•brauchen Feedbackmechanismen
Emergente
Praktiken
Das heisst, dass agile Methoden nicht immer funktionieren müssen. Aber sie funktionieren
statistisch häuﬁg. Um festzustellen ob sie bei mir funktionieren muss ich sie ausprobieren. Es
kann sein, dass sie funktionieren, es kann sein, dass sie nicht funktionieren. Es kann sein,
dass sie spontan aufhören zu funktionieren und später wieder beginnen.

Surviving
DevOps
Continuous Deployment
Lean Startup
Kanban
Emergente
Praktiken
Emergente Praktiken gibt es natürlich nicht nur im Development, sondern auch in Produktion,
in Produktentwicklung etc. Dort sind sie ebenfalls durch Erfahrung entstanden und sind
geblieben, weil sie sich bewährt haben. Sie stammen nicht aus einem theoretischen Modell,
sondern aus der Praxis.

Organisation
Surviving
Einfach/Kompliziert Komplex
Management On-Demand Leadership
Gesteuert Selbstorganisiert
Zentral Dezentral
Budgetiert Marktgesteuert
Positionen Rollen
Regeln Kultur
Matrix Gilden/Communities
Organigramm Netzwerk
Das endet aber nicht bei der Softwareentwicklung. Für praktisch jeden Aufgabenbereich im
Unternehmen gibt es Methoden, die für komplexe und damit auch sich dynamisch wandelnde
Aufgaben taugen.

Organisation
Hier habe ich mal ein Beispiel aus Betacodex, bei dem keine klassische Hierarchie mehr
existiert, und die Zentrale eine ganz andere Rolle hat - nämlich Services und Synergieeffekte
auf Wunsch der äusseren Organisationseinheiten zu liefern.

Holacracy
„no job titles, no managers, no hierarchy“
Das klingt auf den ersten Blick sehr weitreichend, passiert aber - einer der bekanntesten Fälle
ist Zappos. Getitelt wurde das mit

Development
OperationsProduktentwicklung
Marktdruck
Management Organisation
Agile KaskadeDienstag, 24. Juni 14
Und so sieht das konkret aus, wenn der Markt mehr Dynamik fodert: Weil die
Produktentwicklung zu langsam für den Markt ist, muss sie ﬂexibel werden und landet im
agilen. Wenn es dort funktioniert bleibt man an den Operations hängen, die noch Freezes und
monatliche Releases fahren, und dort wird Continuous Deployment und DevOps eingeführt.
Sobald der Kanal zum Kunden steht stimmt Qualität und Quantität in der Produktentwicklung
nicht mehr, und auch dort wechselt man zu kundennahen, dynamischen Verfahren. Auf
dieser Strecke, beginnend mit IT, stört klassisches Management als Querschnittsfunktion
zunehmend, und hier werden Themen wie Servant Leadership, Management 3.0 etc
diskutiert. Und am Ende dreht sich die komplette Organisation zu einer dezentralen,
marktgesteuerten und dynamischen.

•Agil, DevOps etc konsequent
•Teams wählen Teamstellvertreter
•Operations:Backlog über DevOps-Gilde
•Servant Leadership über Visual Kanban
•Quartalsweise Bewertung der
Management-Runde
•Emergente Entscheidungsverfahren
•Unternehmensretrospektiven
•Openspace, Slacktime, ...
Eigene Erfahrungen
Es gibt eine Reihe von Sachen, die wir schon machen und die gut funktionieren.

Hingehen:
http://intrinsify.me/
http://stoosnetwork.org/
Management 3.0, Agile Management Innovations, Holacracy
Lesen:
Nils Pﬂaeging: „Organisation für Komplexität.“
Steve Denning: „Radical Management“
Jurgen Apello: „Management 3.0“
Gerhard Wohland: „Denkwerkzeuge für Höchstleister“

Danke!
Surviving
Fragen -> hartmann@mayﬂower.de
Gute Fragen -> @johannhartmann

Addon
Slides!

Einfach
Kom
pli
ziert
Komplex
Chaotisch
Close to Certainty Far from Certainty
Farfrom
Agreement
Closeto
Agreement
Wie planbar ist die Umsetzung?
Wie sicher ist
meine
Anforderung?
Wie ﬁnde ich heraus, ob mein Problem komplex ist?

Einfach
Kom
pli
ziert
Komplex
Chaotisch
Close to
Certainty
Far from
Certainty
Farfrom
Agreement
Closeto
Agreement
Die Stacey-Matrix gibt einem die Möglichkeit, die Aufgaben einzuordnen - und zwar nicht
nur in die Quadranten aus Cyneﬁn, sondern auch Klassiﬁziert nach Vorhersehbarkeit und
Einigkeit über die Ausführung.
Agreement ist die Einigkeit über die Anforderungen, die das System leisten muss, die
Certainty ist die technische Umsetzbarkeit.

Anforderungen
Surviving
Produktvision
Personas
User Stories
Product Owner
Sprint Reviews / Backlog Grooming
Agiles Anforderungsmanagement hat ein anderes Ziel: es geht nicht darum etwas
bestimmtest zu implementieren, sondern das zum Zeitpunkt der implementierung bekannte
wertvollste.
Um das herausﬁnden zu können braucht man ein gemeinsames Bild vom Produkt und der
Wertschöpfung dahinter - und dazu dienen diese Tools.

Surviving
Continuous Integration
Continuous Deployment
Release Burndown
Variabler Scope
Releasemanagement
Im Komplexen ist Releasemanagement nicht plangetrieben, sondern vor allem empirisch -
man versucht also auf dem Weg Daten zu erzeugen und zu sammeln, die möglichst wertvoll
sind - und mit diesen kontinuierlich neu zu planen.

Surviving
Architektur
Walking Skeleton
Emergente Architektur
Agile Modeling
Architectural Spikes
Architektur in komplexen Systemen ist ebenfalls empirie- und kooperationsgetrieben.

Surviving
Stafﬁng
T-Shaped Personen
Teamverantwortung
Cross-Functional Teams
Emergente Rollen
!Titel & Positionen
Selbstorganisierte Teams, kollektive Intelligenz und schnelles Lernen stellt auch
Anforderungen an das Staffing. Es gibt keine ﬁxierten Positionen und Titel, keine Hierarchien.
Aufgaben werden gemeinsam von einem crossfunktionalien Team bearbeitet, das sich selbst
organisiert. Es gibt keine individuelle Accountability.

Surviving
Entscheidungen
Teamentscheidungen/Konsent
Emergente Entscheidungen
Jede Entscheidung auf Widerruf
Das hat auch folgen auf die Entscheidungsﬁndung. Individuelle Spezialistenentscheidungen
sind gut in komplizierten Umgebungen, Standards in einfachen Umgebungen. Komplexe
Umgebungen brauchen möglichst viel Intelligenz bzw. Impact-bewertung, deshalb sind sie
nicht individuell, sondern werden gemeinsam gefunden - das heisst aber nicht demokratisch,
sondern eben Konsent, Decider, Decision Matrix etc.

Surviving
Management
!Entscheidungen
Servant Leadership
Stewardship
Bossless Teams
Adaptiv ! strategisch
Inspiration
Das Management dreht sich ebenfalls deutlich. In komplexen Umgebungen ist eine
hierarchische Entscheidung der Versuch, sie am Punkt der maximalen Inkompetenz zu
treffen. Statt dessen muss hier Leadership passieren, sprich: die Teams selbst müssen in die
Lage versetzt werden, gute Entscheidungen zu treffen und gut zu arbeiten. Und das gibt ganz
neue Aufgaben.

Surviving
Organisation
Querschnittteams
Autonomie = Transparenz = Verantwortung
!Bonus

Surviving Complexity

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (6)

En vedette

En vedette (14)

Similaire à Surviving Complexity

Similaire à Surviving Complexity (20)

Plus de Johann-Peter Hartmann

Plus de Johann-Peter Hartmann (20)

Surviving Complexity