Surviving Complexity

SurvivingComplexity

http://slideshare.net/johannhartmannDienstag, 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.

http://slideshare.net/johannhartmann

http://slideshare.net/johannhartmann

!Consultant

„Manager“

Hacker

Dienstag, 24. Juni 14

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 fieseste Branche der Welt


Wir sind erwiesenermassen die fieseste Branche der Welt.

39%in Time, Scope &

BudgetDienstag, 24. Juni 14

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äufig20 %

Selten oder Nie50 %

Gelegentlich30 %


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?

> 20 Personen: 8.9 Monate

<= 5 Personen: 9.1 MonateDienstag, 24. Juni 14

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?!


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 SnowdenDienstag, 24. Juni 14

Und die hat diesen Menschen beauftragt, das herauszufinden. 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

„official“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 herausEr 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

ErkennenKategorisierenReagieren

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ß spezifizieren und planen zu müssen.Also arbeitet man nach dem System erkennen - kategorisieren - reagieren. Das Reagieren ergibt sich zwangsläufig 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.

ErkennenAnalysierenReagieren

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.

HandelnErkennenReagieren

ChaotischNovel 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.

ProbierenErkennenReagieren

KomplexEmergente 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?

KomplexeAdaptive 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 Einflüsse von aussen, auf die Ebenfalls reagiert wird und die das Verhalten der einzelnen Elemente und des Gesamtsystems beeinflussen. Damit das System auf Ausseneffekte reagieren kann müssen diese gleich schnell oder schneller durchgeführt werden können.

!

"

#

$

%

&Workflow Engine

ORM

User Management

Business Objects

E-Commerce-Module

SoftwareWeb 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 findet 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 Cynefin 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 Cynefin gesprochen simpel oder kompliziert.

Komplex Kompliziert

Chaotisch Einfach

ProbierenErkennenReagieren

ErkennenAnalysierenReagieren

HandelnErkennenReagieren

ErkennenBeurteilenReagieren

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.

StandardverfahrenStandardprozesseHandlungsanweisungenDokumentationFixer 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, fixe 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

WasserfallDetailliertes Pflichtenheft

MicromanagementMeilensteinplan

Agil zum ReportingFeste 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 Pflichtenheften 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.

SurvivingComplexity


Aber wie gehe ich mit Komplexität um? Was sind emergente Praktiken, die häufig 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

ScrumCrystal 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äufig, nicht immer•Funktion startet & endet spontan•entstehen durch Praxis•brauchen Feedbackmechanismen

EmergentePraktiken


Das heisst, dass agile Methoden nicht immer funktionieren müssen. Aber sie funktionieren statistisch häufig. 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

DevOpsContinuous Deployment

Lean StartupKanban

EmergentePraktiken


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 KomplexManagement 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 flexibel 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 Pflaeging: „Organisation für Komplexität.“Steve Denning: „Radical Management“Jurgen Apello: „Management 3.0“Gerhard Wohland: „Denkwerkzeuge für Höchstleister“


http://stoosnetwork.org

http://stoosnetwork.org

Danke!

SurvivingFragen -> [email protected]

Gute Fragen -> @johannhartmann


mailto:[email protected]

mailto:[email protected]

AddonSlides!


Einfach

Kompli ziert

Komplex

Chaotisch

Close to Certainty Far from Certainty

Far

fro

m

Agr

eem

ent

Clo

se t

o

Agr

eem

ent

Wie planbar ist die Umsetzung?

Wie sicher ist meine

Anforderung?


Wie finde ich heraus, ob mein Problem komplex ist?

Einfach

Kompli ziert

Komplex

Chaotisch

Close to Certainty

Far from Certainty

Far

fro

m

Agr

eem

ent

Clo

se t

o

Agr

eem

ent


Die Stacey-Matrix gibt einem die Möglichkeit, die Aufgaben einzuordnen - und zwar nicht nur in die Quadranten aus Cynefin, sondern auch Klassifiziert 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

ProduktvisionPersonas

User StoriesProduct 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 herausfinden zu können braucht man ein gemeinsames Bild vom Produkt und der Wertschöpfung dahinter - und dazu dienen diese Tools.

Surviving

Continuous IntegrationContinuous Deployment

Release BurndownVariabler 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 SkeletonEmergente Architektur

Agile ModelingArchitectural Spikes


Architektur in komplexen Systemen ist ebenfalls empirie- und kooperationsgetrieben.

Surviving

Staffing

T-Shaped PersonenTeamverantwortung

Cross-Functional TeamsEmergente Rollen

!Titel & Positionen


Selbstorganisierte Teams, kollektive Intelligenz und schnelles Lernen stellt auch Anforderungen an das Staffing. Es gibt keine fixierten 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/KonsentEmergente Entscheidungen

Jede Entscheidung auf Widerruf


Das hat auch folgen auf die Entscheidungsfindung. 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 LeadershipStewardship

Bossless TeamsAdaptiv ! 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

QuerschnittteamsAutonomie = Transparenz = Verantwortung

!Bonus


Surviving Complexity

Leadership & Management

auch heute