SlideShare ist ein Scribd-Unternehmen logo
Management
Brainfucks
Willkommen zum Talk zu Management Brainfucks.
Management
Brainfucks
Eigentlich wollte ich ja nur einen Talk mit Fuck im Titel auf einer Konferenz halten.
Aber in Wahrheit geht es mir gar nicht darum.
Management
Brainfucks
Eigentlich wollte ich ja nur einen Talk mit Fuck im Titel auf einer Konferenz halten.
Aber in Wahrheit geht es mir gar nicht darum.
Wissens-
vermittlung
Es geht ebenfalls nicht um Wissensvermittlung
Wissens-
vermittlung
Es geht ebenfalls nicht um Wissensvermittlung
Nicht-
Wissens-
vermittlung
Sondern um Nichtwissensvermittlung. Wir reden schliesslich über Management. Und das ist
genau der Punkt.
Hier haben wir einen international anerkannten Experten in Nichtwissen.
Donald
Rumsfeld
Genau, das ist Donald Rumsfeld, seines Zeichens ehemaliger Verteidigungsminister der USA,
ausserdem Erfinder von Bio- Atom- Chemiewaffen und vermutlich auch Alientechnologie im
Irak, und einer der profiliersten Nichtwisser der Welt. Er war in der Lage, mit Nichtwissen
sogar Kriege zu beginnen.
Donald
Rumsfeld
We do know of
certain knowledge
that Osama Bin
Laden is either in
Afghanistan, or in
some other
country, or dead.
Der hat solche Dinge gesagt. Eigentlich sagt er damit: wir haben keine ahnung bis auf die
tatsache, dass er auf diesem Planeten ist. Ausser wenn er tot ist, dann kann es auch sein,
dass er bei den aliens ist.
Donald
Rumsfeld
But there are also
unknown
unknowns – there
are things
we do not know
we don't know.
Hier hat er versucht Nichtwissen zu systematisieren, mit den unknown unknows.
Jetzt kann man sagen - das ist ja sein Problem, nicht unseres.
Aber ist das wirklich so?
„Wielange
würde ein
kompletterRewrite
mit node.js dauern?“
Das ist so ein Klassiker. Heute fragt jeder „Wie lange würde ein Komplett-Rewrite auf Basis
von Symfony2, Zend Framework 2 oder, für die mutigen, node.js, dauern?“.
Selbst wenn alle Features
bekannt sind haben wir
keine präzise Schätzung.
WTF?!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.
Wir können noch nicht
mal gut erklären, warum
wir das nicht wissen.
Und es wird noch schlimmer - wir können noch nicht mal erklären, warum wir so dermassen
daneben liegen.
Selbst wenn wir es
empirisch wieder und wieder
bewiesen haben.

Und wir können es nicht erklären, obwohl wir die schlechte Qualität unserer Schätzungen
wieder und wieder unter Beweis gestellt haben. Selbst empirischem Wissen wird nicht
geglaubt.
?Pair Programming
Zwei Programmierer
werden effizienter wenn
nur einer arbeitet und
der andere zuguckt
Das gilt genauso für die durchaus positiven Dinge, die Thema dieses Vortrags sind.
Pair Programming: Ich setzte zwei Developer an die gleiche Aufgabe, und am Ende sind sie
effizienter. Und zwar mit dem an dieser Aufgabe Beteiligtem Code und so, nicht etwa durch
Wissenstransfer oder Juniors einlernen.
27 %
more productive
!Eine akademische Case-Study von Jensen aus 2003 hat einen Produktivitätsvorsprung von
127% durch Pair Programming nachgewiesen. Das waren natürlich echte Projekte, und man
kann ihnen vorwerfen, nicht unter Laborbedingungen passiert zu sein.
!101%
more productive
Unter Laborbedingungen sieht es sogar noch besser aus: In einem Experiment von 2006, von
Xu und Rajlich, wurde sogar eine Produktivitätssteigerung von 201 Prozent gegenüber
einzelner Programmierung nachgewiesen.
?Overhours
Ein Programmierer leistet
mehr in 8 Stunden
als in 14 Stunden?
Ein ähnliches Beispiel sind Overhours. Wenn jemand 8 Stunden arbeitet, und dann noch mal 6
hinterher, dann sollte das zumindest grob in Richtung des anderthalbfachen an
Arbeitsleistung gehen, oder?
!Productivity
6h
> 8h
> 14h
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.
Team Size
?Wenn ich ein Team
deutlich größer
mache wird es nicht
deutlich produktiver?
Es gibt in Brooks Law auch eine Ausprägung davon: Adding people to a late project makes it
later.Diesen Fehler machen wir sogar bei Mayflower 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.
?less knowledge
Wenn ich den besten
Senior aus dem Team
entferne wird das Team
effizienter?
Aber die einfache Addition geht nicht nur in den Fällen von Arbeitszeit oder Leuten nicht auf.
Auch bei Knowhow im Team gilt die Regel nicht.
!more productive
40%der Velocity
durch den Senior
Gesamtvelocity
um 20%gesteigert
Das ist sogar eine Geschichte die uns selbst passiert ist - ein wirklich, wirklich guter Mann,
Teamplayer, freundlich und cooler Kollege macht den größten Teil der Arbeit in jedem Sprint,
bringt brillante Ideen ein. Doch als er aus dem Team verschwindet steigert sich die
Performance des Gesamtteams.
?many more
Low Prio First
Dumb Developer First
Das sind noch längst nicht alle Brainfucks, die Software bereithält. Wenn man in jeden Sprint
Low-Prio-Tasks mit einbezieht wird die Gesamtperformance besser. Und ein Team ist
effizienter, wenn man die Tasks als erstes dem Kollegen mit der kleinsten Erfahrung assigned
und der erfahrenste Kollegen nur noch die Tasks bekommt, die am Ende übrig bleiben. Wer
Rückfragen dazu hat kann sich bei mir melden.
!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
empirisch wieder und wieder
bewiesen 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.
Ich weiß das,
ich bin einer von ihnen.

Und ich muss das wissen, denn ich bin selbst einer. Wer kennt mich noch nicht? Ich bin auf
vielen IPCs, deshalb frage ich :-).
?Wer arbeitet mit
Storypoints?
Wer von den Anwesenden schätzt gerne Aufwände?
?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 wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische
Beispiele sind ...
Was haben alle diese Punkte gemeinsam?
„Mein Debugger funktioniert bei
den Unit-Tests nicht.“
Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische
Beispiele sind ...
Was haben alle diese Punkte gemeinsam?
„Mein Debugger funktioniert bei
den Unit-Tests nicht.“
„Vagrant startet die virtuelle
Maschine nicht mehr.“
Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische
Beispiele sind ...
Was haben alle diese Punkte gemeinsam?
„Mein Debugger funktioniert bei
den Unit-Tests nicht.“
„Vagrant startet die virtuelle
Maschine nicht mehr.“
„Der Bug ist erst in der neuen
Library gefixed, und 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 Antwort
vorher nicht.
Ich wusste sie vorher nicht. Und nicht nur das.
Ich wusste vorher noch nicht,
dass ich eine Antwort brauche.
Und noch schlimmer: Ich wusste vorher auch noch nicht, dass ich sie nicht wusste.
Also die Unknown Unknowns, von denen Donald Rumsfeld sprach.
Ich wusste vorher noch nicht,
dass ich eine Antwort brauche.
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.
Orders of Ignorance
Ignoranz 0ter Ordnung:
Ich weiss etwas.
Das klingt zwar jetzt schwachsinning, macht aber durchaus Sinn. Wenn ich etwas sicher
weiss, bin ich kein Stück ignorant. Diesbezüglich.
Orders of Ignorance
Ignoranz 1ter Ordnung:
Ich weiss etwas
bestimmtes nicht.
Wenn ich etwas nicht weiss, geht das auch ok. Wenn in meiner Anforderung steht
„Backgroundcolor bitte aus dem Styleguide.“, dann weiss ich zwar die Farbe nicht, ich kann
aber nachgucken, nachfragen oder ähnliches.
Orders of Ignorance
Ignoranz 2ter Ordnung:
Ich weiss nicht,
was ich nicht weiss.
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. Klassiker sind
natürlich Bugs, aber auch inkompatible Libraries, Webservices oder sonstige Schnittstellen.
Aber ich weiss was ich machen kann, um es herauszufinden - im agilen meist einfach
machen, die fragen kommen schon von alleine.
Orders of Ignorance
Ignoranz 3ter Ordnung:
Ich weiss nicht wie ich
herausfinde, was ich
nicht weiss.
Und was ist, wenn wir es nicht ausprobieren können? Das sind natürlich zum einen schlecht
probierbare Dinge wie die Bugs im Notfallprogramm unseres Kernkraftwerkes unter realen
Bedingungen, aber auch einfache Dinge wie zukünftige Nutzerwünsche vor Launch.
Orders of Ignorance
Ignoranz 4ter Ordnung:
Ich weiss nicht, dass es
unterschiedliche Arten von
Nichtwissen gibt.
Das wird die anwesenden Informatiker freuen - es gibt auch Meta-Ignoranz, wenn ich nicht
weiss, dass es unterschiedlichen Arten von Nichtwissen gibt.
Orders of Ignorance
Ignoranz 4ter Ordnung:
Es gibt nur 1te Ordnung:
Ich weiss etwas
bestimmtes nicht.
Und genau da liegt eines der Management-Probleme: es gibt nur Nichtwissen erster
Ordnung. Ich muss vorher alle richtigen Fragen stellen, dann weiss ich alles und kann nach
Plan vorgehen.
CHAOS REPORT 2011
WASSERFALL
29%
57%
14%
Successful
Challenged
Failed
Quelle: Standish Group Chaos Report 2011
Mit wieviel Nichtwissen wir es zu tun haben habe ich schon am Detailbeispielen gezeigt, aber
das gilt natürlich auch für das Gesamtbild. Wenn wir schon alles wüssten, brauchten wir nur
nach Plan zu arbeiten. Fakt ist aber, dass am Ende das Nichtwissen über den ganzen
Projekterfolg entscheidet.
CHAOS REPORT 2011
AGILE
9%
49%
42%
Successful
Challenged
Failed
Quelle: Standish Group Chaos Report 2011
Ich hatte ja schon erwähnt, dass agil besser mit nichtwissen umgeht, und deshalb etwas
besser darsteht. Nichtsdestotrotz kommen wir auch hier nicht über 42% erfolgreiche Projekte.
Scope Creep
Dark Matter
50%
Wir geben unserem Nichtwissen sogar Namen!
Wie geht man mit
solchen Welten um?
Genau das wollte auch IBM wissen, und deshalb haben sie 1999 Dave E.Snowden beauftragt.
Und zwar konkret:
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
Chaotisch Einfach
Verwirrung
Und so sieht das aus.
Und mit diesen Quadranten kam herr snowden am ende heraus
Er sagt: Manager nehmen ihre Arbeitswelt als komplex, kompliziert, chaotisch oder einfach
wahr. Und je nach Wahrnehmung agieren sie anders.
Einfach
Der Zusammenhang zwischen
Ursache und Wirkung ist bekannt,
vorhersagbar und wiederholbar.
Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine
Überraschungen zu erwarten.
Einfach
Beispiele:
Email schreiben
Browser bedienen
Es ist keine Rückfrage notwendig
Im Software Development gibt es kaum Beispiele für solche Tätigkeiten, selbst ein CRUD oder
ein zusätzliches Formular braucht Rückfragen.
Einfach
Erkennen
Kategorisieren
Reagieren
Best Practice
Weil man auf bekanntem Gelände ist kommt man gut und planbar voran. Das sind genau die
Tasks, die wir gut schätzen können, ohne erst groß spezifizieren und planen zu müssen.
Kompliziert
Ursache und Wirkung sind über
Zeit und Raum getrennt, aber
nachvollziehbar und
wiederholbar.
Wenn ich im komplizierten Quadranten bin ist es nicht mehr trivial, aber machbar. Es ist
besser, wenn ich eine Ausbildung und/oder Erfahrung mitbringe. Wird auch Knowable
genannt, man kann es also sicher wissen, wenn man will.
Beispiele:
CRUD
Layout anpassen
Es kann immer wie geplant umgesetzt
werden.
KompliziertBei uns in der IT gibt es leider nur wenige Beispiele für solche Sachen, vielleicht der 10te
CRUD im gleichen System.
Erkennen
Analysieren
Reagieren
Kompliziert
Good Practice
Im Gegensatz zu simple komme ich nicht einfach über blosses draufschauen zum Ziel. Ich
muss tatsächlich die notwendigen Informationen einholen,
Chaotisch
Der Zusammenhang zwischen
Ursache und Wirkung ist nicht
erkennbar.
Da wirds gemein. Es gibt keinen erkennbaren Zusammenhang zwischen Ursache und Wirkung.
Beispiele:
Heisenbugs
Hackereinbruch
„Hoffentlich bringt das jetzt was.“
ChaotischIn der Praxis gibt es auch regelmässig solche Situationen.
Handeln
Erkennen
Reagieren
Chaotisch
Novel Practice
Wie gehe ich vor - ich probiere etwas aus und gucke, ob das klappt. Kennt Ihr Shotgun
Debugging? Ich tweake an diversen Stellen im Code und gucke, ob sich was ändert. Wer hat
das schon mal gemacht?
Komplex
Im Nachhinein ist ein
Zusammenhang zwischen
Ursache und Wirkung erkennbar.
Es ist nicht vorhersagbar, aber eine
Wiederholung kann passieren.
Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine
Überraschungen zu erwarten.
Beispiele:
Schachspiel
Innovative Software
Komplexe Software
Ich weiß noch nicht, was am Ende
genau herauskommen wird.
KomplexKomplexe Tätigkeiten sind unser tägliches Brot.
Probieren
Erkennen
Reagieren
Komplex
... Practice
In einem komplexen System probiere ich etwas aus, erkenne die Wirkung und reagiere
darauf. Aber ich habe einen vorteil gegenüber der chaotischen Welt, und es haben sich
bestimmte Praktiken bewährt. Welche erkläre ich gleiche.
Komplexe
Systeme
Wir haben es meistens mit komplexen systemen zu tun. Viel second order ignorance
bedeutet, dass nicht alles im Vorfeld knowable ist. Wasserfall ist ein modell, das in der
komplizierten Welt mit first order ignorance funktionieren würde, aber in einer Welt mit
second order ignorance scheitern muss. Simple ist es manchmal, und das ist auch super so.
chaotisch ist es auch manchmal, und das ist nicht so super so. meistens ist es bei uns
komplex.
Komplexe Systeme bedeutet, dass ich verschiedene Komponenten habe, die autark agieren.
Diese Komponenten können selbst simpel sein, oder komplex. Oder Chaotisch. Aber ich kann
aus den Einzelnen Komponenten nicht ableiten, wie sich das Gesamtsystem verhält.
Das liegt daran, dass die Elemente interagieren. Es gibt viele Interaktionen zwischen den
Teilen des Systems, und sie reagieren aufeinander. Kleine Änderungen können grossen
Wirkungen haben (Schmetterlingseffekt). Ich kann nicht im Vorhinein wissen, wie alle Teile
sich gemeinsam auf Zeit verhalten werden.
Beispiele?
Kennt jemand Beispiele für solche Systeme in seiner Arbeitswelt?
Team
Scrummaster
Product Owner
Senior Dev
Junior Dev
QA
User Experience






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.
Erst 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.
„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. Für welche Art von
Systemen gilt dieser Satz?
?Aber was kann ich dann machen? Wie kann ich in so einer Branche überhaupt was sinnvolles
tun, wenn ich mich auf nichts verlassen kann?
Emergente
Praktiken
Probieren
Erkennen
Reagieren
Das hatte uns Cynefin ja schon gesagt. Ich probiere, ich erkenne, und ich reagiere darauf.
Und es gibt ein paar Dinge die ich probiere, bei denen im Erkennen immer herauskommt „Das
funktioniert.“
Wenn etwas in 75% der Fälle
geholfen hat, werde ich es auch
weiterhin probieren.
Und wenn eine der probierten Sachen in 80% der Fälle funktioniert, dann wende ich sie in
Zukunft auch an.
Pair Programming
Test Driven Development
Sustainable Pace
Collective Code Ownership
Story Points ...
Emergente
PraktikenUnd 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.
Sie funktionieren
nicht immer, aber oft.
Emergente
PraktikenEmergente Praktiken sind Verhaltensmuster des komplexen Systems, nicht der
Einzelelemente. Ich kann sie nicht erzwingen. Sie gelten nicht immer. Aber oft. Es kann sein,
dass sie aufhören, in meinem System zu funktionieren.
Das ist der Grund, warum die agilen Methoden empirisch so schön nachweisbar sind,
wissenschaftlich aber nicht. Weil sie in einem komplexen System passieren.
Die Heuristik funktioniert,
nicht das einzelne Element.
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
trotzde mehr Aufschluß über Team-Performance und Releaseplanung als Alternativen.
Komplex Kompliziert
Chaotisch Einfach
Verwirrung
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 defaulted, in dem man sich am
sichersten fühlt.
Komplex Kompliziert
Chaotisch Einfach
Verwirrung
Probieren
Erkennen
Reagieren
Erkennen
Analysieren
Reagieren
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 defaulted, in dem man sich am
sichersten fühlt.
Default to Comfort Zone != Komplex
Management
Brainfucks
Und genau da kommen die Management Brainfucks her. Wenn ein Manager sich nicht bewusst
ist, dass er in einer komplexen Welt arbeitet, und deshalb auf seine Komfortzone
zurückgreift.
Verwirrung
Kompliziert
Erkennen
Analysieren
Reagieren
Wasserfall
Detailliertes Pflichtenheft
Micromanagement
Meilensteinplan
Agil zum Reporting
feste Ziele
Good Practice
Wenn er denkt er wäre in einer komplizierten Welt, und man könnte alles im vorhinein wissen
oder Fragen, dann möchte er Planen, Messen, Kontrollieren und Steuern. Und man sieht dort
Dinge wie wasserfalliges Vorgehen, die Fragen nach Pflichtenheften als Dokumentation des
vollständigen benötigten Wissens etc.
Verwirrung
Standardverfahren
Standardprozesse
Handlungsanweisungen
Dokumentation
Fixer Baukasten
Einfach
Erkennen
Beurteilen
Reagieren
Best Practice
Wenn er denkt er wäre in einer einfachen Welt, dann fordert er die Regeln der Welt an. Man
erkennt es: Standardverfahren/prozeduren, Handlungsanweisungen, Dokumentation, fixe
Baukästen, generatoren und module als Lösungen für _alles_.
Baukästen sind gut für die simplen Teile, aber nicht für komplexe Systeme.
Default to Comfort Zone
Pair Programming
„Wir haben nicht die Ressourcen zum Pair
Programming.“
Emergente
Praktiken
Probieren
Erkennen
Reagieren
Noch mal zur Erinnerung: wenn ich weiss, dass ich in der komplexen Zone bin, versuche ich
kontinuierlich zu probieren, kontinuierlich zu erkennen und kontinuierliche zu reagieren. und
am Ende habe ich ein Set von emergenten Praktiken, die mir häufiger Erfolg gebracht haben
als andere. Aber was heisst das konkret?
Komplex
Pair Programming
Ok, wir probieren das einfach mal
aus und beobachten es.
Wenn der Manager weiss, dass er in der komplexen Welt unterwegs ist würde er es probieren
wollen - aber nicht einmal, sondern mehrfach, und jeweils beobachten ob man im nachhinein
einen Zusammenhang zwischen Pair Programming und Funktionalität erkennen kann.
Würde man es offiziell einführen, wenn es funktioniert?
Komplex
Wenn es funktioniert wird es nur
nicht abgeschafft.
Das braucht keine Entscheidung.
Nein - emergent heisst ja genau, dass sich die Praktiken durchsetzen, die Funktionieren. Und
sie werden nicht offiziell eingeführt, sondern man wiederholt einfach nur die Probieren-
Schritt.
Kompliziert
Pair Programming
Eine Gruppe arbeitet mit Pair-
Programming und eine ohne, und
am Ende gucken wir, wer mehr Zeit
pro Storypoint verbraucht hat.
Wenn der Manager sich in einer komplizierten Welt sieht dann will er es messen. Vielleicht
würde er mir sogar die Empirie glauben. Wenn es nicht funktioniert würde er aber wissen
wollen, warum wir von den empirischen Daten abweichen.
Kompliziert
Pair Programming
Ursache und Wirkung sind klar
erkennbar. Ich mache es einfach
wieder so.
Er glaubt, dass Ursache und Wirkung nachvollziehbar aneinanderhängen und man ein
positives Ergebnis verlässlich reproduzieren kann.
Einfach
Pair Programming
Wir müssen die Features damit
umgesetzt bekommen, da können
wir nicht die Zeit damit
verschwenden.
Für den Manager in einer einfachen Welt ist es - Überraschung - einfach. Er rechnet kurz die
verfügbaren Stunden pro Feature durch und stellt fest, dass man den Sprint nur zu Ende
bekommt wenn man nicht im Pair arbeitet. Es ist eine Zeitfrage, und Developmentzeit und
Produktivität verhalten sich linear.
Einfach
Pair Programming
Produktivität wird unmittelbar
durch Entwicklerstunden
verursacht.
Er glaubt, dass Ursache und Wirkung nachvollziehbar aneinanderhängen und man ein
positives Ergebnis verlässlich reproduzieren kann.
Kann er damit Erfolg haben?
!101%
more productive
Und ich erinnere an vorhin - Pair Programming ist empirisch sehr erfolgreich. Trotzdem
möchte man dem nicht glauben, wenn es der eigenen Weltsicht nicht entspricht. Und wird
empirisch nicht sehr erfolgreich sein.
Wie erkläre ich es
also meinem
Manager?
Emergent Practice
Gar nicht!
Gar nicht. Es sind emergente Praktiken. Der Zusammenhang ist im Nachhinein feststellbar,
nicht vorher.
JUST DO IT.
Gar nicht. Es sind emergente Praktiken. Der Zusammenhang ist im Nachhinein feststellbar,
nicht vorher.
JUST DO IT.
Probieren
Erkennen
Reagieren
Gar nicht. Es sind emergente Praktiken. Der Zusammenhang ist im Nachhinein feststellbar,
nicht vorher.
Safe Projects
Probieren
Erkennen
Reagieren
Zum Beispiel über Safe Projects, bei denen wenig Risiko im spiel ist.
Slackdays
Coding Dojos
Probieren
Erkennen
Reagieren
Ich probiere die Methoden an Slackdays aus.
Opportunities:
Bugfixing beim Launch
Probieren
Erkennen
Reagieren
Oder ich nutze eine Ausnahmesituation. Ich kenne eine Firma, die hat beim Hardcore-
bugfixing bei einem Launch mit Pair Programming angefangen, und es funktioniert bis heute.
Heimlich ausprobieren.
Probieren
Erkennen
Reagieren
Oder einfach auch nur heimlich ausprobieren.
Überreden.
Probieren
Erkennen
Reagieren
Oder ich nutze Statistiken wie in diesem Vortrag um meinen Chef zu überreden.
Das ist aber ein Fake, weil er dann unter Umständen immer noch denkt, er könne sich darauf
verlassen. kann er aber nicht.
Überreden.
Probieren
Erkennen
Reagieren
Fake!
Oder ich nutze Statistiken wie in diesem Vortrag um meinen Chef zu überreden.
Das ist aber ein Fake, weil er dann unter Umständen immer noch denkt, er könne sich darauf
verlassen. kann er aber nicht.
Probieren
Erkennen
Reagieren
Komplex
Retrospektiven
Probieren
Erkennen
Reagieren
Wenn man Scrum macht gibt es eine explizite Infrastruktur für Erkennen und Reagieren. Die
Retrospektive.
Am Ende des
Coding Dojos
Probieren
Erkennen
Reagieren
Wenn man kein Scrum macht am Ende des Coding Dojos eine Kurzretro, ob es was hilft.
Auch alte Praktiken
bewerten und
Alternativen diskutieren.
Probieren
Erkennen
Reagieren
Wichtig dabei ist, dass man nicht nur das neue Benchmarked, sondern auch bei alten
Methoden über Änderungen und Experimente nachdenke.
Probieren
Erkennen
Reagieren
Komplex
JUST DO IT.
Also im Fazit: es einfach machen. Wenn es funktioniert, wird es niemand abschaffen. Wenn es
nicht funktioniert, willst Du es ohnehin selbst abschaffen.
Danke!
http://slideshare.net/johannhartmann
https://joind.in/8752

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
Addon-Slides
Zusammenhänge, die
wir herstellen konnten.
Und wenn es noch mehr Argumente braucht: ich kann es zwar nicht garantieren dass es bei
euch funktioniert, aber ich kann erzählen, welchen Zusammenhang wir festgestellt haben.






Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
TCO: 75% Maintenace
Web Frontend
Am meisten Zeit verbringt man mit der Software nach der initialen Fertigstellung, man geht
von ca 3/4 der Aufwände aus, die nach dem Release passieren. Maintenance gibt es weil es
unknown unknowns gibt. Features die der Kunde erst kennt wenn er die Software sieht und
nachdenkt. Und weil nachträgliche Änderungen langsamer sind als initiale Entwicklung, und
weil lesen von software langsamer ist als schreiben von software. Wichtig ist also das wissen
über die Zusammenhänge und Effekte innerhalb der Software.
Collective
Code
Knowledge
Es ist gut, wenn jeder möglichst viele Teile vom System versteht, um ein paar der Effekte
seiner Handlung einschätzen zu können. Dazu brauche ich verteiltes Wissen, dass mir
erheblich mehr Benefit gibt als Spezialisierung.






Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
PP
Web Frontend
Wenn man Pair Programming macht kann man besser überschauen, welche Änderung in den
Business Objects welche Auswirkungen im Rest des Systems hat, und was daraus folgt. Das
liegt zum einen daran, dass der Navigator sich darum kümmern kann, während der Driver auf
den Code Fokussiert ist.






Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
TDD
Web Frontend
Bei Test Driven Development macht man das Netz der Abhängigkeiten explizit, indem man
sie als Test oder als MockUp manifestiert. Generell programmiert man mit TDD mit weniger
Seiteneffekten.






Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
Collective Code Ownership
Web Frontend
Ähnlich wirkt auch Collective Code Ownership - weil jeder jeden Code anfasst lernt er immer
mehr über die Effekte im Netz. Und weil er die Seiteneffekte kennt






Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
Low Prio First
Web Frontend
Das gleiche gilt für Low-Prio-Tickets, die einen grossen Netzwerkeffekt haben - sie verzinsen
sich durch andere Tickets, und deshalb lohnt es sich, sie vorzuziehen.
Team > Indivuum
Scrummaster
Product Owner
Senior Dev
Junior Dev
QA
User Experience
Das ist auch der Grund, warum das Team mehr zählt als das Individuum. Vernetzte Effekte
lassen sich am besten über mehrere Leute klären als individuell. Wenn das Team keine
Verantwortung übernimmt weil der Senior sie aktiv wahrnimmt und kompetent ist, dann ist
die Produktivität schlechter als wenn alle Ihr Wissen über das Netz einbringen. Individuen
sind nicht gut in Komplexität.
Probieren und Emergenz erzeugen
Optimieren für Netze -> TEAM
Priorisieren und Verteilen für
Komplexität

Weitere ähnliche Inhalte

Was ist angesagt?

Five Key Numbers to Gauge your Agile Engineering Efforts
Five Key Numbers to Gauge your Agile Engineering EffortsFive Key Numbers to Gauge your Agile Engineering Efforts
Five Key Numbers to Gauge your Agile Engineering Efforts
Jeff Nielsen
 
Building Great Presentations
Building Great PresentationsBuilding Great Presentations
Building Great Presentations
Mattan Griffel
 
The Asana Culture Code
The Asana Culture CodeThe Asana Culture Code
The Asana Culture Code
Asana
 
合意形成の技術(ファシリテーション・ワークショップ)公開スライド:後半
合意形成の技術(ファシリテーション・ワークショップ)公開スライド:後半合意形成の技術(ファシリテーション・ワークショップ)公開スライド:後半
合意形成の技術(ファシリテーション・ワークショップ)公開スライド:後半
Management_CoLtd
 
#OpenSeriousGame L'art du feedback utile
#OpenSeriousGame L'art du feedback utile#OpenSeriousGame L'art du feedback utile
#OpenSeriousGame L'art du feedback utile
Alexandre Quach
 
Sociocratie et Lean Change Method - Etienne Laverdière
Sociocratie et Lean Change Method - Etienne LaverdièreSociocratie et Lean Change Method - Etienne Laverdière
Sociocratie et Lean Change Method - Etienne Laverdière
Agile Montréal
 
デザイン思考の基礎
デザイン思考の基礎デザイン思考の基礎
How to have difficult conversations
How to have difficult conversations How to have difficult conversations
How to have difficult conversations
Rajiv Jayarajah, MAppComm, ACC
 
¿Qué son los OKR´S?
¿Qué son los OKR´S?¿Qué son los OKR´S?
¿Qué son los OKR´S?
ArkAngeles.com
 
Handy culture deck v2.0
Handy culture deck v2.0 Handy culture deck v2.0
Handy culture deck v2.0
Handy
 
RedMartian Culture Code
RedMartian Culture CodeRedMartian Culture Code
RedMartian Culture Code
Roger Egan III
 
How things still don’t quite work at Spotify... and how we’re trying to solve it
How things still don’t quite work at Spotify... and how we’re trying to solve itHow things still don’t quite work at Spotify... and how we’re trying to solve it
How things still don’t quite work at Spotify... and how we’re trying to solve it
Jason Yip
 
[Trung Hoang] Shu-Ha-Ri applied to Agile team
[Trung Hoang] Shu-Ha-Ri applied to Agile team[Trung Hoang] Shu-Ha-Ri applied to Agile team
[Trung Hoang] Shu-Ha-Ri applied to Agile team
Trung Hoang Nhac
 
Slideshareで見つけた「読みやすい・見やすいスライド」に共通する4つのポイント
Slideshareで見つけた「読みやすい・見やすいスライド」に共通する4つのポイントSlideshareで見つけた「読みやすい・見やすいスライド」に共通する4つのポイント
Slideshareで見つけた「読みやすい・見やすいスライド」に共通する4つのポイント
Taichi Hirano
 
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
Yoshitaka Kawashima
 
17 Things Powerful People Say
17 Things Powerful People Say17 Things Powerful People Say
17 Things Powerful People Say
GetSmarter
 
Applying ResearchOps and DesignOps in globally distributed teams @ the Global...
Applying ResearchOps and DesignOps in globally distributed teams @ the Global...Applying ResearchOps and DesignOps in globally distributed teams @ the Global...
Applying ResearchOps and DesignOps in globally distributed teams @ the Global...
Patrizia Bertini
 
Scrum, The Agile Framework
Scrum, The Agile FrameworkScrum, The Agile Framework
Scrum, The Agile Framework
Ichsan Rahardianto
 
26 Time Management Hacks I Wish I'd Known at 20
26 Time Management Hacks I Wish I'd Known at 2026 Time Management Hacks I Wish I'd Known at 20
26 Time Management Hacks I Wish I'd Known at 20
Étienne Garbugli
 
Defining Future Capabilities – Beyond Guesswork
Defining Future Capabilities – Beyond GuessworkDefining Future Capabilities – Beyond Guesswork
Defining Future Capabilities – Beyond Guesswork
LearningCafe
 

Was ist angesagt? (20)

Five Key Numbers to Gauge your Agile Engineering Efforts
Five Key Numbers to Gauge your Agile Engineering EffortsFive Key Numbers to Gauge your Agile Engineering Efforts
Five Key Numbers to Gauge your Agile Engineering Efforts
 
Building Great Presentations
Building Great PresentationsBuilding Great Presentations
Building Great Presentations
 
The Asana Culture Code
The Asana Culture CodeThe Asana Culture Code
The Asana Culture Code
 
合意形成の技術(ファシリテーション・ワークショップ)公開スライド:後半
合意形成の技術(ファシリテーション・ワークショップ)公開スライド:後半合意形成の技術(ファシリテーション・ワークショップ)公開スライド:後半
合意形成の技術(ファシリテーション・ワークショップ)公開スライド:後半
 
#OpenSeriousGame L'art du feedback utile
#OpenSeriousGame L'art du feedback utile#OpenSeriousGame L'art du feedback utile
#OpenSeriousGame L'art du feedback utile
 
Sociocratie et Lean Change Method - Etienne Laverdière
Sociocratie et Lean Change Method - Etienne LaverdièreSociocratie et Lean Change Method - Etienne Laverdière
Sociocratie et Lean Change Method - Etienne Laverdière
 
デザイン思考の基礎
デザイン思考の基礎デザイン思考の基礎
デザイン思考の基礎
 
How to have difficult conversations
How to have difficult conversations How to have difficult conversations
How to have difficult conversations
 
¿Qué son los OKR´S?
¿Qué son los OKR´S?¿Qué son los OKR´S?
¿Qué son los OKR´S?
 
Handy culture deck v2.0
Handy culture deck v2.0 Handy culture deck v2.0
Handy culture deck v2.0
 
RedMartian Culture Code
RedMartian Culture CodeRedMartian Culture Code
RedMartian Culture Code
 
How things still don’t quite work at Spotify... and how we’re trying to solve it
How things still don’t quite work at Spotify... and how we’re trying to solve itHow things still don’t quite work at Spotify... and how we’re trying to solve it
How things still don’t quite work at Spotify... and how we’re trying to solve it
 
[Trung Hoang] Shu-Ha-Ri applied to Agile team
[Trung Hoang] Shu-Ha-Ri applied to Agile team[Trung Hoang] Shu-Ha-Ri applied to Agile team
[Trung Hoang] Shu-Ha-Ri applied to Agile team
 
Slideshareで見つけた「読みやすい・見やすいスライド」に共通する4つのポイント
Slideshareで見つけた「読みやすい・見やすいスライド」に共通する4つのポイントSlideshareで見つけた「読みやすい・見やすいスライド」に共通する4つのポイント
Slideshareで見つけた「読みやすい・見やすいスライド」に共通する4つのポイント
 
たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力たとえ日本人同士でも必要な異文化理解力
たとえ日本人同士でも必要な異文化理解力
 
17 Things Powerful People Say
17 Things Powerful People Say17 Things Powerful People Say
17 Things Powerful People Say
 
Applying ResearchOps and DesignOps in globally distributed teams @ the Global...
Applying ResearchOps and DesignOps in globally distributed teams @ the Global...Applying ResearchOps and DesignOps in globally distributed teams @ the Global...
Applying ResearchOps and DesignOps in globally distributed teams @ the Global...
 
Scrum, The Agile Framework
Scrum, The Agile FrameworkScrum, The Agile Framework
Scrum, The Agile Framework
 
26 Time Management Hacks I Wish I'd Known at 20
26 Time Management Hacks I Wish I'd Known at 2026 Time Management Hacks I Wish I'd Known at 20
26 Time Management Hacks I Wish I'd Known at 20
 
Defining Future Capabilities – Beyond Guesswork
Defining Future Capabilities – Beyond GuessworkDefining Future Capabilities – Beyond Guesswork
Defining Future Capabilities – Beyond Guesswork
 

Andere mochten auch

Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und Systemadministratoren
Johann-Peter Hartmann
 
Agile versus Management WJAX 2014
Agile versus Management WJAX 2014Agile versus Management WJAX 2014
Agile versus Management WJAX 2014
Johann-Peter Hartmann
 
Das Ende der Karriere
Das Ende der KarriereDas Ende der Karriere
Das Ende der Karriere
Johann-Peter Hartmann
 
Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!
Johann-Peter Hartmann
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektes
Johann-Peter Hartmann
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
Johann-Peter Hartmann
 
Die Architektur, die man kann
Die Architektur, die man kannDie Architektur, die man kann
Die Architektur, die man kann
Johann-Peter Hartmann
 
Javascript Security
Javascript SecurityJavascript Security
Javascript Security
jgrahamc
 
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
Johann-Peter Hartmann
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developers
Johann-Peter Hartmann
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
Johann-Peter Hartmann
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
Johann-Peter Hartmann
 
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
 
DevOps jenseits der Tools
DevOps jenseits der ToolsDevOps jenseits der Tools
DevOps jenseits der Tools
Johann-Peter Hartmann
 
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
Johann-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 China
Johann-Peter Hartmann
 
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
Johann-Peter Hartmann
 
Wetware Bugs and Refactoring
Wetware Bugs and RefactoringWetware Bugs and Refactoring
Wetware Bugs and Refactoring
Johann-Peter Hartmann
 
NewWork in der Praxis
NewWork in der PraxisNewWork in der Praxis
NewWork in der Praxis
Johann-Peter Hartmann
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
Johann-Peter Hartmann
 

Andere mochten auch (20)

Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und Systemadministratoren
 
Agile versus Management WJAX 2014
Agile versus Management WJAX 2014Agile versus Management WJAX 2014
Agile versus Management WJAX 2014
 
Das Ende der Karriere
Das Ende der KarriereDas Ende der Karriere
Das Ende der Karriere
 
Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektes
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
 
Die Architektur, die man kann
Die Architektur, die man kannDie Architektur, die man kann
Die Architektur, die man kann
 
Javascript Security
Javascript SecurityJavascript Security
Javascript Security
 
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
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developers
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
 
Legacy php - Sanieren oder Ablösen?
Legacy php  - Sanieren oder Ablösen?Legacy php  - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?
 
DevOps jenseits der Tools
DevOps jenseits der ToolsDevOps jenseits der Tools
DevOps jenseits der Tools
 
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
 
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
 
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
 
Wetware Bugs and Refactoring
Wetware Bugs and RefactoringWetware Bugs and Refactoring
Wetware Bugs and Refactoring
 
NewWork in der Praxis
NewWork in der PraxisNewWork in der Praxis
NewWork in der Praxis
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 

Ähnlich wie Management brainfucks

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
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
Johann-Peter Hartmann
 
Agile Führung - echt jetzt?
Agile Führung - echt jetzt?Agile Führung - echt jetzt?
Agile Führung - echt jetzt?
Agile Usergroup Unterfranken
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
Johann-Peter Hartmann
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
Mayflower GmbH
 
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
Gerrit Beine
 
Planlos mit Plan
Planlos mit PlanPlanlos mit Plan
Planlos mit Plan
Frank Düsterbeck
 
Was tun wenn niemand im Team aktiv ist.pdf
Was tun wenn niemand im Team aktiv ist.pdfWas tun wenn niemand im Team aktiv ist.pdf
Was tun wenn niemand im Team aktiv ist.pdf
Oliver Schirmer
 
Produktive teams
Produktive teamsProduktive teams
Produktive teams
Mayflower GmbH
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
Mayflower GmbH
 
Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)
Roman Rackwitz
 
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
NETUserGroupBern
 
Performancemessung, jetzt in echt
Performancemessung, jetzt in echtPerformancemessung, jetzt in echt
Performancemessung, jetzt in echt
Johann-Peter Hartmann
 
Digitalisierung alles in Bewegung
Digitalisierung alles in BewegungDigitalisierung alles in Bewegung
Digitalisierung alles in Bewegung
Björn Schotte
 
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
Jan Brinkmann
 
Erfolgreiche rewrites
Erfolgreiche rewritesErfolgreiche rewrites
Erfolgreiche rewrites
Johann-Peter Hartmann
 
10 Dinge, die wir in unserem SPRINT-Prozess gelernt haben
10 Dinge, die wir in unserem SPRINT-Prozess gelernt haben10 Dinge, die wir in unserem SPRINT-Prozess gelernt haben
10 Dinge, die wir in unserem SPRINT-Prozess gelernt haben
Cleverclip
 
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
Markus Harrer
 
Whitepaper digitale Teamkultur
Whitepaper digitale TeamkulturWhitepaper digitale Teamkultur
Whitepaper digitale Teamkultur
Anatoli Fichtner
 
Webinar 22.08.2014
Webinar 22.08.2014Webinar 22.08.2014
Webinar 22.08.2014
Niko Ryba
 

Ähnlich wie Management brainfucks (20)

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...
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
 
Agile Führung - echt jetzt?
Agile Führung - echt jetzt?Agile Führung - echt jetzt?
Agile Führung - echt jetzt?
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
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
 
Planlos mit Plan
Planlos mit PlanPlanlos mit Plan
Planlos mit Plan
 
Was tun wenn niemand im Team aktiv ist.pdf
Was tun wenn niemand im Team aktiv ist.pdfWas tun wenn niemand im Team aktiv ist.pdf
Was tun wenn niemand im Team aktiv ist.pdf
 
Produktive teams
Produktive teamsProduktive teams
Produktive teams
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)Profile Roman Rackwitz (deutsch)
Profile Roman Rackwitz (deutsch)
 
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
 
Performancemessung, jetzt in echt
Performancemessung, jetzt in echtPerformancemessung, jetzt in echt
Performancemessung, jetzt in echt
 
Digitalisierung alles in Bewegung
Digitalisierung alles in BewegungDigitalisierung alles in Bewegung
Digitalisierung alles in Bewegung
 
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
 
Erfolgreiche rewrites
Erfolgreiche rewritesErfolgreiche rewrites
Erfolgreiche rewrites
 
10 Dinge, die wir in unserem SPRINT-Prozess gelernt haben
10 Dinge, die wir in unserem SPRINT-Prozess gelernt haben10 Dinge, die wir in unserem SPRINT-Prozess gelernt haben
10 Dinge, die wir in unserem SPRINT-Prozess gelernt haben
 
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]
 
Whitepaper digitale Teamkultur
Whitepaper digitale TeamkulturWhitepaper digitale Teamkultur
Whitepaper digitale Teamkultur
 
Webinar 22.08.2014
Webinar 22.08.2014Webinar 22.08.2014
Webinar 22.08.2014
 

Mehr von Johann-Peter Hartmann

The End of my Career
The End of my CareerThe End of my Career
The End of my Career
Johann-Peter Hartmann
 
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
Johann-Peter Hartmann
 
Serverside Cryptoparty
Serverside CryptopartyServerside Cryptoparty
Serverside Cryptoparty
Johann-Peter Hartmann
 
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
Johann-Peter Hartmann
 
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
 
Profiling for Grown-Ups
Profiling for Grown-UpsProfiling for Grown-Ups
Profiling for Grown-Ups
Johann-Peter Hartmann
 
Paradigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationenParadigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationen
Johann-Peter Hartmann
 

Mehr von Johann-Peter Hartmann (7)

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

Management brainfucks

  • 1. Management Brainfucks Willkommen zum Talk zu Management Brainfucks.
  • 2. Management Brainfucks Eigentlich wollte ich ja nur einen Talk mit Fuck im Titel auf einer Konferenz halten. Aber in Wahrheit geht es mir gar nicht darum.
  • 3. Management Brainfucks Eigentlich wollte ich ja nur einen Talk mit Fuck im Titel auf einer Konferenz halten. Aber in Wahrheit geht es mir gar nicht darum.
  • 4. Wissens- vermittlung Es geht ebenfalls nicht um Wissensvermittlung
  • 5. Wissens- vermittlung Es geht ebenfalls nicht um Wissensvermittlung
  • 6. Nicht- Wissens- vermittlung Sondern um Nichtwissensvermittlung. Wir reden schliesslich über Management. Und das ist genau der Punkt.
  • 7. Hier haben wir einen international anerkannten Experten in Nichtwissen.
  • 8. Donald Rumsfeld Genau, das ist Donald Rumsfeld, seines Zeichens ehemaliger Verteidigungsminister der USA, ausserdem Erfinder von Bio- Atom- Chemiewaffen und vermutlich auch Alientechnologie im Irak, und einer der profiliersten Nichtwisser der Welt. Er war in der Lage, mit Nichtwissen sogar Kriege zu beginnen.
  • 9. Donald Rumsfeld We do know of certain knowledge that Osama Bin Laden is either in Afghanistan, or in some other country, or dead. Der hat solche Dinge gesagt. Eigentlich sagt er damit: wir haben keine ahnung bis auf die tatsache, dass er auf diesem Planeten ist. Ausser wenn er tot ist, dann kann es auch sein, dass er bei den aliens ist.
  • 10. Donald Rumsfeld But there are also unknown unknowns – there are things we do not know we don't know. Hier hat er versucht Nichtwissen zu systematisieren, mit den unknown unknows. Jetzt kann man sagen - das ist ja sein Problem, nicht unseres. Aber ist das wirklich so?
  • 11. „Wielange würde ein kompletterRewrite mit node.js dauern?“ Das ist so ein Klassiker. Heute fragt jeder „Wie lange würde ein Komplett-Rewrite auf Basis von Symfony2, Zend Framework 2 oder, für die mutigen, node.js, dauern?“.
  • 12. Selbst wenn alle Features bekannt sind haben wir keine präzise Schätzung. WTF?!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.
  • 13. Wir können noch nicht mal gut erklären, warum wir das nicht wissen. Und es wird noch schlimmer - wir können noch nicht mal erklären, warum wir so dermassen daneben liegen.
  • 14. Selbst wenn wir es empirisch wieder und wieder bewiesen haben.  Und wir können es nicht erklären, obwohl wir die schlechte Qualität unserer Schätzungen wieder und wieder unter Beweis gestellt haben. Selbst empirischem Wissen wird nicht geglaubt.
  • 15. ?Pair Programming Zwei Programmierer werden effizienter wenn nur einer arbeitet und der andere zuguckt Das gilt genauso für die durchaus positiven Dinge, die Thema dieses Vortrags sind. Pair Programming: Ich setzte zwei Developer an die gleiche Aufgabe, und am Ende sind sie effizienter. Und zwar mit dem an dieser Aufgabe Beteiligtem Code und so, nicht etwa durch Wissenstransfer oder Juniors einlernen.
  • 16. 27 % more productive !Eine akademische Case-Study von Jensen aus 2003 hat einen Produktivitätsvorsprung von 127% durch Pair Programming nachgewiesen. Das waren natürlich echte Projekte, und man kann ihnen vorwerfen, nicht unter Laborbedingungen passiert zu sein.
  • 17. !101% more productive Unter Laborbedingungen sieht es sogar noch besser aus: In einem Experiment von 2006, von Xu und Rajlich, wurde sogar eine Produktivitätssteigerung von 201 Prozent gegenüber einzelner Programmierung nachgewiesen.
  • 18. ?Overhours Ein Programmierer leistet mehr in 8 Stunden als in 14 Stunden? Ein ähnliches Beispiel sind Overhours. Wenn jemand 8 Stunden arbeitet, und dann noch mal 6 hinterher, dann sollte das zumindest grob in Richtung des anderthalbfachen an Arbeitsleistung gehen, oder?
  • 19. !Productivity 6h > 8h > 14h 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.
  • 20. 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.
  • 21. Team Size ?Wenn ich ein Team deutlich größer mache wird es nicht deutlich produktiver? Es gibt in Brooks Law auch eine Ausprägung davon: Adding people to a late project makes it later.Diesen Fehler machen wir sogar bei Mayflower noch regelmässig.
  • 22. !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.
  • 23. ?less knowledge Wenn ich den besten Senior aus dem Team entferne wird das Team effizienter? Aber die einfache Addition geht nicht nur in den Fällen von Arbeitszeit oder Leuten nicht auf. Auch bei Knowhow im Team gilt die Regel nicht.
  • 24. !more productive 40%der Velocity durch den Senior Gesamtvelocity um 20%gesteigert Das ist sogar eine Geschichte die uns selbst passiert ist - ein wirklich, wirklich guter Mann, Teamplayer, freundlich und cooler Kollege macht den größten Teil der Arbeit in jedem Sprint, bringt brillante Ideen ein. Doch als er aus dem Team verschwindet steigert sich die Performance des Gesamtteams.
  • 25. ?many more Low Prio First Dumb Developer First Das sind noch längst nicht alle Brainfucks, die Software bereithält. Wenn man in jeden Sprint Low-Prio-Tasks mit einbezieht wird die Gesamtperformance besser. Und ein Team ist effizienter, wenn man die Tasks als erstes dem Kollegen mit der kleinsten Erfahrung assigned und der erfahrenste Kollegen nur noch die Tasks bekommt, die am Ende übrig bleiben. Wer Rückfragen dazu hat kann sich bei mir melden.
  • 26. !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.
  • 27. Selbst wenn wir es empirisch wieder und wieder bewiesen 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.
  • 28. 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.
  • 29. Ich weiß das, ich bin einer von ihnen.  Und ich muss das wissen, denn ich bin selbst einer. Wer kennt mich noch nicht? Ich bin auf vielen IPCs, deshalb frage ich :-).
  • 30. ?Wer arbeitet mit Storypoints? Wer von den Anwesenden schätzt gerne Aufwände?
  • 31. ?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.
  • 32. Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische Beispiele sind ... Was haben alle diese Punkte gemeinsam?
  • 33. „Mein Debugger funktioniert bei den Unit-Tests nicht.“ Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische Beispiele sind ... Was haben alle diese Punkte gemeinsam?
  • 34. „Mein Debugger funktioniert bei den Unit-Tests nicht.“ „Vagrant startet die virtuelle Maschine nicht mehr.“ Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische Beispiele sind ... Was haben alle diese Punkte gemeinsam?
  • 35. „Mein Debugger funktioniert bei den Unit-Tests nicht.“ „Vagrant startet die virtuelle Maschine nicht mehr.“ „Der Bug ist erst in der neuen Library gefixed, und 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?
  • 36. Ich wusste die Antwort vorher nicht. Ich wusste sie vorher nicht. Und nicht nur das.
  • 37. Ich wusste vorher noch nicht, dass ich eine Antwort brauche. Und noch schlimmer: Ich wusste vorher auch noch nicht, dass ich sie nicht wusste. Also die Unknown Unknowns, von denen Donald Rumsfeld sprach.
  • 38. Ich wusste vorher noch nicht, dass ich eine Antwort brauche. Und noch schlimmer: Ich wusste vorher auch noch nicht, dass ich sie nicht wusste. Also die Unknown Unknowns, von denen Donald Rumsfeld sprach.
  • 39. 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.
  • 40. Orders of Ignorance Ignoranz 0ter Ordnung: Ich weiss etwas. Das klingt zwar jetzt schwachsinning, macht aber durchaus Sinn. Wenn ich etwas sicher weiss, bin ich kein Stück ignorant. Diesbezüglich.
  • 41. Orders of Ignorance Ignoranz 1ter Ordnung: Ich weiss etwas bestimmtes nicht. Wenn ich etwas nicht weiss, geht das auch ok. Wenn in meiner Anforderung steht „Backgroundcolor bitte aus dem Styleguide.“, dann weiss ich zwar die Farbe nicht, ich kann aber nachgucken, nachfragen oder ähnliches.
  • 42. Orders of Ignorance Ignoranz 2ter Ordnung: Ich weiss nicht, was ich nicht weiss. 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. Klassiker sind natürlich Bugs, aber auch inkompatible Libraries, Webservices oder sonstige Schnittstellen. Aber ich weiss was ich machen kann, um es herauszufinden - im agilen meist einfach machen, die fragen kommen schon von alleine.
  • 43. Orders of Ignorance Ignoranz 3ter Ordnung: Ich weiss nicht wie ich herausfinde, was ich nicht weiss. Und was ist, wenn wir es nicht ausprobieren können? Das sind natürlich zum einen schlecht probierbare Dinge wie die Bugs im Notfallprogramm unseres Kernkraftwerkes unter realen Bedingungen, aber auch einfache Dinge wie zukünftige Nutzerwünsche vor Launch.
  • 44. Orders of Ignorance Ignoranz 4ter Ordnung: Ich weiss nicht, dass es unterschiedliche Arten von Nichtwissen gibt. Das wird die anwesenden Informatiker freuen - es gibt auch Meta-Ignoranz, wenn ich nicht weiss, dass es unterschiedlichen Arten von Nichtwissen gibt.
  • 45. Orders of Ignorance Ignoranz 4ter Ordnung: Es gibt nur 1te Ordnung: Ich weiss etwas bestimmtes nicht. Und genau da liegt eines der Management-Probleme: es gibt nur Nichtwissen erster Ordnung. Ich muss vorher alle richtigen Fragen stellen, dann weiss ich alles und kann nach Plan vorgehen.
  • 46. CHAOS REPORT 2011 WASSERFALL 29% 57% 14% Successful Challenged Failed Quelle: Standish Group Chaos Report 2011 Mit wieviel Nichtwissen wir es zu tun haben habe ich schon am Detailbeispielen gezeigt, aber das gilt natürlich auch für das Gesamtbild. Wenn wir schon alles wüssten, brauchten wir nur nach Plan zu arbeiten. Fakt ist aber, dass am Ende das Nichtwissen über den ganzen Projekterfolg entscheidet.
  • 47. CHAOS REPORT 2011 AGILE 9% 49% 42% Successful Challenged Failed Quelle: Standish Group Chaos Report 2011 Ich hatte ja schon erwähnt, dass agil besser mit nichtwissen umgeht, und deshalb etwas besser darsteht. Nichtsdestotrotz kommen wir auch hier nicht über 42% erfolgreiche Projekte.
  • 48. Scope Creep Dark Matter 50% Wir geben unserem Nichtwissen sogar Namen!
  • 49. Wie geht man mit solchen Welten um? Genau das wollte auch IBM wissen, und deshalb haben sie 1999 Dave E.Snowden beauftragt. Und zwar konkret:
  • 50. Das wollte auch diese Firma wissen.
  • 51. Dave Snowden Und die hat diesen Menschen beauftragt, das herauszufinden. Er kommt aus Wales und forscht an der Komplexitätstheorie im Bereich Sensemaking.
  • 52. 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.
  • 53. 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.
  • 54. Komplex Kompliziert Chaotisch Einfach Verwirrung Und so sieht das aus. Und mit diesen Quadranten kam herr snowden am ende heraus Er sagt: Manager nehmen ihre Arbeitswelt als komplex, kompliziert, chaotisch oder einfach wahr. Und je nach Wahrnehmung agieren sie anders.
  • 55. Einfach Der Zusammenhang zwischen Ursache und Wirkung ist bekannt, vorhersagbar und wiederholbar. Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine Überraschungen zu erwarten.
  • 56. Einfach Beispiele: Email schreiben Browser bedienen Es ist keine Rückfrage notwendig Im Software Development gibt es kaum Beispiele für solche Tätigkeiten, selbst ein CRUD oder ein zusätzliches Formular braucht Rückfragen.
  • 57. Einfach Erkennen Kategorisieren Reagieren Best Practice Weil man auf bekanntem Gelände ist kommt man gut und planbar voran. Das sind genau die Tasks, die wir gut schätzen können, ohne erst groß spezifizieren und planen zu müssen.
  • 58. Kompliziert Ursache und Wirkung sind über Zeit und Raum getrennt, aber nachvollziehbar und wiederholbar. Wenn ich im komplizierten Quadranten bin ist es nicht mehr trivial, aber machbar. Es ist besser, wenn ich eine Ausbildung und/oder Erfahrung mitbringe. Wird auch Knowable genannt, man kann es also sicher wissen, wenn man will.
  • 59. Beispiele: CRUD Layout anpassen Es kann immer wie geplant umgesetzt werden. KompliziertBei uns in der IT gibt es leider nur wenige Beispiele für solche Sachen, vielleicht der 10te CRUD im gleichen System.
  • 60. Erkennen Analysieren Reagieren Kompliziert Good Practice Im Gegensatz zu simple komme ich nicht einfach über blosses draufschauen zum Ziel. Ich muss tatsächlich die notwendigen Informationen einholen,
  • 61. Chaotisch Der Zusammenhang zwischen Ursache und Wirkung ist nicht erkennbar. Da wirds gemein. Es gibt keinen erkennbaren Zusammenhang zwischen Ursache und Wirkung.
  • 62. Beispiele: Heisenbugs Hackereinbruch „Hoffentlich bringt das jetzt was.“ ChaotischIn der Praxis gibt es auch regelmässig solche Situationen.
  • 63. Handeln Erkennen Reagieren Chaotisch Novel Practice Wie gehe ich vor - ich probiere etwas aus und gucke, ob das klappt. Kennt Ihr Shotgun Debugging? Ich tweake an diversen Stellen im Code und gucke, ob sich was ändert. Wer hat das schon mal gemacht?
  • 64. Komplex Im Nachhinein ist ein Zusammenhang zwischen Ursache und Wirkung erkennbar. Es ist nicht vorhersagbar, aber eine Wiederholung kann passieren. Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine Überraschungen zu erwarten.
  • 65. Beispiele: Schachspiel Innovative Software Komplexe Software Ich weiß noch nicht, was am Ende genau herauskommen wird. KomplexKomplexe Tätigkeiten sind unser tägliches Brot.
  • 66. Probieren Erkennen Reagieren Komplex ... Practice In einem komplexen System probiere ich etwas aus, erkenne die Wirkung und reagiere darauf. Aber ich habe einen vorteil gegenüber der chaotischen Welt, und es haben sich bestimmte Praktiken bewährt. Welche erkläre ich gleiche.
  • 67. Komplexe Systeme Wir haben es meistens mit komplexen systemen zu tun. Viel second order ignorance bedeutet, dass nicht alles im Vorfeld knowable ist. Wasserfall ist ein modell, das in der komplizierten Welt mit first order ignorance funktionieren würde, aber in einer Welt mit second order ignorance scheitern muss. Simple ist es manchmal, und das ist auch super so. chaotisch ist es auch manchmal, und das ist nicht so super so. meistens ist es bei uns komplex.
  • 68. Komplexe Systeme bedeutet, dass ich verschiedene Komponenten habe, die autark agieren. Diese Komponenten können selbst simpel sein, oder komplex. Oder Chaotisch. Aber ich kann aus den Einzelnen Komponenten nicht ableiten, wie sich das Gesamtsystem verhält.
  • 69. Das liegt daran, dass die Elemente interagieren. Es gibt viele Interaktionen zwischen den Teilen des Systems, und sie reagieren aufeinander. Kleine Änderungen können grossen Wirkungen haben (Schmetterlingseffekt). Ich kann nicht im Vorhinein wissen, wie alle Teile sich gemeinsam auf Zeit verhalten werden.
  • 70. Beispiele? Kennt jemand Beispiele für solche Systeme in seiner Arbeitswelt?
  • 72.       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.
  • 73. Erst 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.
  • 74. „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.
  • 75. „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. Für welche Art von Systemen gilt dieser Satz?
  • 76. ?Aber was kann ich dann machen? Wie kann ich in so einer Branche überhaupt was sinnvolles tun, wenn ich mich auf nichts verlassen kann?
  • 77. Emergente Praktiken Probieren Erkennen Reagieren Das hatte uns Cynefin ja schon gesagt. Ich probiere, ich erkenne, und ich reagiere darauf. Und es gibt ein paar Dinge die ich probiere, bei denen im Erkennen immer herauskommt „Das funktioniert.“
  • 78. Wenn etwas in 75% der Fälle geholfen hat, werde ich es auch weiterhin probieren. Und wenn eine der probierten Sachen in 80% der Fälle funktioniert, dann wende ich sie in Zukunft auch an.
  • 79. Pair Programming Test Driven Development Sustainable Pace Collective Code Ownership Story Points ... Emergente PraktikenUnd 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.
  • 80. Sie funktionieren nicht immer, aber oft. Emergente PraktikenEmergente Praktiken sind Verhaltensmuster des komplexen Systems, nicht der Einzelelemente. Ich kann sie nicht erzwingen. Sie gelten nicht immer. Aber oft. Es kann sein, dass sie aufhören, in meinem System zu funktionieren. Das ist der Grund, warum die agilen Methoden empirisch so schön nachweisbar sind, wissenschaftlich aber nicht. Weil sie in einem komplexen System passieren.
  • 81. Die Heuristik funktioniert, nicht das einzelne Element. 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 trotzde mehr Aufschluß über Team-Performance und Releaseplanung als Alternativen.
  • 82. Komplex Kompliziert Chaotisch Einfach Verwirrung 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 defaulted, in dem man sich am sichersten fühlt.
  • 83. Komplex Kompliziert Chaotisch Einfach Verwirrung Probieren Erkennen Reagieren Erkennen Analysieren Reagieren 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 defaulted, in dem man sich am sichersten fühlt.
  • 84. Default to Comfort Zone != Komplex Management Brainfucks Und genau da kommen die Management Brainfucks her. Wenn ein Manager sich nicht bewusst ist, dass er in einer komplexen Welt arbeitet, und deshalb auf seine Komfortzone zurückgreift.
  • 85. Verwirrung Kompliziert Erkennen Analysieren Reagieren Wasserfall Detailliertes Pflichtenheft Micromanagement Meilensteinplan Agil zum Reporting feste Ziele Good Practice Wenn er denkt er wäre in einer komplizierten Welt, und man könnte alles im vorhinein wissen oder Fragen, dann möchte er Planen, Messen, Kontrollieren und Steuern. Und man sieht dort Dinge wie wasserfalliges Vorgehen, die Fragen nach Pflichtenheften als Dokumentation des vollständigen benötigten Wissens etc.
  • 86. Verwirrung Standardverfahren Standardprozesse Handlungsanweisungen Dokumentation Fixer Baukasten Einfach Erkennen Beurteilen Reagieren Best Practice Wenn er denkt er wäre in einer einfachen Welt, dann fordert er die Regeln der Welt an. Man erkennt es: Standardverfahren/prozeduren, Handlungsanweisungen, Dokumentation, fixe Baukästen, generatoren und module als Lösungen für _alles_. Baukästen sind gut für die simplen Teile, aber nicht für komplexe Systeme.
  • 87. Default to Comfort Zone Pair Programming „Wir haben nicht die Ressourcen zum Pair Programming.“ Emergente Praktiken Probieren Erkennen Reagieren Noch mal zur Erinnerung: wenn ich weiss, dass ich in der komplexen Zone bin, versuche ich kontinuierlich zu probieren, kontinuierlich zu erkennen und kontinuierliche zu reagieren. und am Ende habe ich ein Set von emergenten Praktiken, die mir häufiger Erfolg gebracht haben als andere. Aber was heisst das konkret?
  • 88. Komplex Pair Programming Ok, wir probieren das einfach mal aus und beobachten es. Wenn der Manager weiss, dass er in der komplexen Welt unterwegs ist würde er es probieren wollen - aber nicht einmal, sondern mehrfach, und jeweils beobachten ob man im nachhinein einen Zusammenhang zwischen Pair Programming und Funktionalität erkennen kann. Würde man es offiziell einführen, wenn es funktioniert?
  • 89. Komplex Wenn es funktioniert wird es nur nicht abgeschafft. Das braucht keine Entscheidung. Nein - emergent heisst ja genau, dass sich die Praktiken durchsetzen, die Funktionieren. Und sie werden nicht offiziell eingeführt, sondern man wiederholt einfach nur die Probieren- Schritt.
  • 90. Kompliziert Pair Programming Eine Gruppe arbeitet mit Pair- Programming und eine ohne, und am Ende gucken wir, wer mehr Zeit pro Storypoint verbraucht hat. Wenn der Manager sich in einer komplizierten Welt sieht dann will er es messen. Vielleicht würde er mir sogar die Empirie glauben. Wenn es nicht funktioniert würde er aber wissen wollen, warum wir von den empirischen Daten abweichen.
  • 91. Kompliziert Pair Programming Ursache und Wirkung sind klar erkennbar. Ich mache es einfach wieder so. Er glaubt, dass Ursache und Wirkung nachvollziehbar aneinanderhängen und man ein positives Ergebnis verlässlich reproduzieren kann.
  • 92. Einfach Pair Programming Wir müssen die Features damit umgesetzt bekommen, da können wir nicht die Zeit damit verschwenden. Für den Manager in einer einfachen Welt ist es - Überraschung - einfach. Er rechnet kurz die verfügbaren Stunden pro Feature durch und stellt fest, dass man den Sprint nur zu Ende bekommt wenn man nicht im Pair arbeitet. Es ist eine Zeitfrage, und Developmentzeit und Produktivität verhalten sich linear.
  • 93. Einfach Pair Programming Produktivität wird unmittelbar durch Entwicklerstunden verursacht. Er glaubt, dass Ursache und Wirkung nachvollziehbar aneinanderhängen und man ein positives Ergebnis verlässlich reproduzieren kann. Kann er damit Erfolg haben?
  • 94. !101% more productive Und ich erinnere an vorhin - Pair Programming ist empirisch sehr erfolgreich. Trotzdem möchte man dem nicht glauben, wenn es der eigenen Weltsicht nicht entspricht. Und wird empirisch nicht sehr erfolgreich sein.
  • 95. Wie erkläre ich es also meinem Manager?
  • 96. Emergent Practice Gar nicht! Gar nicht. Es sind emergente Praktiken. Der Zusammenhang ist im Nachhinein feststellbar, nicht vorher.
  • 97. JUST DO IT. Gar nicht. Es sind emergente Praktiken. Der Zusammenhang ist im Nachhinein feststellbar, nicht vorher.
  • 98. JUST DO IT. Probieren Erkennen Reagieren Gar nicht. Es sind emergente Praktiken. Der Zusammenhang ist im Nachhinein feststellbar, nicht vorher.
  • 99. Safe Projects Probieren Erkennen Reagieren Zum Beispiel über Safe Projects, bei denen wenig Risiko im spiel ist.
  • 101. Opportunities: Bugfixing beim Launch Probieren Erkennen Reagieren Oder ich nutze eine Ausnahmesituation. Ich kenne eine Firma, die hat beim Hardcore- bugfixing bei einem Launch mit Pair Programming angefangen, und es funktioniert bis heute.
  • 103. Überreden. Probieren Erkennen Reagieren Oder ich nutze Statistiken wie in diesem Vortrag um meinen Chef zu überreden. Das ist aber ein Fake, weil er dann unter Umständen immer noch denkt, er könne sich darauf verlassen. kann er aber nicht.
  • 104. Überreden. Probieren Erkennen Reagieren Fake! Oder ich nutze Statistiken wie in diesem Vortrag um meinen Chef zu überreden. Das ist aber ein Fake, weil er dann unter Umständen immer noch denkt, er könne sich darauf verlassen. kann er aber nicht.
  • 106. Retrospektiven Probieren Erkennen Reagieren Wenn man Scrum macht gibt es eine explizite Infrastruktur für Erkennen und Reagieren. Die Retrospektive.
  • 107. Am Ende des Coding Dojos Probieren Erkennen Reagieren Wenn man kein Scrum macht am Ende des Coding Dojos eine Kurzretro, ob es was hilft.
  • 108. Auch alte Praktiken bewerten und Alternativen diskutieren. Probieren Erkennen Reagieren Wichtig dabei ist, dass man nicht nur das neue Benchmarked, sondern auch bei alten Methoden über Änderungen und Experimente nachdenke.
  • 109. Probieren Erkennen Reagieren Komplex JUST DO IT. Also im Fazit: es einfach machen. Wenn es funktioniert, wird es niemand abschaffen. Wenn es nicht funktioniert, willst Du es ohnehin selbst abschaffen.
  • 111. 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
  • 113. Zusammenhänge, die wir herstellen konnten. Und wenn es noch mehr Argumente braucht: ich kann es zwar nicht garantieren dass es bei euch funktioniert, aber ich kann erzählen, welchen Zusammenhang wir festgestellt haben.
  • 114.       Workflow Engine ORM User Management Business Objects E-Commerce-Module TCO: 75% Maintenace Web Frontend Am meisten Zeit verbringt man mit der Software nach der initialen Fertigstellung, man geht von ca 3/4 der Aufwände aus, die nach dem Release passieren. Maintenance gibt es weil es unknown unknowns gibt. Features die der Kunde erst kennt wenn er die Software sieht und nachdenkt. Und weil nachträgliche Änderungen langsamer sind als initiale Entwicklung, und weil lesen von software langsamer ist als schreiben von software. Wichtig ist also das wissen über die Zusammenhänge und Effekte innerhalb der Software.
  • 115. Collective Code Knowledge Es ist gut, wenn jeder möglichst viele Teile vom System versteht, um ein paar der Effekte seiner Handlung einschätzen zu können. Dazu brauche ich verteiltes Wissen, dass mir erheblich mehr Benefit gibt als Spezialisierung.
  • 116.       Workflow Engine ORM User Management Business Objects E-Commerce-Module PP Web Frontend Wenn man Pair Programming macht kann man besser überschauen, welche Änderung in den Business Objects welche Auswirkungen im Rest des Systems hat, und was daraus folgt. Das liegt zum einen daran, dass der Navigator sich darum kümmern kann, während der Driver auf den Code Fokussiert ist.
  • 117.       Workflow Engine ORM User Management Business Objects E-Commerce-Module TDD Web Frontend Bei Test Driven Development macht man das Netz der Abhängigkeiten explizit, indem man sie als Test oder als MockUp manifestiert. Generell programmiert man mit TDD mit weniger Seiteneffekten.
  • 118.       Workflow Engine ORM User Management Business Objects E-Commerce-Module Collective Code Ownership Web Frontend Ähnlich wirkt auch Collective Code Ownership - weil jeder jeden Code anfasst lernt er immer mehr über die Effekte im Netz. Und weil er die Seiteneffekte kennt
  • 119.       Workflow Engine ORM User Management Business Objects E-Commerce-Module Low Prio First Web Frontend Das gleiche gilt für Low-Prio-Tickets, die einen grossen Netzwerkeffekt haben - sie verzinsen sich durch andere Tickets, und deshalb lohnt es sich, sie vorzuziehen.
  • 120. Team > Indivuum Scrummaster Product Owner Senior Dev Junior Dev QA User Experience Das ist auch der Grund, warum das Team mehr zählt als das Individuum. Vernetzte Effekte lassen sich am besten über mehrere Leute klären als individuell. Wenn das Team keine Verantwortung übernimmt weil der Senior sie aktiv wahrnimmt und kompetent ist, dann ist die Produktivität schlechter als wenn alle Ihr Wissen über das Netz einbringen. Individuen sind nicht gut in Komplexität.
  • 121. Probieren und Emergenz erzeugen Optimieren für Netze -> TEAM Priorisieren und Verteilen für Komplexität