IT und Management geht wenig bis gar nicht. Und schuld ist Komplexität. Denn IT lebt Komplexität, und klassisches, tayloristisch geprägtes Management weiss nicht, wie es damit umgehen soll. Also wird man sich nicht einig, und die offizielle Welt löst sich völlig von der inoffiziellen, die die Arbeit macht. Warum ist das so?
1. 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.
2. !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 :-)
3. 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 :-).
4. Die fieseste
Branche der WeltDienstag, 24. Juni 14
Wir sind erwiesenermassen die fieseste Branche der Welt.
5. 39%
in Time, Scope &
Budget
Dienstag, 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.
6. Häufig
20 %
Selten oder Nie
50 %
Gelegentlich
30 %
Dienstag, 24. Juni 14
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.
7. Brooks‘s Law
Adding manpower
to a late software project
makes it later.
Dienstag, 24. Juni 14
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?
8. Wie lange brauchen
100.000 Zeilen Code?
> 20Personen: 8.9Monate
<= 5Personen: 9.1Monate
Dienstag, 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.
9. Pair-Programming
1+1 = 3?
Dienstag, 24. Juni 14
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.
10. 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.
11. 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?
13. Dave Snowden
Dienstag, 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 :-).
14. Study the
actual,
not the
„official“
management practice
Dienstag, 24. Juni 14
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.
15. Komplex Kompliziert
Chaotisch Einfach
Verwirrung
Dienstag, 24. Juni 14
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.
16. Einfach
Der Zusammenhang zwischen
Ursache und Wirkung ist bekannt,
vorhersagbar und wiederholbar.
Dienstag, 24. Juni 14
Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine
Überraschungen zu erwarten. Hier weiss ich alles, was ich wissen muss.
17. Einfach
Beispiele:
Email schreiben
Browser bedienen
Es ist keine Rückfrage notwendig
Dienstag, 24. Juni 14
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.
18. Einfach
Erkennen
Kategorisieren
Reagieren
Best Practice
Dienstag, 24. Juni 14
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.
19. Kompliziert
Ursache und Wirkung sind über
Zeit und Raum getrennt, aber
nachvollziehbar und
wiederholbar.
Dienstag, 24. Juni 14
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.
20. 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.
21. Erkennen
Analysieren
Reagieren
Kompliziert
Good Practice
Dienstag, 24. Juni 14
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.
22. Chaotisch
Der Zusammenhang zwischen
Ursache und Wirkung ist nicht
erkennbar.
Dienstag, 24. Juni 14
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.
23. 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.
24. Handeln
Erkennen
Reagieren
Chaotisch
Novel Practice
Dienstag, 24. Juni 14
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.
25. Komplex
Im Nachhinein ist ein
Zusammenhang zwischen
Ursache und Wirkung erkennbar.
Es ist nicht vorhersagbar, aber eine
Wiederholung kann passieren.
Dienstag, 24. Juni 14
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.
26. 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.
27. Probieren
Erkennen
Reagieren
Komplex
Emergente
Praktiken
?
Dienstag, 24. Juni 14
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?
29. Komplex
Einfach
Einfach
Chaotisch
Einfach
Komplex
Kompliziert
Dienstag, 24. Juni 14
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.
31. verstärken
dämpfend
Einfach
Einfach
Chaotisch
Einfach
Komplex
Kompliziert
Dienstag, 24. Juni 14
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.
32. Einfach
Einfach
Chaotisch
Einfach
Komplex
Kompliziert
Dienstag, 24. Juni 14
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.
33. !
"
#
$
%
&
Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
Software
Web Frontend
Dienstag, 24. Juni 14
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.
34. Team
Scrummaster
Product Owner
Senior Dev
Junior Dev
QA
User Experience
Dienstag, 24. Juni 14
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?
35. Dienstag, 24. Juni 14
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.
36. Masterplan.
Reaktion auf
Umgebung
Dienstag, 24. Juni 14
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.
37. Hierarchie.
Selbstorganisation
Dienstag, 24. Juni 14
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.
38. Schon 10% dynamische Anteile
ergeben ein komplexes System.
Dienstag, 24. Juni 14
Gerhard Wohland nennt das in seinen Denkwerkzeugen „Rot“ für dynamische und „Blau“ für
steuerbare Prozesse, in Cynefin gesprochen simpel oder kompliziert.
41. Strategien:
Kompliziert
Wasserfall
Detailliertes Pflichtenheft
Micromanagement
Meilensteinplan
Agil zum Reporting
Feste Ziele
Good Practice
Dienstag, 24. Juni 14
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.
42. •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
Dienstag, 24. Juni 14
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?
43. •Selbstorganisiert
•Team!
•Adaptiv
•Cross-Funktional
•Emergente Praktiken: 5-3-2, 3-4-3
Komplex
Dienstag, 24. Juni 14
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.
44. Warum wollen Manager
komplexe Aufgaben
kompliziert lösen?
Dienstag, 24. Juni 14
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?
45. Dienstag, 24. Juni 14
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.
46. Need for
Closure
Dienstag, 24. Juni 14
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.
47. Kontrollillusion
Dienstag, 24. Juni 14
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.
48. Extrinsic
incentive bias
Dienstag, 24. Juni 14
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?
50. Surviving
ComplexityDienstag, 24. Juni 14
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.
51. Surviving
„When we created
Scrum we did not talk
about Lean, we talked
about complex
adaptive systems.“
Jeff Sutherland
Dienstag, 24. Juni 14
Tatsächlich kommt zB explizit Scrum aus der Diskussion komplexer Adaptiver Systeme.
52. Development
Surviving
Agile Methoden:
Extreme Programming
Scrum
Crystal Clear
Feature Driven Development
Dienstag, 24. Juni 14
Die agilen Methoden sind emergente Praktiken. Dinge, von denen man durch Erfahrungen
und Experimente in der Praxis festgestellt haben, dass sie oft funktionieren.
53. Surviving
•Funktionieren häufig, nicht immer
•Funktion startet & endet spontan
•entstehen durch Praxis
•brauchen Feedbackmechanismen
Emergente
Praktiken
Dienstag, 24. Juni 14
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.
54. Surviving
DevOps
Continuous Deployment
Lean Startup
Kanban
Emergente
Praktiken
Dienstag, 24. Juni 14
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.
55. Organisation
Surviving
Einfach/Kompliziert Komplex
Management On-Demand Leadership
Gesteuert Selbstorganisiert
Zentral Dezentral
Budgetiert Marktgesteuert
Positionen Rollen
Regeln Kultur
Matrix Gilden/Communities
Organigramm Netzwerk
Dienstag, 24. Juni 14
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.
56. Organisation
Dienstag, 24. Juni 14
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.
57. Holacracy
„no job titles, no managers, no hierarchy“
Dienstag, 24. Juni 14
Das klingt auf den ersten Blick sehr weitreichend, passiert aber - einer der bekanntesten Fälle
ist Zappos. Getitelt wurde das mit
58. 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.
59. •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
Dienstag, 24. Juni 14
Es gibt eine Reihe von Sachen, die wir schon machen und die gut funktionieren.
63. 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?
Dienstag, 24. Juni 14
Wie finde ich heraus, ob mein Problem komplex ist?
65. Anforderungen
Surviving
Produktvision
Personas
User Stories
Product Owner
Sprint Reviews / Backlog Grooming
Dienstag, 24. Juni 14
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.
66. Surviving
Continuous Integration
Continuous Deployment
Release Burndown
Variabler Scope
Releasemanagement
Dienstag, 24. Juni 14
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.
68. Surviving
Staffing
T-Shaped Personen
Teamverantwortung
Cross-Functional Teams
Emergente Rollen
!Titel & Positionen
Dienstag, 24. Juni 14
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.
69. Surviving
Entscheidungen
Teamentscheidungen/Konsent
Emergente Entscheidungen
Jede Entscheidung auf Widerruf
Dienstag, 24. Juni 14
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.
70. Surviving
Management
!Entscheidungen
Servant Leadership
Stewardship
Bossless Teams
Adaptiv ! strategisch
Inspiration
Dienstag, 24. Juni 14
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.