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