SlideShare ist ein Scribd-Unternehmen logo
1 von 117
Downloaden Sie, um offline zu lesen
Agile 
vs 
Management 
Hallo zusammen. Willkommen zum Talk Agile vs Management. Guten morgen. 
Ich hoffe, Sie sind alle gut angekommen.
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.
Nicht- 
Wissens-vermittlung 
Sondern um Nichtwissensvermittlung. Wir reden schliesslich über Management. Und das ist genau der Punkt.
Hier haben wir einen der Menschen, die Nichtwissen popularisiert haben.
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.
„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.
„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?
„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.“
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.
!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.
" 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.
"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.
? 
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?
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.
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.
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.
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.
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.
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.
! 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.
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.
! 
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.
"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.
"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.
? Wer arbeitet mit 
Storypoints? 
Wer schätzt seine Aufwände in Storypoints?
? 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?
!„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?
Ich wusste die 
Antworten 
auf diese Fragen 
vorher nicht. 
Ich wusste sie vorher nicht. Und nicht nur das.
Ich wusste 
vorher nicht, 
dass ich diese 
Fragen habe. 
Ich wusste sie vorher nicht. Und nicht nur das.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
Und wir? 
Wie sieht es 
bei uns ITlern aus? 
Orders of Ignorance 
Aber welche Form der Ignoranz ist bei uns denn massgeblich?
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.
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.
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!
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.
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.
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?
Das wollte auch diese Firma wissen.
Dave Snowden 
Und die hat diesen Menschen beauftragt, das herauszufinden. Er kommt aus Wales und forscht an der Komplexitätstheorie im Bereich Sensemaking.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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 :-)
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.
# 
$ 
% 
& 
' 
( 
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.
„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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
„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.
„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.
„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.
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.
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.
Verwirrung 
Methoden aus dem falschen Quadranten. 
Genau diese Verwirrung ist die Quelle der meisten Probleme von IT und Management.
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.
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.
„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.
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.
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.
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.
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.
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
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.
! 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.
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.
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.
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.
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.
! Unterhalb des Radars 
Und jetzt wieder zurück zur Realität: unterhalb des Radars.
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?
Ich habe durch Probieren gelernt, 
dass B rauskommt 
wenn ich A mache. 
Emergente 
Praktiken 
Komplex 
Dann probiere ich die Praktiken schlicht trotzdem aus.
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.
• 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?
Resultate 
Sobald ich Resultate habe. Resultate funktionieren in allen Quadranten, das ist die eine Währung, die jeder Manager spricht.
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.
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
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

Más contenido relacionado

Was ist angesagt?

Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtJohann-Peter Hartmann
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeJohann-Peter Hartmann
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenGerrit Beine
 
Legacy php - Sanieren oder Ablösen?
Legacy php  - Sanieren oder Ablösen?Legacy php  - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?Johann-Peter Hartmann
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesJohann-Peter Hartmann
 
RoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für ChinaRoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für ChinaJohann-Peter Hartmann
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...Mayflower GmbH
 
Arbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaArbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaElsy Zollikofer
 
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-LockdownDer 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-LockdownTechDivision GmbH
 
Whitepaper digitale Teamkultur
Whitepaper digitale TeamkulturWhitepaper digitale Teamkultur
Whitepaper digitale TeamkulturAnatoli Fichtner
 

Was ist angesagt? (19)

Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommt
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-Verträge
 
Agile Führung - echt jetzt?
Agile Führung - echt jetzt?Agile Führung - echt jetzt?
Agile Führung - echt jetzt?
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
 
Legacy php - Sanieren oder Ablösen?
Legacy php  - Sanieren oder Ablösen?Legacy php  - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektes
 
Erfolgreiche rewrites
Erfolgreiche rewritesErfolgreiche rewrites
Erfolgreiche rewrites
 
RoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für ChinaRoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für China
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
 
Wetware Bugs and Refactoring
Wetware Bugs and RefactoringWetware Bugs and Refactoring
Wetware Bugs and Refactoring
 
Arbeitswelt2020 pecha kucha
Arbeitswelt2020 pecha kuchaArbeitswelt2020 pecha kucha
Arbeitswelt2020 pecha kucha
 
Arbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaArbeitswelt2020PechaKucha
Arbeitswelt2020PechaKucha
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-LockdownDer 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
 
Produktive teams
Produktive teamsProduktive teams
Produktive teams
 
Whitepaper digitale Teamkultur
Whitepaper digitale TeamkulturWhitepaper digitale Teamkultur
Whitepaper digitale Teamkultur
 
2010 09 21 AdminCamp News Tuesday
2010 09 21 AdminCamp News Tuesday2010 09 21 AdminCamp News Tuesday
2010 09 21 AdminCamp News Tuesday
 

Andere mochten auch

How not to screw the operating system of your startup
How not to screw the operating system of your startupHow not to screw the operating system of your startup
How not to screw the operating system of your startupJohann-Peter Hartmann
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developersJohann-Peter Hartmann
 
Javascript Security
Javascript SecurityJavascript Security
Javascript Securityjgrahamc
 
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?Johann-Peter Hartmann
 

Andere mochten auch (7)

JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
How not to screw the operating system of your startup
How not to screw the operating system of your startupHow not to screw the operating system of your startup
How not to screw the operating system of your startup
 
DevOps jenseits der Tools
DevOps jenseits der ToolsDevOps jenseits der Tools
DevOps jenseits der Tools
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developers
 
Javascript Security
Javascript SecurityJavascript Security
Javascript Security
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
 
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
 

Ähnlich wie Agile versus Management WJAX 2014

Digitalisierung alles in Bewegung
Digitalisierung alles in BewegungDigitalisierung alles in Bewegung
Digitalisierung alles in BewegungBjörn Schotte
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftMayflower GmbH
 
Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)Roman Rackwitz
 
Beyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
Beyond Agile - Antifragilität in der Software-Entwicklung - mit NotizenBeyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
Beyond Agile - Antifragilität in der Software-Entwicklung - mit NotizenGerrit Beine
 
Diese iPad Apps wollen wir sehen (Hastenteufel&Sax@next10)
Diese iPad Apps wollen wir sehen (Hastenteufel&Sax@next10)Diese iPad Apps wollen wir sehen (Hastenteufel&Sax@next10)
Diese iPad Apps wollen wir sehen (Hastenteufel&Sax@next10)Rainer Sax
 
Der Wikipedia Irrtum: Wissensmanagement im Enterprise 2.0
Der Wikipedia Irrtum: Wissensmanagement im Enterprise 2.0Der Wikipedia Irrtum: Wissensmanagement im Enterprise 2.0
Der Wikipedia Irrtum: Wissensmanagement im Enterprise 2.0SoftwareSaxony
 
Coding Dojo .NET User Group Leipzig
Coding Dojo .NET User Group LeipzigCoding Dojo .NET User Group Leipzig
Coding Dojo .NET User Group LeipzigGregor Woiwode
 
7 Thesen zum Recruiting der Zukunft
7 Thesen zum Recruiting der Zukunft7 Thesen zum Recruiting der Zukunft
7 Thesen zum Recruiting der ZukunftHenrik Zaborowski
 
Software-Entwicklung Im Team
Software-Entwicklung Im TeamSoftware-Entwicklung Im Team
Software-Entwicklung Im TeamStephan Schmidt
 
Personal Branding im Web
Personal Branding im WebPersonal Branding im Web
Personal Branding im WebKarin Friedli
 
Wie man mehr Erfolg hat, indem man andere seine Arbeit tun lässt
Wie man mehr Erfolg hat, indem man andere seine Arbeit tun lässtWie man mehr Erfolg hat, indem man andere seine Arbeit tun lässt
Wie man mehr Erfolg hat, indem man andere seine Arbeit tun lässtJens Jacobsen
 
A-Recruiter Tage 2013: Workshop II "Konflikte" (Herr Wende)
A-Recruiter Tage 2013: Workshop II "Konflikte" (Herr Wende)A-Recruiter Tage 2013: Workshop II "Konflikte" (Herr Wende)
A-Recruiter Tage 2013: Workshop II "Konflikte" (Herr Wende)U-Form:e Testsysteme
 
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...eparo GmbH
 
Weiches Zeugs für harte Jungs und Mädels
Weiches Zeugs für harte Jungs und MädelsWeiches Zeugs für harte Jungs und Mädels
Weiches Zeugs für harte Jungs und MädelsNETUserGroupBern
 
Programmieren lernen Grundkurs - Tag1: 1. Einführung
Programmieren lernen Grundkurs - Tag1: 1. EinführungProgrammieren lernen Grundkurs - Tag1: 1. Einführung
Programmieren lernen Grundkurs - Tag1: 1. EinführungJan Brinkmann
 

Ähnlich wie Agile versus Management WJAX 2014 (18)

Digitalisierung alles in Bewegung
Digitalisierung alles in BewegungDigitalisierung alles in Bewegung
Digitalisierung alles in Bewegung
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)
 
Beyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
Beyond Agile - Antifragilität in der Software-Entwicklung - mit NotizenBeyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
Beyond Agile - Antifragilität in der Software-Entwicklung - mit Notizen
 
Planlos mit Plan
Planlos mit PlanPlanlos mit Plan
Planlos mit Plan
 
Diese iPad Apps wollen wir sehen (Hastenteufel&Sax@next10)
Diese iPad Apps wollen wir sehen (Hastenteufel&Sax@next10)Diese iPad Apps wollen wir sehen (Hastenteufel&Sax@next10)
Diese iPad Apps wollen wir sehen (Hastenteufel&Sax@next10)
 
Der Wikipedia Irrtum: Wissensmanagement im Enterprise 2.0
Der Wikipedia Irrtum: Wissensmanagement im Enterprise 2.0Der Wikipedia Irrtum: Wissensmanagement im Enterprise 2.0
Der Wikipedia Irrtum: Wissensmanagement im Enterprise 2.0
 
Coding Dojo .NET User Group Leipzig
Coding Dojo .NET User Group LeipzigCoding Dojo .NET User Group Leipzig
Coding Dojo .NET User Group Leipzig
 
7 Thesen zum Recruiting der Zukunft
7 Thesen zum Recruiting der Zukunft7 Thesen zum Recruiting der Zukunft
7 Thesen zum Recruiting der Zukunft
 
Software-Entwicklung Im Team
Software-Entwicklung Im TeamSoftware-Entwicklung Im Team
Software-Entwicklung Im Team
 
Personal Branding im Web
Personal Branding im WebPersonal Branding im Web
Personal Branding im Web
 
Wie man mehr Erfolg hat, indem man andere seine Arbeit tun lässt
Wie man mehr Erfolg hat, indem man andere seine Arbeit tun lässtWie man mehr Erfolg hat, indem man andere seine Arbeit tun lässt
Wie man mehr Erfolg hat, indem man andere seine Arbeit tun lässt
 
Interview zu IDEENKICK mit THINKVENTION
Interview zu IDEENKICK mit THINKVENTIONInterview zu IDEENKICK mit THINKVENTION
Interview zu IDEENKICK mit THINKVENTION
 
A-Recruiter Tage 2013: Workshop II "Konflikte" (Herr Wende)
A-Recruiter Tage 2013: Workshop II "Konflikte" (Herr Wende)A-Recruiter Tage 2013: Workshop II "Konflikte" (Herr Wende)
A-Recruiter Tage 2013: Workshop II "Konflikte" (Herr Wende)
 
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
 
Weiches Zeugs für harte Jungs und Mädels
Weiches Zeugs für harte Jungs und MädelsWeiches Zeugs für harte Jungs und Mädels
Weiches Zeugs für harte Jungs und Mädels
 
Programmieren lernen Grundkurs - Tag1: 1. Einführung
Programmieren lernen Grundkurs - Tag1: 1. EinführungProgrammieren lernen Grundkurs - Tag1: 1. Einführung
Programmieren lernen Grundkurs - Tag1: 1. Einführung
 

Mehr von Johann-Peter Hartmann

Mehr von Johann-Peter Hartmann (6)

The End of my Career
The End of my CareerThe End of my Career
The End of my Career
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
 
Serverside Cryptoparty
Serverside CryptopartyServerside Cryptoparty
Serverside Cryptoparty
 
JavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 BerlinJavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 Berlin
 
Profiling for Grown-Ups
Profiling for Grown-UpsProfiling for Grown-Ups
Profiling for Grown-Ups
 
Paradigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationenParadigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationen
 

Agile versus Management WJAX 2014

  • 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.
  • 3. Nicht- Wissens-vermittlung Sondern um Nichtwissensvermittlung. Wir reden schliesslich über Management. Und das ist genau der Punkt.
  • 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?
  • 49. Das wollte auch diese Firma wissen.
  • 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