Your SlideShare is downloading. ×
0
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Management brainfucks
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Management brainfucks

10,537

Published on

Wie erkläre ich einem klassischen Manager, warum Programmierer effizienter werden, wenn sie mit zwei Leuten an der gleichen Aufgabe sitzen? Warum ein Programmierer in 14 Stunden täglich nicht mehr …

Wie erkläre ich einem klassischen Manager, warum Programmierer effizienter werden, wenn sie mit zwei Leuten an der gleichen Aufgabe sitzen? Warum ein Programmierer in 14 Stunden täglich nicht mehr schafft als in 8, warum ein Team schneller wird, wenn man das Programmiergenie entfernt. Warum man effizienter wird, wenn man Low-Prio-Tasks vor High-Prio-Tasks macht und nur 6 von 8 Stunden planen will.

Published in: Business
6 Comments
31 Likes
Statistics
Notes
  • Ralf: ja, natürlich. Ich kann im komplexen Bereich kann ich metrische Abbildungen ins Simple bzw. ins Komplizierte erzeugen. Und es kann sein, dass sie mir statistisch häufig eine korrektes Bild der Realität geben. Der Unterschied ist: sie sind nicht verlässlich, weil es eben keine verbindliche ursächliche Folge gibt, und sie sind kontextabhängig, weil sie äusseren Einflüssen unterliegen, die nonlinear wirken.
    Wir haben das im Resultat als klares Go für selbstselektierte Metriken (sprich: durch die mit der Ausführung Betreuten) und als klares No-Go für die Nutzung als Leistungserfolgsbewertung transaktionaler Natur verstanden.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Großartige anschauliche Darstellung des Themas, daran sind schon viele vorher gescheitert :-)
    Bei manchen Teilen sehe ich noch Diskussionsbedarf oder vielleicht sind sie mir auch einfach unklar. Ich glaube, wenn man versteht in welcher Domäne man ist kann man auch Messen.
    Nur man muss sich sehr bewußt sein was man misst und wie man damit umgeht.
    Defined Process Control -> time/budget tracking (man kennt ja das System ganz gut
    Stochastic Process Control -> process metrics (man hat ein gewisses wissen von dem System und kann dadurch durch Metriken zur Steuerung nutzen)
    Empirical Process Control - final outcame (man kennt das System nur noch als Back Box oder hat ein unzureichendes Verständnis von dem System -> also bleibt nur noch die Messing vom finalen Outcame)
    Die spannende Frage ist was man im chaotischen Bereich macht. Hier kann man ja nicht mal mehr aus dem finalen Outcame lernen. Die Welt dreht sich ja so schnell, dass die immer neu ist ... Ich glaube aber man könnte sich aus dem Submodel für Chaos von Snowden Messgrößen ableiten, die man hier zur Steuerung einsetzen kann. Hab dazu aber bisher nix gesehen un selber was gemacht.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Stephan: Du hast Recht. Die Präsentation richtete sich auf der Webinale sowohl in Inhalt wie Sprache an Developer. Glücklicherweise gibt mir jemand in Hamburg Anlass, das ganze auch in Richtung Manager auszuformulieren. Ich durchkämme gerade Gerhard Wohland und Peter Kruse um auch non-IT-Beispiele für nicht-intuitives Verhalten (aka Brainfucks:-) ) von komplexen Systemen zu erläutern. Wird also passend nachgeliefert. Unbedingt empfehlenswert ist btw. auch Niels neues Buch: http://www.amazon.de/Organisation-f%C3%BCr-Komplexit%C3%A4t-lebendig-H%C3%B6chstleistung/dp/3732280454
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Guten Tag! Sehr schöne Präsentation und sehr gute Darstellung. Ich stimme inhaltlich mit allen Punkten überein. Viele Punkte zum Thema Pair-Programming oder 6 Stunden Tage sind bei uns auch immer wieder Thema und da helfen diese Folien sehr.
    Einziges Problem ist für mich der Titel: Genau die Leute (Manager - zu denen ich übrigens auch gehöre), denen es erklärt werden soll, hören nicht zu, wenn auf den ersten drei Folien 'fuck' steht.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Ich arbeite bei einer IT-Personalberatung als Produktentwickler und wir verstehen schon sehr gut. Deine Slides haben mich um Lichtjahre weitergebracht, was das Verständnis für die Problematik von IT-Spezialisten angeht... DANKE für deine viele Arbeit und das sharen!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
10,537
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
167
Comments
6
Likes
31
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ManagementBrainfucksWillkommen zum Talk zu Management Brainfucks.
  • 2. ManagementBrainfucksEigentlich wollte ich ja nur einen Talk mit Fuck im Titel auf einer Konferenz halten.Aber in Wahrheit geht es mir gar nicht darum.
  • 3. ManagementBrainfucksEigentlich 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-vermittlungEs geht ebenfalls nicht um Wissensvermittlung
  • 5. Wissens-vermittlungEs geht ebenfalls nicht um Wissensvermittlung
  • 6. Nicht-Wissens-vermittlungSondern um Nichtwissensvermittlung. Wir reden schliesslich über Management. Und das istgenau der Punkt.
  • 7. Hier haben wir einen international anerkannten Experten in Nichtwissen.
  • 8. DonaldRumsfeldGenau, das ist Donald Rumsfeld, seines Zeichens ehemaliger Verteidigungsminister der USA,ausserdem Erfinder von Bio- Atom- Chemiewaffen und vermutlich auch Alientechnologie imIrak, und einer der profiliersten Nichtwisser der Welt. Er war in der Lage, mit Nichtwissensogar Kriege zu beginnen.
  • 9. DonaldRumsfeldWe do know ofcertain knowledgethat Osama BinLaden is either inAfghanistan, or insome othercountry, or dead.Der hat solche Dinge gesagt. Eigentlich sagt er damit: wir haben keine ahnung bis auf dietatsache, dass er auf diesem Planeten ist. Ausser wenn er tot ist, dann kann es auch sein,dass er bei den aliens ist.
  • 10. DonaldRumsfeldBut there are alsounknownunknowns – thereare thingswe do not knowwe dont 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. „Wielangewürde einkompletterRewritemit node.js dauern?“Das ist so ein Klassiker. Heute fragt jeder „Wie lange würde ein Komplett-Rewrite auf Basisvon Symfony2, Zend Framework 2 oder, für die mutigen, node.js, dauern?“.
  • 12. Selbst wenn alle Featuresbekannt sind haben wirkeine präzise Schätzung.WTF?!Das muss man sich mal auf der Zunge zergehen lassen: wir kennen schon alle Features, wirwissen wie es aussieht, trotzdem haben wir in Wahrheit keine Ahnung.
  • 13. Wir können noch nichtmal gut erklären, warumwir das nicht wissen.Und es wird noch schlimmer - wir können noch nicht mal erklären, warum wir so dermassendaneben liegen.
  • 14. Selbst wenn wir esempirisch wieder und wiederbewiesen haben.Und wir können es nicht erklären, obwohl wir die schlechte Qualität unserer Schätzungenwieder und wieder unter Beweis gestellt haben. Selbst empirischem Wissen wird nichtgeglaubt.
  • 15. ?Pair ProgrammingZwei Programmiererwerden effizienter wennnur einer arbeitet undder andere zugucktDas 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 sieeffizienter. Und zwar mit dem an dieser Aufgabe Beteiligtem Code und so, nicht etwa durchWissenstransfer oder Juniors einlernen.
  • 16. 27 %more productive!Eine akademische Case-Study von Jensen aus 2003 hat einen Produktivitätsvorsprung von127% durch Pair Programming nachgewiesen. Das waren natürlich echte Projekte, und mankann ihnen vorwerfen, nicht unter Laborbedingungen passiert zu sein.
  • 17. !101%more productiveUnter Laborbedingungen sieht es sogar noch besser aus: In einem Experiment von 2006, vonXu und Rajlich, wurde sogar eine Produktivitätssteigerung von 201 Prozent gegenübereinzelner Programmierung nachgewiesen.
  • 18. ?OverhoursEin Programmierer leistetmehr in 8 Stundenals in 14 Stunden?Ein ähnliches Beispiel sind Overhours. Wenn jemand 8 Stunden arbeitet, und dann noch mal 6hinterher, dann sollte das zumindest grob in Richtung des anderthalbfachen anArbeitsleistung gehen, oder?
  • 19. !Productivity6h> 8h> 14hFür Wissensarbeiter liegt der Peak sogar bei 6h - wenn er 6 Stunden am Tag aktiv arbeitet istdas Maximum erreicht (Quelle: Why Crunch Modes Doesn’t Work: Six Lessons)Eine einfache Addition gilt nicht.
  • 20. Texthttp://www.lostgarden.com/2008/09/rules-of-productivity-presentation.htmlMan weiss sogar, dass jede Überstundenarbeit nach ein paar Wochen zwangsläufig inErholungsphasen mit kleinerer Produktivität endet, ob man daheim oder im Büro sitzt. Unddass diese Erholung grösser ist als die Arbeitsphase.
  • 21. Team Size?Wenn ich ein Teamdeutlich größermache wird es nichtdeutlich produktiver?Es gibt in Brooks Law auch eine Ausprägung davon: Adding people to a late project makes itlater.Diesen Fehler machen wir sogar bei Mayflower noch regelmässig.
  • 22. !100.000 LOC<5 Personen:ca 9 Monate>20 Personen:ca 9 MonateDoug 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 kleinenTeams bewertet, anhand von 100.000 equivalent source lines of code. Und heraus kam, dassmittlere Teams mit 5 bis 9 Leuten nur knapp weniger Code schaffen als grosse Teams mitmehr als 20 Leuten.Auch hier gilt eine einfache Addition nicht.
  • 23. ?less knowledgeWenn ich den bestenSenior aus dem Teamentferne wird das Teameffizienter?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 productive40%der Velocitydurch den SeniorGesamtvelocityum 20%gesteigertDas 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 diePerformance des Gesamtteams.
  • 25. ?many moreLow Prio FirstDumb Developer FirstDas sind noch längst nicht alle Brainfucks, die Software bereithält. Wenn man in jeden SprintLow-Prio-Tasks mit einbezieht wird die Gesamtperformance besser. Und ein Team isteffizienter, wenn man die Tasks als erstes dem Kollegen mit der kleinsten Erfahrung assignedund der erfahrenste Kollegen nur noch die Tasks bekommt, die am Ende übrig bleiben. WerRückfragen dazu hat kann sich bei mir melden.
  • 26. !http://davidfrico.com/agile-book.htmOder man wendet sich direkt an den Experten, was empirisches Wissen angeht. David F Ricohat im Rahmen seiner Forschung einmal alle Studien auf dem Gebiet gesammelt undzusammengefasst, und stellt netterweise auch auf seiner Website die Daten zur Verfügung.Das Buch leider nicht.
  • 27. Selbst wenn wir esempirisch wieder und wiederbewiesen haben.Aber, wie bereits oben - das reicht nicht. Es reicht nicht, dass jede Studie, jede akademischeUntersuchung, jede Untersuchung von IBM oder Consulting-Unternehmen beim gleichenErgebnis herauskommt.
  • 28. Man kann esManagernnicht erklären.Wir kommen einfach nicht zu den Managern durch. Dieses empirische Wissen hat die gleicheQualität wie die „Amerikanische Wissenschaftler haben herausgefunden“-Einspaltenartikel inder 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 aufvielen IPCs, deshalb frage ich :-).
  • 30. ?Wer arbeitet mitStorypoints?Wer von den Anwesenden schätzt gerne Aufwände?
  • 31. ?Warum nicht einfachStunden?Warum schätzen wir nicht einfach in Stunden, wie damals vorm Krieg. Warum sagen wir nichteinfach: 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. TypischeBeispiele sind ...Was haben alle diese Punkte gemeinsam?
  • 33. „Mein Debugger funktioniert beiden Unit-Tests nicht.“Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. TypischeBeispiele sind ...Was haben alle diese Punkte gemeinsam?
  • 34. „Mein Debugger funktioniert beiden Unit-Tests nicht.“„Vagrant startet die virtuelleMaschine nicht mehr.“Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. TypischeBeispiele sind ...Was haben alle diese Punkte gemeinsam?
  • 35. „Mein Debugger funktioniert beiden Unit-Tests nicht.“„Vagrant startet die virtuelleMaschine nicht mehr.“„Der Bug ist erst in der neuenLibrary gefixed, und die brauchtandere Updates.“Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. TypischeBeispiele sind ...Was haben alle diese Punkte gemeinsam?
  • 36. Ich wusste die Antwortvorher 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 IgnoranceOrders ofIgnoranceDas offizielle Organ der Association for Computing Machinery, die Communications of theACM, haben sich mal einen Kopf darüber gemacht, was man so alles nicht wissen kann. unddas ganze Ausformuliert. Genannt haben sie es die Orders of Ignorance.
  • 40. Orders of IgnoranceIgnoranz 0ter Ordnung:Ich weiss etwas.Das klingt zwar jetzt schwachsinning, macht aber durchaus Sinn. Wenn ich etwas sicherweiss, bin ich kein Stück ignorant. Diesbezüglich.
  • 41. Orders of IgnoranceIgnoranz 1ter Ordnung:Ich weiss etwasbestimmtes 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 kannaber nachgucken, nachfragen oder ähnliches.
  • 42. Orders of IgnoranceIgnoranz 2ter Ordnung:Ich weiss nicht,was ich nicht weiss.Hier kommen wir bei Donald Rumsfeld an, oder bei unserem Business- uns fehlt nicht nureine Antwort, wir wussten vorher noch nicht mal, dass wir fragen müssen. Klassiker sindnatürlich Bugs, aber auch inkompatible Libraries, Webservices oder sonstige Schnittstellen.Aber ich weiss was ich machen kann, um es herauszufinden - im agilen meist einfachmachen, die fragen kommen schon von alleine.
  • 43. Orders of IgnoranceIgnoranz 3ter Ordnung:Ich weiss nicht wie ichherausfinde, was ichnicht weiss.Und was ist, wenn wir es nicht ausprobieren können? Das sind natürlich zum einen schlechtprobierbare Dinge wie die Bugs im Notfallprogramm unseres Kernkraftwerkes unter realenBedingungen, aber auch einfache Dinge wie zukünftige Nutzerwünsche vor Launch.
  • 44. Orders of IgnoranceIgnoranz 4ter Ordnung:Ich weiss nicht, dass esunterschiedliche Arten vonNichtwissen gibt.Das wird die anwesenden Informatiker freuen - es gibt auch Meta-Ignoranz, wenn ich nichtweiss, dass es unterschiedlichen Arten von Nichtwissen gibt.
  • 45. Orders of IgnoranceIgnoranz 4ter Ordnung:Es gibt nur 1te Ordnung:Ich weiss etwasbestimmtes nicht.Und genau da liegt eines der Management-Probleme: es gibt nur Nichtwissen ersterOrdnung. Ich muss vorher alle richtigen Fragen stellen, dann weiss ich alles und kann nachPlan vorgehen.
  • 46. CHAOS REPORT 2011WASSERFALL29%57%14%SuccessfulChallengedFailedQuelle: Standish Group Chaos Report 2011Mit wieviel Nichtwissen wir es zu tun haben habe ich schon am Detailbeispielen gezeigt, aberdas gilt natürlich auch für das Gesamtbild. Wenn wir schon alles wüssten, brauchten wir nurnach Plan zu arbeiten. Fakt ist aber, dass am Ende das Nichtwissen über den ganzenProjekterfolg entscheidet.
  • 47. CHAOS REPORT 2011AGILE9%49%42%SuccessfulChallengedFailedQuelle: Standish Group Chaos Report 2011Ich hatte ja schon erwähnt, dass agil besser mit nichtwissen umgeht, und deshalb etwasbesser darsteht. Nichtsdestotrotz kommen wir auch hier nicht über 42% erfolgreiche Projekte.
  • 48. Scope CreepDark Matter50%Wir geben unserem Nichtwissen sogar Namen!
  • 49. Wie geht man mitsolchen 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 SnowdenUnd die hat diesen Menschen beauftragt, das herauszufinden. Er kommt aus Wales undforscht an der Komplexitätstheorie im Bereich Sensemaking.
  • 52. Study theactual,not theofficialmanagement practiceUnd IBM hat ihm einen sehr schönen Auftrag gegeben:die echten Managementmethoden, die praktiziert wurden, und nicht die offiziellenanzugucken. Und da gab es ein interessantes Ergebnis. Mit einem interessanten Namen.
  • 53. CynefinLebensraum, PlatzUnd zwar mit dem Cynefin-Framework. Ich hoffe ich spreche es richtig aus, mein walisisch istetwas eingerostet. Cynefin beschreibt meine Umgebung, die Welt, in der ich lebe - und zwarinklusive Ort, Kultur und Leuten.
  • 54. Komplex KompliziertChaotisch EinfachVerwirrungUnd so sieht das aus.Und mit diesen Quadranten kam herr snowden am ende herausEr sagt: Manager nehmen ihre Arbeitswelt als komplex, kompliziert, chaotisch oder einfachwahr. Und je nach Wahrnehmung agieren sie anders.
  • 55. EinfachDer Zusammenhang zwischenUrsache und Wirkung ist bekannt,vorhersagbar und wiederholbar.Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keineÜberraschungen zu erwarten.
  • 56. EinfachBeispiele:Email schreibenBrowser bedienenEs ist keine Rückfrage notwendigIm Software Development gibt es kaum Beispiele für solche Tätigkeiten, selbst ein CRUD oderein zusätzliches Formular braucht Rückfragen.
  • 57. EinfachErkennenKategorisierenReagierenBest PracticeWeil man auf bekanntem Gelände ist kommt man gut und planbar voran. Das sind genau dieTasks, die wir gut schätzen können, ohne erst groß spezifizieren und planen zu müssen.
  • 58. KompliziertUrsache und Wirkung sind überZeit und Raum getrennt, abernachvollziehbar undwiederholbar.Wenn ich im komplizierten Quadranten bin ist es nicht mehr trivial, aber machbar. Es istbesser, wenn ich eine Ausbildung und/oder Erfahrung mitbringe. Wird auch Knowablegenannt, man kann es also sicher wissen, wenn man will.
  • 59. Beispiele:CRUDLayout anpassenEs kann immer wie geplant umgesetztwerden.KompliziertBei uns in der IT gibt es leider nur wenige Beispiele für solche Sachen, vielleicht der 10teCRUD im gleichen System.
  • 60. ErkennenAnalysierenReagierenKompliziertGood PracticeIm Gegensatz zu simple komme ich nicht einfach über blosses draufschauen zum Ziel. Ichmuss tatsächlich die notwendigen Informationen einholen,
  • 61. ChaotischDer Zusammenhang zwischenUrsache und Wirkung ist nichterkennbar.Da wirds gemein. Es gibt keinen erkennbaren Zusammenhang zwischen Ursache und Wirkung.
  • 62. Beispiele:HeisenbugsHackereinbruch„Hoffentlich bringt das jetzt was.“ChaotischIn der Praxis gibt es auch regelmässig solche Situationen.
  • 63. HandelnErkennenReagierenChaotischNovel PracticeWie gehe ich vor - ich probiere etwas aus und gucke, ob das klappt. Kennt Ihr ShotgunDebugging? Ich tweake an diversen Stellen im Code und gucke, ob sich was ändert. Wer hatdas schon mal gemacht?
  • 64. KomplexIm Nachhinein ist einZusammenhang zwischenUrsache und Wirkung erkennbar.Es ist nicht vorhersagbar, aber eineWiederholung kann passieren.Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keineÜberraschungen zu erwarten.
  • 65. Beispiele:SchachspielInnovative SoftwareKomplexe SoftwareIch weiß noch nicht, was am Endegenau herauskommen wird.KomplexKomplexe Tätigkeiten sind unser tägliches Brot.
  • 66. ProbierenErkennenReagierenKomplex... PracticeIn einem komplexen System probiere ich etwas aus, erkenne die Wirkung und reagieredarauf. Aber ich habe einen vorteil gegenüber der chaotischen Welt, und es haben sichbestimmte Praktiken bewährt. Welche erkläre ich gleiche.
  • 67. KomplexeSystemeWir haben es meistens mit komplexen systemen zu tun. Viel second order ignorancebedeutet, dass nicht alles im Vorfeld knowable ist. Wasserfall ist ein modell, das in derkomplizierten Welt mit first order ignorance funktionieren würde, aber in einer Welt mitsecond 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 unskomplex.
  • 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 kannaus den Einzelnen Komponenten nicht ableiten, wie sich das Gesamtsystem verhält.
  • 69. Das liegt daran, dass die Elemente interagieren. Es gibt viele Interaktionen zwischen denTeilen des Systems, und sie reagieren aufeinander. Kleine Änderungen können grossenWirkungen haben (Schmetterlingseffekt). Ich kann nicht im Vorhinein wissen, wie alle Teilesich gemeinsam auf Zeit verhalten werden.
  • 70. Beispiele?Kennt jemand Beispiele für solche Systeme in seiner Arbeitswelt?
  • 71. TeamScrummasterProduct OwnerSenior DevJunior DevQAUser Experience
  • 72. Workflow EngineORMUser ManagementBusiness ObjectsE-Commerce-ModuleSoftwareWeb FrontendAuch Software selbst ist ein komplexes System. Gerade in der Entwicklung, wenn noch nichtklar ist, wie alle Teile genau aussehen könen bzw welche Konsequenzen die Interaktionenhaben.
  • 73. Erst im Nachhinein ist einZusammenhang zwischenUrsache und Wirkung erkennbar.Es ist nicht vorhersagbar, aber eineWiederholung kann passieren.Und wenn man sowas vor Augen hat ist auch das Verhalten plausibel: Wenn ich ein Teamwieder so zusammen an ein neues Projekt setzte, kann ein ganz anderes Ergebnisherauskommen. Wenn ich die gleiche Architektur für eine andere Lösung einsetze kann siefunktionieren, muss aber nicht. Sogar im gleichen System muss es nicht mehr funktionieren,weil es sich selbst schon bewegt hat.
  • 74. „Insanity: doing the samething over and over againand expecting differentresults.“Und das ist gemein, was das schlicht unser normaler Wissen ausser Kraft setzt.In komplexen Systemen erwarten wir unterschiedliche Resultate, wenn wir mehrfach dasgleiche machen.
  • 75. „You can‘t control whatyou can‘t measure.“Tom DeMarcoAuch dieser Ausspruch von Tom DeMarco gilt nicht. Ich kann in einem komplexen Systemzwar messen, aber ich kann deshalb noch lange nicht kontrollieren. Für welche Art vonSystemen gilt dieser Satz?
  • 76. ?Aber was kann ich dann machen? Wie kann ich in so einer Branche überhaupt was sinnvollestun, wenn ich mich auf nichts verlassen kann?
  • 77. EmergentePraktikenProbierenErkennenReagierenDas 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 „Dasfunktioniert.“
  • 78. Wenn etwas in 75% der Fällegeholfen hat, werde ich es auchweiterhin probieren.Und wenn eine der probierten Sachen in 80% der Fälle funktioniert, dann wende ich sie inZukunft auch an.
  • 79. Pair ProgrammingTest Driven DevelopmentSustainable PaceCollective Code OwnershipStory Points ...EmergentePraktikenUnd genau diese agilen Prinzipien sind emergente Praktiken. Dinge von denen man malgemerkt hat, dass Software häufig, nicht immer, besser funktioniert wenn man sie macht.
  • 80. Sie funktionierennicht immer, aber oft.EmergentePraktikenEmergente Praktiken sind Verhaltensmuster des komplexen Systems, nicht derEinzelelemente. 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 Hours1 212 523 645 1008 111Velocity Hours8+8=16111+111=2225+3+2+2+2+1+1=16100+64+52+52+52+21+21=365Mike 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 aufeine 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 Velocitytrotzde mehr Aufschluß über Team-Performance und Releaseplanung als Alternativen.
  • 82. Komplex KompliziertChaotisch EinfachVerwirrungUnd 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 derVerwirrung. Und in dem Fall wird auf den Quadranten defaulted, in dem man sich amsichersten fühlt.
  • 83. Komplex KompliziertChaotisch EinfachVerwirrungProbierenErkennenReagierenErkennenAnalysierenReagierenHandelnErkennenReagierenErkennenBeurteilenReagierenUnd 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 derVerwirrung. Und in dem Fall wird auf den Quadranten defaulted, in dem man sich amsichersten fühlt.
  • 84. Default to Comfort Zone != KomplexManagementBrainfucksUnd genau da kommen die Management Brainfucks her. Wenn ein Manager sich nicht bewusstist, dass er in einer komplexen Welt arbeitet, und deshalb auf seine Komfortzonezurückgreift.
  • 85. VerwirrungKompliziertErkennenAnalysierenReagierenWasserfallDetailliertes PflichtenheftMicromanagementMeilensteinplanAgil zum Reportingfeste ZieleGood PracticeWenn er denkt er wäre in einer komplizierten Welt, und man könnte alles im vorhinein wissenoder Fragen, dann möchte er Planen, Messen, Kontrollieren und Steuern. Und man sieht dortDinge wie wasserfalliges Vorgehen, die Fragen nach Pflichtenheften als Dokumentation desvollständigen benötigten Wissens etc.
  • 86. VerwirrungStandardverfahrenStandardprozesseHandlungsanweisungenDokumentationFixer BaukastenEinfachErkennenBeurteilenReagierenBest PracticeWenn er denkt er wäre in einer einfachen Welt, dann fordert er die Regeln der Welt an. Manerkennt es: Standardverfahren/prozeduren, Handlungsanweisungen, Dokumentation, fixeBaukä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 ZonePair Programming„Wir haben nicht die Ressourcen zum PairProgramming.“EmergentePraktikenProbierenErkennenReagierenNoch mal zur Erinnerung: wenn ich weiss, dass ich in der komplexen Zone bin, versuche ichkontinuierlich zu probieren, kontinuierlich zu erkennen und kontinuierliche zu reagieren. undam Ende habe ich ein Set von emergenten Praktiken, die mir häufiger Erfolg gebracht habenals andere. Aber was heisst das konkret?
  • 88. KomplexPair ProgrammingOk, wir probieren das einfach malaus und beobachten es.Wenn der Manager weiss, dass er in der komplexen Welt unterwegs ist würde er es probierenwollen - aber nicht einmal, sondern mehrfach, und jeweils beobachten ob man im nachhineineinen Zusammenhang zwischen Pair Programming und Funktionalität erkennen kann.Würde man es offiziell einführen, wenn es funktioniert?
  • 89. KomplexWenn es funktioniert wird es nurnicht abgeschafft.Das braucht keine Entscheidung.Nein - emergent heisst ja genau, dass sich die Praktiken durchsetzen, die Funktionieren. Undsie werden nicht offiziell eingeführt, sondern man wiederholt einfach nur die Probieren-Schritt.
  • 90. KompliziertPair ProgrammingEine Gruppe arbeitet mit Pair-Programming und eine ohne, undam Ende gucken wir, wer mehr Zeitpro Storypoint verbraucht hat.Wenn der Manager sich in einer komplizierten Welt sieht dann will er es messen. Vielleichtwürde er mir sogar die Empirie glauben. Wenn es nicht funktioniert würde er aber wissenwollen, warum wir von den empirischen Daten abweichen.
  • 91. KompliziertPair ProgrammingUrsache und Wirkung sind klarerkennbar. Ich mache es einfachwieder so.Er glaubt, dass Ursache und Wirkung nachvollziehbar aneinanderhängen und man einpositives Ergebnis verlässlich reproduzieren kann.
  • 92. EinfachPair ProgrammingWir müssen die Features damitumgesetzt bekommen, da könnenwir nicht die Zeit damitverschwenden.Für den Manager in einer einfachen Welt ist es - Überraschung - einfach. Er rechnet kurz dieverfügbaren Stunden pro Feature durch und stellt fest, dass man den Sprint nur zu Endebekommt wenn man nicht im Pair arbeitet. Es ist eine Zeitfrage, und Developmentzeit undProduktivität verhalten sich linear.
  • 93. EinfachPair ProgrammingProduktivität wird unmittelbardurch Entwicklerstundenverursacht.Er glaubt, dass Ursache und Wirkung nachvollziehbar aneinanderhängen und man einpositives Ergebnis verlässlich reproduzieren kann.Kann er damit Erfolg haben?
  • 94. !101%more productiveUnd ich erinnere an vorhin - Pair Programming ist empirisch sehr erfolgreich. Trotzdemmöchte man dem nicht glauben, wenn es der eigenen Weltsicht nicht entspricht. Und wirdempirisch nicht sehr erfolgreich sein.
  • 95. Wie erkläre ich esalso meinemManager?
  • 96. Emergent PracticeGar 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.ProbierenErkennenReagierenGar nicht. Es sind emergente Praktiken. Der Zusammenhang ist im Nachhinein feststellbar,nicht vorher.
  • 99. Safe ProjectsProbierenErkennenReagierenZum Beispiel über Safe Projects, bei denen wenig Risiko im spiel ist.
  • 100. SlackdaysCoding DojosProbierenErkennenReagierenIch probiere die Methoden an Slackdays aus.
  • 101. Opportunities:Bugfixing beim LaunchProbierenErkennenReagierenOder 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.
  • 102. Heimlich ausprobieren.ProbierenErkennenReagierenOder einfach auch nur heimlich ausprobieren.
  • 103. Überreden.ProbierenErkennenReagierenOder 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 daraufverlassen. kann er aber nicht.
  • 104. Überreden.ProbierenErkennenReagierenFake!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 daraufverlassen. kann er aber nicht.
  • 105. ProbierenErkennenReagierenKomplex
  • 106. RetrospektivenProbierenErkennenReagierenWenn man Scrum macht gibt es eine explizite Infrastruktur für Erkennen und Reagieren. DieRetrospektive.
  • 107. Am Ende desCoding DojosProbierenErkennenReagierenWenn man kein Scrum macht am Ende des Coding Dojos eine Kurzretro, ob es was hilft.
  • 108. Auch alte Praktikenbewerten undAlternativen diskutieren.ProbierenErkennenReagierenWichtig dabei ist, dass man nicht nur das neue Benchmarked, sondern auch bei altenMethoden über Änderungen und Experimente nachdenke.
  • 109. ProbierenErkennenReagierenKomplexJUST DO IT.Also im Fazit: es einfach machen. Wenn es funktioniert, wird es niemand abschaffen. Wenn esnicht funktioniert, willst Du es ohnehin selbst abschaffen.
  • 110. Danke!http://slideshare.net/johannhartmannhttps://joind.in/8752
  • 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 Teamshttp://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/1604270314http://davidfrico.com/agile-book.htmFive Orders of Ignorancehttp://www-plan.cs.colorado.edu/diwan/3308-s10/p17-armour.pdfThe Waterfall Accidenthttp://pascal.gugenberger.net/thoughts/waterfall-accident.htmlProductivity vs Overhourshttp://lunar.lostgarden.com/Rules%20of%20Productivity.pptx
  • 112. Addon-Slides
  • 113. Zusammenhänge, diewir herstellen konnten.Und wenn es noch mehr Argumente braucht: ich kann es zwar nicht garantieren dass es beieuch funktioniert, aber ich kann erzählen, welchen Zusammenhang wir festgestellt haben.
  • 114. Workflow EngineORMUser ManagementBusiness ObjectsE-Commerce-ModuleTCO: 75% MaintenaceWeb FrontendAm meisten Zeit verbringt man mit der Software nach der initialen Fertigstellung, man gehtvon ca 3/4 der Aufwände aus, die nach dem Release passieren. Maintenance gibt es weil esunknown unknowns gibt. Features die der Kunde erst kennt wenn er die Software sieht undnachdenkt. Und weil nachträgliche Änderungen langsamer sind als initiale Entwicklung, undweil lesen von software langsamer ist als schreiben von software. Wichtig ist also das wissenüber die Zusammenhänge und Effekte innerhalb der Software.
  • 115. CollectiveCodeKnowledgeEs ist gut, wenn jeder möglichst viele Teile vom System versteht, um ein paar der Effekteseiner Handlung einschätzen zu können. Dazu brauche ich verteiltes Wissen, dass mirerheblich mehr Benefit gibt als Spezialisierung.
  • 116. Workflow EngineORMUser ManagementBusiness ObjectsE-Commerce-ModulePPWeb FrontendWenn man Pair Programming macht kann man besser überschauen, welche Änderung in denBusiness Objects welche Auswirkungen im Rest des Systems hat, und was daraus folgt. Dasliegt zum einen daran, dass der Navigator sich darum kümmern kann, während der Driver aufden Code Fokussiert ist.
  • 117. Workflow EngineORMUser ManagementBusiness ObjectsE-Commerce-ModuleTDDWeb FrontendBei Test Driven Development macht man das Netz der Abhängigkeiten explizit, indem mansie als Test oder als MockUp manifestiert. Generell programmiert man mit TDD mit wenigerSeiteneffekten.
  • 118. Workflow EngineORMUser ManagementBusiness ObjectsE-Commerce-ModuleCollective Code OwnershipWeb FrontendÄhnlich wirkt auch Collective Code Ownership - weil jeder jeden Code anfasst lernt er immermehr über die Effekte im Netz. Und weil er die Seiteneffekte kennt
  • 119. Workflow EngineORMUser ManagementBusiness ObjectsE-Commerce-ModuleLow Prio FirstWeb FrontendDas gleiche gilt für Low-Prio-Tickets, die einen grossen Netzwerkeffekt haben - sie verzinsensich durch andere Tickets, und deshalb lohnt es sich, sie vorzuziehen.
  • 120. Team > IndivuumScrummasterProduct OwnerSenior DevJunior DevQAUser ExperienceDas ist auch der Grund, warum das Team mehr zählt als das Individuum. Vernetzte Effektelassen sich am besten über mehrere Leute klären als individuell. Wenn das Team keineVerantwortung übernimmt weil der Senior sie aktiv wahrnimmt und kompetent ist, dann istdie Produktivität schlechter als wenn alle Ihr Wissen über das Netz einbringen. Individuensind nicht gut in Komplexität.
  • 121. Probieren und Emergenz erzeugenOptimieren für Netze -> TEAMPriorisieren und Verteilen fürKomplexität

×