Post on 27-Jun-2015
description
transcript
Agile vs
ManagementHallo 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.
?Pair Programming
Zwei Programmierer werden effizienter wenn einer arbeitet und der andere zuguckt
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?
27 %more productive
!Eine 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?
OverhoursEin ä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.
!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. Das heisst, dass der Entwickler in der sechsten Woche zwar 14 Stunden im Büro sitzt, aber die Produktivät einer Halbtagskraft liefern kann.
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. 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.
!Estimation
Die Produktivität ist höher
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.
Orders of Ignorance
Ignoranz 0ter Ordnung:
Ich weiß etwas.
Abwesenheit von Ignoranz
Das klingt zwar jetzt unnötig, macht aber durchaus Sinn. Wenn ich etwas sicher weiß, bin ich nicht ignorant.
Orders of Ignorance
Ich ändere in style.css die Farbe auf #ffffff
Ignoranz 0ter Ordnung:
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.
Orders of Ignorance
Ich weiss etwas bestimmtes nicht.
Abwesenheit von Wissen
Ignoranz 1ter Ordnung:
Wenn ich etwas nicht weiß, geht das auch ok. Solange ich weiß, was ich nicht weiß - und wie ich zu dem Wissen komme.
Orders of Ignorance
Ändere die Farbe in style.css auf den
Default-Wert
Ignoranz 1ter Ordnung:
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
Ich weiß nicht, was ich nicht weiß.
Abwesenheit von Erkennen.
Ignoranz 2ter Ordnung:
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.
Orders of Ignorance
Mach die Library kompatibel.
Ignoranz 2ter Ordnung:
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.
Orders of Ignorance
Ignoranz 3ter Ordnung:
Ich weiß nicht, wie ich herausfinde was ich
nicht weiß.
Abwesenheit von Vorgehen
Und was ist, wenn wir es nicht ausprobieren können?
Orders of Ignorance
Finde die beste Library auf Github.
Ignoranz 3ter Ordnung:
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.
Orders of Ignorance
Ignoranz 4ter Ordnung:
Ich weiß 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
Es gibt nur 1te Ordnung: !
Ich weiss etwas bestimmtes nicht.
Ignoranz 4ter Ordnung:
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.
Orders of Ignorance
Und wir?
Wie sieht es bei uns ITlern aus?
Aber welche Form der Ignoranz ist bei uns denn massgeblich?
Orders of Ignorance
Und wir?
Nichtwissen erster Ordnung kann man im Vorfeld klären.
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 %
57 %
14 %
SuccessfulChallengedFailed
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 %
SuccessfulChallengedFailed
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
49 %47 %
4 %
SuccessfulChallengedFailed
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
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. Ignoranz 0ter Ordnung: ich weiss alles.
Einfach
Beispiele: Email schreiben
Browser bedienen !
Es ist keine Rückfrage notwendig
Im Software Development gibt es kaum Beispiele für solche Tätigkeiten, selbst ein CRUD oder ein zusätzliches Formular braucht Rückfragen. Für Entwickler sind E-Mail schreiben und Browser bedienen solche Tätigkeiten.
Einfach
Erkennen Kategorisieren
Reagieren
Best Practice
Ignoranz 0ter OrdnungWeil man auf bekanntem Gelände ist kommt man gut und planbar voran. Das sind genau die Tasks, die wir gut schätzen können, ohne erst groß spezifizieren und planen zu müssen. Also arbeitet man nach dem System erkennen - kategorisieren - reagieren. Das Reagieren ergibt sich zwangsläufig aus dem Kategorisieren, und es gibt eine bekannte Best Practice, wie zu reagieren ist.
Kompliziert
Ursache und Wirkung sind über Zeit und Raum getrennt,
aber nachvollziehbar und wiederholbar.
Wenn ich im komplizierten Quadranten bin ist es nicht mehr trivial, aber machbar. Es ist besser, wenn ich eine Ausbildung und/oder Erfahrung mitbringe. Wird auch Knowable genannt, man kann es also sicher wissen, wenn man will. Hier 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.
KompliziertFü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
Kompliziert
Good Practice
Ignoranz 1ter OrdnungBei solchen Problemen gehe ich nach Erkennen - Analysieren - Reagieren vor. Das heisst, dass ich in Analysieren Zeit stecken muss, bevor ich reagieren kann. Und dass es keine Best Practice gibt, sondern nur gut practice - denn die konkrete Reaktion ergibt sich aus dem Vorwissen und der Analyse, und beides kann sich unterscheiden.
Chaotisch
Der Zusammenhang zwischen Ursache und Wirkung ist
nicht erkennbar.
In Chaotisch wirds gemein. Es gibt keinen erkennbaren Zusammenhang zwischen Ursache und Wirkung. 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.“
ChaotischIn 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
ChaotischNovel Practice
Ignoranz 3ter OrdnungUnd genau so ist der Vorgehen - Ich mache etwas - quasi ohne Nachdenken zuvor - und erkenne, was es bewirkt hat, und reagiere dann darauf. Shotgun-Debugging oder Chicken Voodoo sind Antipattern in der Softwareentwicklung, die darauf basieren. Ich probiere einfach solange, bis es funktioniert.
Komplex
Im Nachhinein ist ein Zusammenhang zwischen
Ursache und Wirkung erkennbar. Es ist nicht vorhersagbar, aber eine
Wiederholung kann passieren.
Komplex ist gemein. 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.
KomplexIgnoranz 2ter OrdnungKomplexe Tätigkeiten sind unser tägliches Brot.
Einfach
Einfach
Chaotisch
Einfach
Komplex
Kompliziert
KomplexWeiss 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
KomplexUnd 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
Chaotisch
Einfach
Komplex
Kompliziert
Komplexverstärkend
dämpfend
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?
KomplexGenau, das ist ein Schmetterlingseffekt. Mit sehr wenig Ressourceneinsatz - zB dem Flügelschlag eines Schmetterlings - werden woanders auf der Welt Wirbelstürme in Gang gebracht.
KomplexWir 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
Chaotisch
Einfach
Komplex
Kompliziert
Komplexverstärkend
dämpfend
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 :-)
Team
Scrummaster
Product Owner
Senior Dev
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
SoftwareWeb 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.
Software
„When we created Scrum we did not talk about Lean,
we talked about complex adaptive systems.“
Jeff Sutherland
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
KomplexKonkret 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.
KomplexKennt 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.
Emergente Praktiken
Komplex
Ich habe durch Probieren gelernt, dass B rauskommt wenn ich A mache.
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.
Emergente Praktiken
Komplex
Ich habe durch Probieren gelernt, dass gute Qualität rauskommt wenn ich Tests als erstes mache.
Ein Beispiel für so eine emergente Praxis ist zum Beispiel Test Driven Development.
Emergente Praktiken
Komplex
Ich habe durch Probieren gelernt, dass mehr Code rauskommt wenn ich Pair Programming mache.
Oder Pair Programming. Was mache ich, wenn ich sehe, dass die Performance nicht höher ist? Genau, ich mache es nicht.
Komplex
Wenn etwas in 75% der Fälle geholfen hat, werde ich es auch
weiterhin machen.
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.
Komplex
Wie nennt man das, wenn ein Team
seinen Prozess selbst entwickelt?
Und was passiert, wenn die Minions selbst Dinge probieren, erkennen und darauf reagieren, um herauszufinden welche Praktiken funktionieren und welche nicht?
Selbst-organisation
Komplex
Probieren Erkennen Reagieren
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.
Komplex
The best architectures, requirements, and designs
emerge
from self-organizing teams.
Die komplette agile Entwicklung basiert auf emergenten Praktiken, das ist insbesondere im agilen Manifest zu finden.
Komplex
Agil ist eine Antwort auf komplexe Aufgaben
Selbstorganisation Lernschleifen
Emergente Praktiken
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 DeMarcoAuch 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 DeMarcoIn 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=16111+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
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 zurückgegriffen, in dem man sich am sichersten fühlt.
Methoden aus dem falschen Quadranten.
Verwirrung
Genau diese Verwirrung ist die Quelle der meisten Probleme von IT und Management.
Methoden aus dem falschen Quadranten.
IT ist meistens komplex.
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.
einfach schwierig
Un
klar
Kla
r
An
ford
eru
ng
Lösung
Einfach
Kompli ziert
Komplex
Chaotisch
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.
Standardprozesse Handlungsanweisungen Checklisten Protokollierte Verfahren Baukastensysteme Developer sind frei beweglich
EinfachErkennen Beurteilen Reagieren Best Practice
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.
Autoritäres Management Micromanagement Mushroom Management Cargo Cult Golden Hammer Syndrome
Einfach dysfunktional
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.
Lastenheft/Pflichtenheft Klare Prozesse Architekten & Gremien Meilensteinplan & GANTT-Pläne Verträge & Dokumentation Klare Verantwortung Ziele & Prämien
KompliziertErkennen Analysieren Reagieren Good Practice
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.
Transaktionales Management (MbO) Grosse, bekannte Prozesse Death by Planning Architects Don’t Code Blamestorming Fear of Success
Kompliziert dysfunktional
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.
• Agil initiert durch Development • abgesprochen mit Management • mit internem Coach
Optimal
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 RadarsUnd 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?
Emergente Praktiken
Komplex
Ich habe durch Probieren gelernt, dass B rauskommt wenn ich A mache.
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.
klein hoch
ho
chkl
ein
Ben
efit
Risiko / Kosten
• Scrum Master Role
• Retrospectives
• Continuous Integration
• Test Driven Development
• Pair Programming• 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.
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
Danke!
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