Die modernisierte Fassung der "Management Brainfucks": Warum wehren sich Manager gegen agile Methoden, obwohl diese zu ihrem Vorteil wären? Warum behindern sie uns Entwickler bei der Arbeit mit Formalien, Blaming, naiven Lösungsvorschlägen und Kontrollillusion? Der Talk zeigt die Wurzeln dieses Missverständnisses und wie man sich darausbewegt.
1. Agile
vs
Management
Hallo zusammen. Willkommen zum Talk Agile vs Management. Guten morgen.
Ich hoffe, Sie sind alle gut angekommen.
2. Wissens-vermittlung
Wenn sie noch ein bisschen erschöpft sind ist das kein Problem, in diesem Talk brauchen Sie sich nichts zu merken - denn es geht nicht um
Wissensvermittlung.
4. Hier haben wir einen der Menschen, die Nichtwissen popularisiert haben.
5. Donald
Rumsfeld
Das ist Donald Rumsfeld, seines Zeichens ehemaliger Verteidigungsminister der USA, Erfinder von Bio- Atom- Chemiewaffen im Irak, und einer der
profiliersten Nichtwisser der Welt.
6. „We do know of certain
knowledge that Osama
Bin Laden is either in
Afghanistan, or in some
other country, or dead.
And we know of certain
knowledge that we don't
know which of those
happens to be the case."
Donald
Rumsfeld
Um einmal ein Beispiel zu geben - 2001 begann der Afghanistankrieg, um mit Osama Bin Laden den Verantwortlichen hinter dem World Trade Center
Attentat zu finden. Glücklicherweise wusste man genau, wo er sich befand:
In Afghanistan - praktisch, denn man hatte die Truppen ja schon da - in einem anderen Land (eher unpraktisch) oder er war schon tot. Faktisch hatte man
also keine Ahnung, wo er war. Aber man wusste immerhin sicher dass man nicht wusste wo er war.
7. „But there are
also unknown
unknowns –
there are things
we do not
know we don't
know.“
Donald
Rumsfeld
Und Donald Rumsfeld war nicht nur ein Praktiker des Nichtwissens, er hat auch am theoretischem Unterbau der Ahnungslosigkeit gearbeitet. Und nicht
nur die einfache Ahnungslosigkeit, sondern auch die Ahnungslosigkeit, dass man Ahnungslos ist.
Wer sich noch erinnern kann - Rumsfeld galt damals als mächtiger Idiot. Kann jemand so ahnungslos wie er sein?
8. „Wie lange würde ein
kompletter Rewrite
mit node.js dauern?“
Aber schauen wir doch mal auf unsere eigene Welt. Und nehmen wir eine Frage, die heutzutage jedem dritten Entwickler von seinem Chef gestellt wird.
„Wie lange würde ein kompletter Rewrite der Software auf Basis von Node.Js und MongoDB bauen? Und was sagen wir, wenn wir das gefragt werden?
„Vermutlich ziemlich genau zwischen 3 Monaten und 3 Jahren.“
9. Wir kennen die Software.
Wir kennen alle Features.
Wir haben sie schon
alle einmal implementiert.
Wir kennen node.js gut.
!
Wir wissen es trotzdem nicht.
Das muss man sich mal auf der Zunge zergehen lassen: wir kennen schon alle Features, wir wissen wie es aussieht, trotzdem haben wir in Wahrheit keine
Ahnung. Und der Vorgesetzte fragt uns, warum wir das nicht wissen.
10. !Wir können nicht
einmal gut erklären, warum
wir das nicht wissen.
Und dann gucken wir irritiert und sagen ihm: Ja, weil es nicht geht. Ich könnte schon was sagen, aber das würde dann vermutlich nicht stimmen. Das war
immer so.
11. " 4 % Successful
47 % Challenged
49 % Failed
Rewrites
Die Standish-Group - ja, die mit dem Chaos-Report - hat auch mal eine Auswertung über den Erfolg von solcher Komplett-Rewrites gemacht. Und nur 4%
schaffen es in Zeit und Budget, 47% verreissen Zeit und Budget, und 49% werden ganz eingestellt.
12. "Selbst wenn wir es
wieder und wieder
gezeigt haben.
Wir haben es also empirisch wieder und wieder gezeigt, dass die Schätzungen sogar auf bekanntem Terrain massiv daneben liegen. Trotzdem glauben
Manager häufig, dass es eigentlich anders sein muss, und hier einfach besser geschätzt und kalkuliert werden muss.
13. ?
Zwei Programmierer
werden effizienter wenn
einer arbeitet und
der andere zuguckt
Pair Programming
Dieses Unverständnis gilt auch für die Methoden, die wir einsetzen.
Zum Beispiel Pair Programming: Ich setzte zwei Developer an die gleiche Aufgabe, und am Ende sind sie effizienter. Für einen Manager ist das völlig
unplausibel. Wenn einer eine Aufgabe alleine schon machen kann, warum wird der schneller, wenn jemand anderes daneben sitzt und mitdiskutiert?
Warum spart das Zeit, und ist keine grosse Zeitverschwendung?
14. e !
27 %
more productivEine akademische Case-Study von Jensen aus 2003 hat einen Produktivitätsvorsprung von 27% durch Pair Programming nachgewiesen. Das waren echte
Projekte, und man kann ihnen vorwerfen, dass sie zufällig passiert sind und es unter Laborbedingungen ganz anders ausgesehen hätte.
15. 101 %
more productive !
Und in der Tat sieht es unter Laborbedingungen ganz anders aus: In einem Experiment von 2006, von Xu und Rajlich, wurde sogar eine
Produktivitätssteigerung von 101 Prozent gegenüber einzelner Programmierung nachgewiesen.
16. Ein Programmierer leistet
mehr in 8 Stunden
? als in 14 Stunden?
Overhours
Ein ähnliches Beispiel sind Überstunden. Wenn jemand 8 Stunden arbeitet, und dann noch mal 6 hinterher, dann sollte das zumindest grob in Richtung des
anderthalbfachen an Arbeitsleistung gehen, oder? Faktisch wird ein Entwickler deutlich weniger produktiv, wenn er mehr als 8 Stunden im Mittel arbeitet.
17. 6h
> 8h
! > 14h
Productivity
Für Wissensarbeiter liegt der Peak sogar bei 6h - wenn er 6 Stunden am Tag aktiv arbeitet ist das Maximum erreicht (Quelle: Why Crunch Modes Doesn’t
Work: Six Lessons)
Eine einfache Addition gilt nicht.
18. Text
http://www.lostgarden.com/2008/09/rules-of-productivity-presentation.html
Man weiss sogar, dass jede Überstundenarbeit nach ein paar Wochen zwangsläufig in Erholungsphasen mit kleinerer Produktivität endet, ob man daheim
oder im Büro sitzt. Und dass diese Erholung grösser ist als die Arbeitsphase.
Das heisst, dass der Entwickler in der sechsten Woche zwar 14 Stunden im Büro sitzt, aber die Produktivät einer Halbtagskraft liefern kann.
19. Wenn ich ein
Team deutlich größer mache
? wird es
nicht deutlich produktiver?
Team SizeEs gibt in Brooks Law auch eine Ausprägung davon: Adding people to a late project makes it later. Das ist seit den 80er Jahren bekannt und
dokumentiert, trotzdem passiert der Fehler heute noch regelmässig.
20. ! 100.000 LOC
<5 Personen:
ca 9 Monate
>20 Personen:
ca 9 Monate
Doug Putnam von QSM ist neben der Standish Group der Mensch, der am meisten Statistik über Softwareprojekte betreibt. Und dort haben sie die
Produktivät von grossen und kleinen Teams bewertet, anhand von 100.000 equivalent source lines of code. Und heraus kam, dass mittlere Teams mit 5 bis
9 Leuten nur knapp weniger Code schaffen als grosse Teams mit mehr als 20 Leuten.
Auch hier gilt eine einfache Addition nicht.
21. Die Produktivität
! ist höher
Estimation
wenn ich nicht schätze
wie lange ich brauche.
Und wenn ich nicht schätze wie lange ich brauche bin ich schneller als wenn ich schätzen würde.
22. !
http://davidfrico.com/agile-book.htm
Oder man wendet sich direkt an den Experten, was empirisches Wissen angeht. David F Rico hat im Rahmen seiner Forschung einmal alle Studien auf dem
Gebiet gesammelt und zusammengefasst, und stellt netterweise auch auf seiner Website die Daten zur Verfügung. Das Buch leider nicht.
23. "Selbst wenn wir es
wieder und wieder
gezeigt haben.
Aber, wie bereits oben - das reicht nicht. Es reicht nicht, dass jede Studie, jede akademische Untersuchung, jede Untersuchung von IBM oder Consulting-
Unternehmen beim gleichen Ergebnis herauskommt.
24. "Man kann es
Managern
nicht erklären.
Wir kommen einfach nicht zu den Managern durch. Dieses empirische Wissen hat die gleiche Qualität wie die „Amerikanische Wissenschaftler haben
herausgefunden“-Einspaltenartikel in der Bildzeitung.
25. ? Wer arbeitet mit
Storypoints?
Wer schätzt seine Aufwände in Storypoints?
26. ? Warum nicht
einfach Stunden?
Warum schätzen wir nicht einfach in Stunden, wie damals vorm Krieg. Warum sagen wir nicht einfach: das dauert 3 Tage, und dann dauert es eben drei
Tage?
Weil das eine Kontrollillusion erzeugen würde. Denn was passiert?
27. !„Mein Debugger funktioniert
bei den Unit-Tests nicht.“
„Vagrant startet die virtuelle
Maschine nicht mehr.“
„Der Bug ist erst in
der neuen Library gefixed.
Die braucht andere Updates.“
Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische Beispiele sind ...
Was haben alle diese Punkte gemeinsam?
28. Ich wusste die
Antworten
auf diese Fragen
vorher nicht.
Ich wusste sie vorher nicht. Und nicht nur das.
29. Ich wusste
vorher nicht,
dass ich diese
Fragen habe.
Ich wusste sie vorher nicht. Und nicht nur das.
30. Ich wusste nicht,
was ich
nicht wusste.
Und noch schlimmer: Ich wusste vorher auch noch nicht, dass ich sie nicht wusste.
Also die Unknown Unknowns, von denen Donald Rumsfeld sprach.
31. Orders of
Ignorance
Orders of Ignorance
Das offizielle Organ der Association for Computing Machinery, die Communications of the ACM, haben sich mal einen Kopf darüber gemacht, was man
so alles nicht wissen kann. und das ganze Ausformuliert. Genannt haben sie es die Orders of Ignorance.
32. Ignoranz 0ter Ordnung:
Ich weiß etwas.
Abwesenheit von Ignoranz
Orders of Ignorance
Das klingt zwar jetzt unnötig, macht aber durchaus Sinn. Wenn ich etwas sicher weiß, bin ich nicht ignorant.
33. Ignoranz 0ter Ordnung:
Ich ändere in style.css
die Farbe auf #ffffff
Orders of Ignorance
Wenn ich alles weiß, ist mein Leben einfach. Ich mache es einfach. In diesem Fall weiß ich den Wert, und ich weiß, wo ich ihn eintragen muss.
34. Ignoranz 1ter Ordnung:
Ich weiss etwas
bestimmtes nicht.
Abwesenheit von Wissen
Orders of Ignorance
Wenn ich etwas nicht weiß, geht das auch ok. Solange ich weiß, was ich nicht weiß - und wie ich zu dem Wissen komme.
35. Ignoranz 1ter Ordnung:
Ändere die Farbe in
style.css auf den
Default-Wert
Orders of Ignorance
Wenn in meiner Anforderung steht „Backgroundcolor bitte aus dem Styleguide.“, dann weiss ich zwar die Farbe nicht, ich kann aber nachgucken,
nachfragen oder ähnliches.
36. Ignoranz 2ter Ordnung:
Ich weiß nicht,
was ich nicht weiß.
Abwesenheit von Erkennen.
Orders of Ignorance
Hier kommen wir bei Donald Rumsfeld an, oder bei unserem Business- uns fehlt nicht nur eine Antwort, wir wussten vorher noch nicht mal, dass wir fragen
müssen.
37. Ignoranz 2ter Ordnung:
Mach die Library kompatibel.
Orders of Ignorance
Wenn ich zum Beispiel eine Library kompatibel machen soll, weiss ich vorher nicht, was ich genau tun muss - denn ich weiss noch nicht mal, welche
Anpassungen erforderlich sind. Aber ich kann es herausfinden, und ich weiss, was ich dazu tun muss - Library einbinden und Fehler angucken.
38. Ignoranz 3ter Ordnung:
Ich weiß nicht, wie ich
herausfinde was ich
nicht weiß.
Abwesenheit von Vorgehen
Orders of Ignorance
Und was ist, wenn wir es nicht ausprobieren können?
39. Ignoranz 3ter Ordnung:
Finde die beste Library
auf Github.
Orders of Ignorance
Das ist ein solches Problem. Ich weiss nicht nur nicht, was die beste Library auf github ist, ich weiss auch nicht, was ich tun kann, um das herauszufinden. Es
gibt sicherlich eine beste Library auf Github. Aber ich weiss nicht, was ich tun könnte, um sie zu finden.
40. Ignoranz 4ter Ordnung:
Ich weiß nicht, dass es
unterschiedliche Arten von
Nichtwissen gibt.
Orders of Ignorance
Das wird die anwesenden Informatiker freuen - es gibt auch Meta-Ignoranz, wenn ich nicht weiss, dass es unterschiedlichen Arten von Nichtwissen gibt.
41. Ignoranz 4ter Ordnung:
Es gibt nur 1te Ordnung:
!
Ich weiss etwas
bestimmtes nicht.
Orders of Ignorance
Und genau da liegt eines der Management-Probleme: es gibt in Ihrer Welt nur Nichtwissen erster Ordnung. Ich muss vorher alle richtigen Fragen stellen,
dann weiss ich alles und kann nach Plan vorgehen.
42. Und wir?
Wie sieht es
bei uns ITlern aus?
Orders of Ignorance
Aber welche Form der Ignoranz ist bei uns denn massgeblich?
43. Und wir?
Nichtwissen erster Ordnung
kann man im Vorfeld klären.
Orders of Ignorance
Schauen wir doch einmal nach. Wissen erster Ordnung ist welches wie die Stylesheet-Farbe. Ich kann es einfach im Vorfeld klären, indem ich recherchiere.
Also müsste ein Big Upfront Design gut funktionieren, denn dort findet die Fragenklärung statt.
44. CHAOS REPORT 2012
KLASSISCH
29 %
14 %
57 %
Successful
Challenged
Failed
Quelle: Standish Group Chaos Report 2012
Die größte Studie zum Thema Softwareprojekte ist der Standish Group Chaos Report, den es seit über 20 Jahren gibt. Und der dokumentiert die traurige
Wahrheit, die uns Softwareleuten seit 20 Jahren Sorge macht und als „Softwarekrise“ quasi zu einem Dauerbrenner geworden ist. Nur 14% Prozent aller
Projekt sind in Time & Budget. 57 % laufen aus dem Budget und / oder der Zeitline, und 29 % werden nie fertiggestellt.
45. CHAOS REPORT 2012
AGILE
9 %
49 %
42 %
Successful
Challenged
Failed
Quelle: Standish Group Chaos Report 2011
Bei agilen Projekten sehen die Zahlen besser aus - 42% sind erfolgreich, und nur 9% scheitern vollständig. Immer noch nicht besonders, aber besser als
vorher. Wie kann das denn sein? Ich verspreche Deadlines mehr sondern schaffe sie ab, und trotzdem halte ich sie besser? Dabei gab es doch gar keine
vernünftige Planung!
46. STANDISH GROUP
REWRITES
4 %
49 % 47 %
Successful
Challenged
Failed
Ja, Planung. Das wird sogar noch schlimmer. Wenn ich einen Rewrite machen habe ich praktisch den High Score von Planung. Die Software, ihre
Anforderungen, ihre Implementierung, alles ist schon da. Und trotzdem sinken die Chancen sogar noch einmal deutlich, was das Einhalten von Time &
Budget angeht.
47. Scope Creep +
(fehlendes Erkennen auf Kundenseite)
Dark Matter
(fehlendes Erkennen auf Developmentseite)
=50%
Ignorance 2ter Ordnung
Wenn man tatsächlich auf die Projekte und auf die Projektstatistik schaut - in diesem Fall ist die Quelle David J Andersons agile Manager - dann leuchtet
er sehr ein.
Es gibt zwei Sorten von Unknown Unknows, die bei uns eine grosse Rolle spielen - Scope Creep, das sind die Features, von denen der Nutzer vorher noch
nicht weiss, dass sie ihm fehlen werden - und Dark Matter, Programmierung von der wir bei Beginn der Entwicklung noch nicht Wissen, dass wir sie
brauchen, um die Features bereitzustellen.
48. Was mache ich in
so einer Branche?
Wie gehe ich damit um, wenn ich so viele Dinge habe, die ich nicht weiss?
Mit Dingen die ich nicht weiss kann ich ja nichts machen, oder? Oder kann ich damit Arbeiten, wenn ich unknown unknowns habe?
50. Dave Snowden
Und die hat diesen Menschen beauftragt, das herauszufinden. Er kommt aus Wales und forscht an der Komplexitätstheorie im Bereich Sensemaking.
51. 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.
52. Cynefin
Lebensraum,
Platz
Und zwar mit dem Cynefin-Framework. Ich hoffe ich spreche es richtig aus, mein walisisch ist etwas eingerostet. Cynefin beschreibt meine Umgebung, die
Welt, in der ich lebe - und zwar inklusive Ort, Kultur und Leuten.
53. Komplex Kompliziert
Verwirrung
Chaotisch Einfach
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.
54. Der Zusammenhang zwischen
Ursache und Wirkung ist
bekannt, vorhersagbar und
wiederholbar.
Einfach
Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine Überraschungen zu erwarten. Ignoranz 0ter Ordnung: ich weiss
alles.
55. Beispiele:
Email schreiben
Browser bedienen
!
Es ist keine Rückfrage notwendig
Einfach
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.
56. Erkennen
Kategorisieren
Reagieren
Best Practice
Einfach
Ignoranz 0ter Ordnung
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.
57. Ursache und Wirkung sind über
Zeit und Raum getrennt,
aber nachvollziehbar und
wiederholbar.
Kompliziert
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 habe ich Ignoranz erster Ordnung: ich weiss, dass ich etwas bestimmtes
noch nicht weiss.
58. Beispiele:
CRUD
Layout anpassen
!
Es kann immer wie geplant
umgesetzt werden.
Kompliziert
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.
59. Erkennen
Analysieren
Reagieren
Good Practice
Kompliziert
Ignoranz 1ter Ordnung
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.
60. Der Zusammenhang zwischen
Ursache und Wirkung ist
nicht erkennbar.
Chaotisch
In Chaotisch wirds gemein. Es gibt keinen erkennbaren Zusammenhang zwischen Ursache und Wirkung. Chaotisch ist dominiert von Ignoranz dritter
Ordnung, also: ich weiss nicht, was ich nicht weiss, und ich habe auch keinen Weg, mit dem ich es verlässlich herausfinde.
61. Beispiele:
Heisenbugs
Software ohne Source
!
„Hoffentlich bringt das jetzt was.“
Chaotisch
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.
62. Handeln
Erkennen
Reagieren
Novel Practice
Chaotisch
Ignoranz 3ter Ordnung
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.
63. Im Nachhinein ist ein
Zusammenhang zwischen
Ursache und Wirkung erkennbar.
Es ist nicht vorhersagbar, aber eine
Wiederholung kann passieren.
Komplex
Komplex ist gemein. Bei Komplexen Welten habe ich es mit Second Order Ignorance zu tun, also mit Unknown Unknowns. Im Nachhinein kann ich den
Zusammenhang zwischen Ursache und Wirkung nachvollziehen, denn die Unknown Unknowns sind zunächst zu Known Unknowns geworden, also zu
bekannten Problemen - und mit der Lösung selbst sind sie dann zu Knowns geworden. Ich kann es aber nicht vorhersagen. Denn beim nächsten Mal
müssen es ganz andere Unknown Unknowns sein, denn sie sind nach Definition nicht bekannt.
64. Beispiele:
Schachspiel
Innovative Software
Komplexe Software
Ich weiß am Anfang nicht, was am
Ende genau herauskommen wird.
Komplex Ignoranz 2ter Ordnung
Komplexe Tätigkeiten sind unser tägliches Brot.
65. Einfach
Einfach
Chaotisch
Einfach
Komplex
Kompliziert
Komplex
Weiss jemand, was ein komplexes System ist?
Zunächst einmal besteht ein komplexes System aus mehreren Elementen. Diese Elemente selbst können ebenfalls komplex sein - aber auch einfach,
kompliziert oder chaotisch. Und sie verhalten sich jeweils individuell.
66. Einfach
Einfach
Chaotisch
Einfach
Komplex
Kompliziert
Komplex
Und diese Elemente interagieren, sie wirken aufeinander. Die Ausgabe eines Elementes ist der Eingangskanal des anderen, beim nächsten verbraucht sie
gemeinsame Ressourcen und limitiert so dessen Wirkung.
67. Einfach
Einfach
dämpfend
Chaotisch
Einfach
Komplex
Kompliziert
verstärkend
Komplex
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 es gibt Schleifen, die sich verstärken und hochpendeln. Weiß jemand wie das hochpendeln genannt wird, wenn mit sehr wenig Input ein sehr grosser
Effekt erzielt wird?
68. Komplex
Genau, das ist ein Schmetterlingseffekt. Mit sehr wenig Ressourceneinsatz - zB dem Flügelschlag eines Schmetterlings - werden woanders auf der Welt
Wirbelstürme in Gang gebracht.
69. Komplex
Wir in der IT sind eher für den umgekehrten Schmetterlingseffekt bekannt. Wir setzen endlos viele Ressourcen ein, und am Ende gibt es nur ganz wenig
Effekt.
70. Einfach
Einfach
dämpfend
Chaotisch
Einfach
Komplex
Kompliziert
verstärkend
Komplex
Und natürlich kommen auch noch äussere Einflüsse dazu, und auch diese können wieder bidirektional sein, und auch dort können sich wieder Schleifen
ergeben.
71. 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.
Faktisch hat so einen Ameise nur einige wenige Sensoren und einige wenige Regeln, nach denen sie ihr Verhalten ausrichtet. Trotzdem kommen
Ameisenhaufen zustanden. Weil die Königin das steuert? Nein :-)
72. Scrummaster
Product Owner
Senior Dev
Team
Junior Dev
QA
User Experience
In einem Softwareteam agieren die Parteien autonom. Niemand hat das Gesamtbild, aber als Team kann man die Gesamtsituation beurteilen und damit
arbeiten, und am Ende kommt eine Software heraus.
73. #
$
%
&
'
(
Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
Software Web Frontend
Auch 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.
74. „When we created Scrum
we did not talk about Lean,
we talked about complex
adaptive systems.“
Jeff Sutherland
Software
Die ganze agile Welt basiert auf diesem Verständnis der Softwarewelt. Jeff Sutherland, der Erfinder von Scrum, hat das in Scrum zu einer Zeit diskutiert
bevor Scrum selbst als Bezeichnung dafür existierte.
75. Im Nachhinein ist ein
Zusammenhang zwischen
Ursache und Wirkung erkennbar.
Es ist nicht vorhersagbar, aber eine
Wiederholung kann passieren.
Und wenn man sowas vor Augen hat ist auch das Verhalten plausibel: Wenn ich ein Team wieder so zusammen an ein neues Projekt setzte, kann ein ganz
anderes Ergebnis herauskommen. Wenn ich die gleiche Architektur für eine andere Lösung einsetze kann sie funktionieren, muss aber nicht. Sogar im
gleichen System muss es nicht mehr funktionieren, weil es sich selbst schon bewegt hat.
76. Im Nachhinein ist ein
Zusammenhang zwischen
Ursache und Wirkung erkennbar.
Es ist nicht vorhersagbar, aber
eine Wiederholung kann
passieren.
Was ist der
richtige Prozess?
Aber dann stellt sich die Frage - was ist denn dann der richtige Prozess? Wenn ich nicht vorhersehen kann was passiert, und Ursache und Wirkung nicht
klar sind, wie soll ich dann vorgehen?
77. Im Nachhinein ist ein
Zusammenhang zwischen
Ursache und Wirkung erkennbar.
Es ist nicht vorhersagbar, aber
eine Wiederholung kann
passieren.
Ausprobieren!
Genau, ich muss es ausprobieren. In dem Moment wo ich mit dem System arbeite habe ich Feedback aus dem System, und ich kann an der Wirkung
erkennen welche Ursachen es hatte. Und damit vorhersagen über die Zukunft treffen. Die eintreffen können - oder auch nicht.
78. Probieren
Erkennen
Reagieren
Emergente
Praktiken
Komplex
Konkret führt also kein anderer Weg um das Anfangen herum, und erst im Verlauf der Arbeit sammle ich Erfahrungen welche Ursachen welche Wirkungen
haben. Wenn ich erkannt habe dass eine Ursache eine bestimmte Wirkung hatte nutze ich sie als Reaktion immer dann, wenn ich diese Wirkung brauche.
Und auf diese Weise ergeben sich emergente Praktiken, mit denen ich einen gewünschten Effekt erreichen kann.
79. Komplex
Kennt jemand das Kürzel PDCA? Genau, das ist der Deming-Circle aus dem LEAN-Umfeld. Bei ihm handelt es sich um eine Abwandlung von Probieren -
erkennen - reagieren. Lean ist - wie die agilen Methoden - ein Toolset das in der Lage ist komplexe Umgebungen zu beherrschen.
80. Ich habe durch Probieren gelernt,
dass B rauskommt
wenn ich A mache.
Emergente
Praktiken
Komplex
Und wenn ich eine Weile mit so einem komplexen System arbeite sammle ich immer mehr solche Praktiken. Ich kenne nicht alle Zusammenhänge warum
das so ist, aber ich weiss aus meiner Erfahrung, dass es statistisch häufig passiert.
81. Ich habe durch Probieren gelernt,
dass gute Qualität rauskommt
wenn ich Tests als erstes mache.
Emergente
Praktiken
Komplex
Ein Beispiel für so eine emergente Praxis ist zum Beispiel Test Driven Development.
82. Ich habe durch Probieren gelernt,
dass mehr Code rauskommt
wenn ich Pair Programming mache.
Emergente
Praktiken
Komplex
Oder Pair Programming.
Was mache ich, wenn ich sehe, dass die Performance nicht höher ist?
Genau, ich mache es nicht.
83. Wenn etwas in 75% der Fälle
geholfen hat, werde ich es auch
weiterhin machen.
Komplex
Oder Pair Programming.
Was mache ich, wenn ich sehe, dass die Performance nicht höher ist?
Genau, ich mache es nicht.
84. Continuous Integration
Daily Scrum
Sustainable Pace
Collective Code Ownership
Story Points
Retrospectives
Osmotic Communication
Slack Time
!
Und genau diese agilen Prinzipien sind emergente Praktiken. Dinge von denen man mal gemerkt hat, dass Software häufig, nicht immer, besser
funktioniert wenn man sie macht.
85. Wie nennt man das,
wenn ein Team
seinen Prozess selbst
entwickelt?
Komplex
Und was passiert, wenn die Minions selbst Dinge probieren, erkennen und darauf reagieren, um herauszufinden welche Praktiken funktionieren und
welche nicht?
86. Selbst-organisation
Probieren
Erkennen
Reagieren
Komplex
Genau, das Resultat ist Selbstorganisation. Muss man das als Scrum einführen? Nein, der Zyklus Probieren->Erkennen->Reagieren ergibt schon aus sich
heraus Selbstorganisation. Fremdorganisation ist gar nicht möglich.
Oder, um mit der Systemtheorie zu sprechen: Selbstorganisation ist das spontane Auftreten neuer, stabiler, effizient erscheinender Strukturen und
Verhaltensweisen (Musterbildung) in offenen Systemen.
87. The best architectures,
requirements, and designs
emerge
from self-organizing
teams.
Komplex
Die komplette agile Entwicklung basiert auf emergenten Praktiken, das ist insbesondere im agilen Manifest zu finden.
88. Agil ist eine Antwort
auf komplexe Aufgaben
Selbstorganisation
Lernschleifen
Emergente Praktiken
Komplex
Und da sind wir eigentlich beim Punkt von Agil. Agil ist schlicht ein Methodenset zur Bearbeitung von komplexen Aufgaben. Alle 3 Teile:
Selbstorganisation, Lernschleifen und Emergente Praktiken sind fixe Bestandteile komplexer adaptiver Systeme.
89. „Insanity: doing the same
thing over and over again
and expecting
different results.“
Und das ist gemein, was das schlicht unser normaler Wissen ausser Kraft setzt.
In komplexen Systemen erwarten wir unterschiedliche Resultate, wenn wir mehrfach das gleiche machen.
90. „You can‘t control what
you can‘t measure.“
Tom DeMarco
Auch dieser Ausspruch von Tom DeMarco gilt nicht. Ich kann in einem komplexen System zwar messen, aber ich kann deshalb noch lange nicht
kontrollieren.
91. „You can‘t control what
you can‘t measure.“
Tom DeMarco
In komplexen Systemen bleibt da nur noch „You can’t control“ übrig. Es geht schlicht nicht mehr. Das hat er irgendwann selbst gemerkt, und den Satz
daher wieder zurückgenommen.
92. Emergente Prozesse
funktionieren oft, nicht immer
Story Points Avg Hours
1 21
2 52
3 64
5 100
8 111
Velocity Hours
8+8=16
111+111=
222
5+3+2+2+2+1+
1=16
100+64+52+52
+52+21+21=
365
Mike Cohn hat sich mal die Mühe gemacht mittlere Zeiten für Story Points zu ermitteln.
Wenn ich die durchschnittlichen Zeiten von Story Points nehme und addiere komme ich auf eine Summe, die aller Statistik nach nicht das gleiche
Aussagen kann.
Wenn ich eine normale Anzahl Stories über mehr als 10 Sprints nehme gibt mir die Velocity trotzdem mehr Aufschluß über Team-Performance und
Releaseplanung als Alternativen.
93. Komplex Kompliziert
Probieren
Erkennen
Reagieren
Erkennen
Analysieren
Reagieren
Verwirrung
Chaotisch Einfach
Handeln
Erkennen
Reagieren
Erkennen
Beurteilen
Reagieren
Und jetzt kommen wir zu dem Punkt, wo die meisten Management-Probleme herkommen.
Wenn ich nicht weiss, in welchem Quadranten ich arbeite, dann bin ich in der Mitte - in der Verwirrung. Und in dem Fall wird auf den Quadranten
zurückgegriffen, in dem man sich am sichersten fühlt.
94. Verwirrung
Methoden aus dem falschen Quadranten.
Genau diese Verwirrung ist die Quelle der meisten Probleme von IT und Management.
95. IT ist meistens
komplex.
Methoden aus dem falschen Quadranten.
Bei IT-Projekten sind meistens die komplexen Eigenschaften dominant. Das gilt längst nicht für alle IT - die zwölfte CMS-Seite auf der gleichen Basis ist
eher einfach, eine Motorsteuerung kompliziert, und im Agenturbereich kurz vor der Messe wird es eher chaotisch.
96. Kompli ziert
Chaotisch
einfach schwierig
Klar Unklar
Anforderung
Lösung
Einfach
Komplex
Netterweise gibt das Cynefin-Umfeld mit dem Stacey-Diagramm eine einfache Orientierung. Es hat zwei Achsen, die das Problem zu Projektbeginn
beschreiben - die eine ist die Klarheit und das Verständnis des Problems, die andere die Klarheit und das Verständnis der Lösung. Bei einem normalen
Projekt sind beide zwar nicht 100% unklar, aber eben auch nicht 100% klar. Und weil sie sich aufeinander beziehen ändert die Anforderung die Lösung und
diese dann wieder die Anforderung. Also normales komplexes Verhalten.
97. „Pairprogramming ist langsam.“
„TDD ist Zeitverschwendung.“
„Refactoring ist Fehlerbehebung.“
„Scrum sind viele unnötige Meetings“
!
!
Einfache
Wahrnehmung
Wenn ich zum Beispiel einen Manager habe, der sich im einfachen Quadranten wähnt, dann möchte er ohne grosse Analyse zum richtigen kommen. Die
Praktiken der Entwickler irritieren ihn. Pairprogramming kann gar nicht schneller sein, egal was die Statistik sagt, und TDD ist Zeitverschwendung. Mit
Refactoring versucht man nur frühere Inkompetenz zu korrigieren, und Scrum meetet sich zu Tode.
98. Einfach
Erkennen
Beurteilen
Reagieren Best Practice
Standardprozesse
Handlungsanweisungen
Checklisten
Protokollierte Verfahren
Baukastensysteme
Developer sind frei beweglich
Er sieht erheblich lieber einfache best Practices, und möchte die verlässlich etabliert haben. Deshalb findet er Standardprozesse, erarbeitet
Handlungsanweisungen, Checklisten. Er protokolliert gerne Verfahren, damit sie später nur durch Abtippen wiederholt werden können. Er mag
Baukastensysteme und erwartet massive Zeiteinsparungen daraus. Entwickler können spontan Projekte wechseln und mehrere Projekte gleichzeitig
bearbeiten.
99. Einfach
dysfunktional
Autoritäres Management
Micromanagement
Mushroom Management
Cargo Cult
Golden Hammer Syndrome
Im Resultat führt er die Entwickler über Autoritäres Management, steuert auch gerne mal direkt. Er macht Mushroom-Management: die Developer werden
im Dunkeln gelassen und bekommen nur Mist vorgesetzt. Wenn agile Methoden kommen dann als Cargo-Cult: er liest über sie im Flugzeit und ordnet in
der nächste Woche an, dass ab jetzt Pair Programming / Kanban / Domain Driven Design gemacht wird. Er bevorzugt Lösungen die einfach für alles
taugen.
100. Agil ist unverlässlich.
Es fehlt ein detaillierter Plan.
Es fehlt klare Verantwortung.
Agil ist eine Wohlfühlveranstaltung.
!
!
Komplizierte
Wahrnehmung
Der komplizierte Manager rechnet nicht mit einfachen Lösungen, ganz im Gegenteil. Resultate sind das Produkt von Planung, Kompetenz und Disziplin.
Ohne diese kann es keine Resultate geben, also ist agil selbst unverlässlich, weil es die Methoden nicht bietet. Ohne Plan, ohne klar verteilte Hüte kann
das nicht funktionieren. Und die Meetings mit permanenter Ausleuchtung von allem sind nicht Zielorientiert und kümmern sich offensichtlich um
Befindlichkeiten, nicht um Fakten.
101. Kompliziert
Erkennen
Analysieren
Reagieren Good Practice
Lastenheft/Pflichtenheft
Klare Prozesse
Architekten & Gremien
Meilensteinplan & GANTT-Pläne
Verträge & Dokumentation
Klare Verantwortung
Ziele & Prämien
Weil er im komplizierten Zuhause ist nutzt er er gerne professionelle Verfahren, die eine gewisse logische Tiefe mitbringen. Eine detaillierte Analyse ist auf
allen Ebenen genauso wichtig wie eine detaillierte verlässliche Planung. Gut ausgebildete Leute entscheiden und haben die Verantwortung, und das Ziel
wird wie geplant erreicht - wenn nicht jemand auf dem Weg versagte.
102. Kompliziert
dysfunktional
Transaktionales Management (MbO)
Grosse, bekannte Prozesse
Death by Planning
Architects Don’t Code
Blamestorming
Fear of Success
Die Dysfunktionen sind dementsprechend auch weniger offensichtlich kaputt, sondern benötigen erhebliches Nachdenken. Transnationales Management -
also Zielvereinbarungen und Bonus - funktionieren nur in einer Ursache-Wirkung-Welt, und laufen in einer komplexen immer auf einen Kuhhandel zur
Bonusermittlung hinaus. Planung und Prozesse werden wie XML und Gewalt eingesetzt: wenn es nicht funktioniert hat mehr davon! Bei Ihnen übernehmen
Architekten, Gremien und Planer die Verantwortung, und die anderen haben sich danach zu richten, deshalb sollen die Architekten auch nicht
mitprogrammieren. Bei Fehlern muss jemand etwas falsch gemacht haben, aber irgendwie landet man nie bei einer klaren Verantwortung - nicht
verwunderlich, denn im komplexen gibt es keine klare Kopplung zwischen Ursache und Wirkung.
!
http://c2.com/cgi/wiki?DeathByPlanning
http://c2.com/cgi/wiki?FearOfSuccess
103. Schön und gut,
aber wie erkläre ich
ihm das jetzt?
? Jetzt weiß ich zwar warum mein Manager es nicht versteht, aber das hilft mir nichts - denn ich kann ihm das nicht erklären. Und wäre ich jetzt ein
Consultant würde ich sagen: „Kaufen sie mich ein, ich erkläre das dann.“ - aber ich bin keiner. Also Dinge, die in der Praxis tatsächlich funktioniert haben.
104. ! Oberhalb des Radars
Es gibt in der Praxis zwei Wege, einen oberhalb des Radars und einen unterhalb des Radars. Beide sind ein wenig gemogelt, aber man muss dem
Management ja auch Gelegenheit geben, mit den neuen Gegebenheiten zurechtzukommen. Und diese Zeit will nicht verschwendet sein.
105. Rettungs —
Projekte
Der Klassiker unter der Einführung agiler Methoden - Projekte, bei denen andere Methoden schon versagt haben. Warum eignen sie sich besser? Zunächst
einmal erwartet niemand, dass es von Anfang an alles gut ist. Zum anderen ist in solchen Projektphasen der Grad an Komplexität noch einmal deutlich
höher, deshalb bringen agile Methoden hier oft überraschend gute Ergebnisse.
106. Leuchtturm-
Projekte
Das ist die zweite Methode. Ich mache Leuchtturmprojekte. Das ist etwas weniger elegant als ein Rettungsprojekt, weil es sich meistens um kleine
Projekte mit überschaubarem Risiko und einer Flexibilitätsanforderung handelt.
107. 100% Managementsupport
Managementeinbeziehung
Die agilen Coaches empfehlen in solchen Fällen immer 100% Managementsupport, vermutlich weil die auch über ihr Budget entscheiden. Viel wichtiger
ist aber tatsächlich das geduldige Einbeziehen des Managements, damit die durch Teilnahme ein Gefühl dafür gewinnen, wie und warum agil funktioniert.
108. Optimal
• Agil initiert durch Development
• abgesprochen mit Management
• mit internem Coach
Optimal läuft es wenn es aus der Entwicklung kommt und dort getragen wird - wenn dort kein Support vorhanden ist brauche ich noch kein Projekt zu
machen. Es sollte mit dem Management abgesprochen sein, und wie schon genannt mit viel Kommunikation passieren. Und am besten ist es wenn ich
dem Management einen internen Coach zur Verfügung stelle, der sowohl die Unternehmenskultur als auch agile Hintergründe versteht.
109. ! Unterhalb des Radars
Und jetzt wieder zurück zur Realität: unterhalb des Radars.
110. U-Boot—
Projekte
Ich mache ein Projekt einfach intern agil, und emuliere nach aussen das offiziell gängige Projektverfahren. Ich kenne große Unternehmen, die agil im
Projekt arbeiten und nach aussen einen Meilensteinplan mit 218 Zielen kommunizieren. Und alle zwei Wochen ändern sich die Ziele, die in den
Meilensteinen enthalten sein werden.
Und was ist, wenn ich gar kein Projekt habe?
111. Ich habe durch Probieren gelernt,
dass B rauskommt
wenn ich A mache.
Emergente
Praktiken
Komplex
Dann probiere ich die Praktiken schlicht trotzdem aus.
112. Um so weiter weg
ein Manager
von agilen Praktiken ist,
um so mehr Platz
ist unter seinem Radar.
Glücklicherweise gilt oft die Faustregel, dass unter dem Radar von Managern die mit agil wenig am Hut haben - zumindest wenn sie nicht die
unmittelbaren Vorgesetzten sind oder nicht so gut in Micromanagement.
113. • Scrum Master Role
• Pair Programming
• Continuous Integration
• Retrospectives
• Test Driven Development
klein hoch
klein hoch
Benefit
Risiko / Kosten
• KanBan
Wir machen solche Dinge gerne über ein einfaches Kosten-Benefit-Diagramm: wir scoren die Methoden in Risiko und Benefit, und machen die mit hohem
Benefit und kleinem Risiko. Und wann komm ich wieder über den Radar?
114. Resultate
Sobald ich Resultate habe. Resultate funktionieren in allen Quadranten, das ist die eine Währung, die jeder Manager spricht.
115. Für gute Manager, die ein offenes Ohr, Hirn und Herz haben gibt es glücklicherweise auch einige Managementmethoden, die für komplexe
Aufgabenstellung taugen. Insbesondere erfreut sich Management 3.0 hier einiger Beliebtheit, das nicht nur ein Buch, sondern auch einige Werkzeuge und
vor allem Kurse anbietet. Das kann ich tatsächlich empfehlen. Generell würde jedes Management, das unter den Oberbegriff der Transformationen
Führung fällt helfen- nur leider gibt es davon noch nicht so viele einfach handhabbare Quellen. Radical Management geht ebenfalls in eine ähnliche
Richtung, hat aber nie wirklich in Europa abgehoben.
116. Danke!
For every complex problem there is an
answer that is clear, simple and wrong.
H.L. Mencken
By 2016, the Cynefin Framework will be used in
10% of IT operations organizations as a
sensemaking methodology.
Gartner Group 2012
Slides mit Volltext: http://slideshare.net/johannhartmann/
Gute Fragen: @johannhartmann
Andere Fragen: hartmann@mayflower.de
117. Links:
!
Cynefin allgemein:
http://cognitive-edge.com/blog/entry/5855/cynefin-papers-a-summary/
Cynefin für Entwickler:
http://lizkeogh.com/2012/03/11/cynefin-for-devs/
Kleine Teams vs grosse Teams
http://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-than-
large-teams/
Agile Methoden empirisch betrachtet:
http://www.amazon.com/Business-Value-Agile-Software-Methods/dp/1604270314
http://davidfrico.com/agile-book.htm
Five Orders of Ignorance
http://www-plan.cs.colorado.edu/diwan/3308-s10/p17-armour.pdf
The Waterfall Accident
http://pascal.gugenberger.net/thoughts/waterfall-accident.html
Productivity vs Overhours
http://lunar.lostgarden.com/Rules%20of%20Productivity.pptx