Management brainfucks

Management brainfucks
Management Brainfucks Willkommen zum Talk zu Management Brainfucks.
Management Brainfucks Eigentlich wollte ich ja nur einen Talk mit Fuck im Titel auf einer Konferenz halten. Aber in Wahrheit geht es mir gar nicht darum.
Management Brainfucks Eigentlich wollte ich ja nur einen Talk mit Fuck im Titel auf einer Konferenz halten. Aber in Wahrheit geht es mir gar nicht darum.
Wissens- vermittlung Es geht ebenfalls nicht um Wissensvermittlung
Wissens- vermittlung Es geht ebenfalls nicht um Wissensvermittlung
Nicht- Wissens- vermittlung Sondern um Nichtwissensvermittlung. Wir reden schliesslich über Management. Und das ist genau der Punkt.
Hier haben wir einen international anerkannten Experten in Nichtwissen.
Donald Rumsfeld Genau, das ist Donald Rumsfeld, seines Zeichens ehemaliger Verteidigungsminister der USA, ausserdem Erfinder von Bio- Atom- Chemiewaffen und vermutlich auch Alientechnologie im Irak, und einer der profiliersten Nichtwisser der Welt. Er war in der Lage, mit Nichtwissen sogar Kriege zu beginnen.
Donald Rumsfeld We do know of certain knowledge that Osama Bin Laden is either in Afghanistan, or in some other country, or dead. Der hat solche Dinge gesagt. Eigentlich sagt er damit: wir haben keine ahnung bis auf die tatsache, dass er auf diesem Planeten ist. Ausser wenn er tot ist, dann kann es auch sein, dass er bei den aliens ist.
Donald Rumsfeld But there are also unknown unknowns – there are things we do not know we don't know. Hier hat er versucht Nichtwissen zu systematisieren, mit den unknown unknows. Jetzt kann man sagen - das ist ja sein Problem, nicht unseres. Aber ist das wirklich so?
„Wielange würde ein kompletterRewrite mit node.js dauern?“ Das ist so ein Klassiker. Heute fragt jeder „Wie lange würde ein Komplett-Rewrite auf Basis von Symfony2, Zend Framework 2 oder, für die mutigen, node.js, dauern?“.
Selbst wenn alle Features bekannt sind haben wir keine präzise Schätzung. WTF?!Das muss man sich mal auf der Zunge zergehen lassen: wir kennen schon alle Features, wir wissen wie es aussieht, trotzdem haben wir in Wahrheit keine Ahnung.
Wir können noch nicht mal gut erklären, warum wir das nicht wissen. Und es wird noch schlimmer - wir können noch nicht mal erklären, warum wir so dermassen daneben liegen.
Selbst wenn wir es empirisch wieder und wieder bewiesen haben.  Und wir können es nicht erklären, obwohl wir die schlechte Qualität unserer Schätzungen wieder und wieder unter Beweis gestellt haben. Selbst empirischem Wissen wird nicht geglaubt.
?Pair Programming Zwei Programmierer werden effizienter wenn nur einer arbeitet und der andere zuguckt Das gilt genauso für die durchaus positiven Dinge, die Thema dieses Vortrags sind. Pair Programming: Ich setzte zwei Developer an die gleiche Aufgabe, und am Ende sind sie effizienter. Und zwar mit dem an dieser Aufgabe Beteiligtem Code und so, nicht etwa durch Wissenstransfer oder Juniors einlernen.
27 % more productive !Eine akademische Case-Study von Jensen aus 2003 hat einen Produktivitätsvorsprung von 127% durch Pair Programming nachgewiesen. Das waren natürlich echte Projekte, und man kann ihnen vorwerfen, nicht unter Laborbedingungen passiert zu sein.
!101% more productive Unter Laborbedingungen sieht es sogar noch besser aus: In einem Experiment von 2006, von Xu und Rajlich, wurde sogar eine Produktivitätssteigerung von 201 Prozent gegenüber einzelner Programmierung nachgewiesen.
?Overhours Ein Programmierer leistet mehr in 8 Stunden als in 14 Stunden? Ein ähnliches Beispiel sind Overhours. Wenn jemand 8 Stunden arbeitet, und dann noch mal 6 hinterher, dann sollte das zumindest grob in Richtung des anderthalbfachen an Arbeitsleistung gehen, oder?
!Productivity 6h > 8h > 14h Für Wissensarbeiter liegt der Peak sogar bei 6h - wenn er 6 Stunden am Tag aktiv arbeitet ist das Maximum erreicht (Quelle: Why Crunch Modes Doesn’t Work: Six Lessons) Eine einfache Addition gilt nicht.
Text http://www.lostgarden.com/2008/09/rules-of-productivity-presentation.html Man weiss sogar, dass jede Überstundenarbeit nach ein paar Wochen zwangsläufig in Erholungsphasen mit kleinerer Produktivität endet, ob man daheim oder im Büro sitzt. Und dass diese Erholung grösser ist als die Arbeitsphase.
Team Size ?Wenn ich ein Team deutlich größer mache wird es nicht deutlich produktiver? Es gibt in Brooks Law auch eine Ausprägung davon: Adding people to a late project makes it later.Diesen Fehler machen wir sogar bei Mayflower noch regelmässig.
!100.000 LOC <5 Personen: ca 9 Monate >20 Personen: ca 9 Monate Doug Putnam von QSM ist neben der Standish Group der Mensch, der am meisten Statistik über Softwareprojekte betreibt. Und dort haben sie die Produktivät von grossen und kleinen Teams bewertet, anhand von 100.000 equivalent source lines of code. Und heraus kam, dass mittlere Teams mit 5 bis 9 Leuten nur knapp weniger Code schaffen als grosse Teams mit mehr als 20 Leuten. Auch hier gilt eine einfache Addition nicht.
?less knowledge Wenn ich den besten Senior aus dem Team entferne wird das Team effizienter? Aber die einfache Addition geht nicht nur in den Fällen von Arbeitszeit oder Leuten nicht auf. Auch bei Knowhow im Team gilt die Regel nicht.
!more productive 40%der Velocity durch den Senior Gesamtvelocity um 20%gesteigert Das ist sogar eine Geschichte die uns selbst passiert ist - ein wirklich, wirklich guter Mann, Teamplayer, freundlich und cooler Kollege macht den größten Teil der Arbeit in jedem Sprint, bringt brillante Ideen ein. Doch als er aus dem Team verschwindet steigert sich die Performance des Gesamtteams.
?many more Low Prio First Dumb Developer First Das sind noch längst nicht alle Brainfucks, die Software bereithält. Wenn man in jeden Sprint Low-Prio-Tasks mit einbezieht wird die Gesamtperformance besser. Und ein Team ist effizienter, wenn man die Tasks als erstes dem Kollegen mit der kleinsten Erfahrung assigned und der erfahrenste Kollegen nur noch die Tasks bekommt, die am Ende übrig bleiben. Wer Rückfragen dazu hat kann sich bei mir melden.
!http://davidfrico.com/agile-book.htm Oder man wendet sich direkt an den Experten, was empirisches Wissen angeht. David F Rico hat im Rahmen seiner Forschung einmal alle Studien auf dem Gebiet gesammelt und zusammengefasst, und stellt netterweise auch auf seiner Website die Daten zur Verfügung. Das Buch leider nicht.
Selbst wenn wir es empirisch wieder und wieder bewiesen haben.  Aber, wie bereits oben - das reicht nicht. Es reicht nicht, dass jede Studie, jede akademische Untersuchung, jede Untersuchung von IBM oder Consulting-Unternehmen beim gleichen Ergebnis herauskommt.
Man kann es Managern nicht erklären.  Wir kommen einfach nicht zu den Managern durch. Dieses empirische Wissen hat die gleiche Qualität wie die „Amerikanische Wissenschaftler haben herausgefunden“-Einspaltenartikel in der Bildzeitung.
Ich weiß das, ich bin einer von ihnen.  Und ich muss das wissen, denn ich bin selbst einer. Wer kennt mich noch nicht? Ich bin auf vielen IPCs, deshalb frage ich :-).
?Wer arbeitet mit Storypoints? Wer von den Anwesenden schätzt gerne Aufwände?
?Warum nicht einfach Stunden? Warum schätzen wir nicht einfach in Stunden, wie damals vorm Krieg. Warum sagen wir nicht einfach: das dauert 3 Tage, und dann dauert es eben drei Tage.
Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische Beispiele sind ... Was haben alle diese Punkte gemeinsam?
„Mein Debugger funktioniert bei den Unit-Tests nicht.“ Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische Beispiele sind ... Was haben alle diese Punkte gemeinsam?
„Mein Debugger funktioniert bei den Unit-Tests nicht.“ „Vagrant startet die virtuelle Maschine nicht mehr.“ Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische Beispiele sind ... Was haben alle diese Punkte gemeinsam?
„Mein Debugger funktioniert bei den Unit-Tests nicht.“ „Vagrant startet die virtuelle Maschine nicht mehr.“ „Der Bug ist erst in der neuen Library gefixed, und die braucht andere Updates.“ Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische Beispiele sind ... Was haben alle diese Punkte gemeinsam?
Ich wusste die Antwort vorher nicht. Ich wusste sie vorher nicht. Und nicht nur das.
Ich wusste vorher noch nicht, dass ich eine Antwort brauche. Und noch schlimmer: Ich wusste vorher auch noch nicht, dass ich sie nicht wusste. Also die Unknown Unknowns, von denen Donald Rumsfeld sprach.
Ich wusste vorher noch nicht, dass ich eine Antwort brauche. Und noch schlimmer: Ich wusste vorher auch noch nicht, dass ich sie nicht wusste. Also die Unknown Unknowns, von denen Donald Rumsfeld sprach.
Orders of Ignorance Orders of Ignorance Das offizielle Organ der Association for Computing Machinery, die Communications of the ACM, haben sich mal einen Kopf darüber gemacht, was man so alles nicht wissen kann. und das ganze Ausformuliert. Genannt haben sie es die Orders of Ignorance.
Orders of Ignorance Ignoranz 0ter Ordnung: Ich weiss etwas. Das klingt zwar jetzt schwachsinning, macht aber durchaus Sinn. Wenn ich etwas sicher weiss, bin ich kein Stück ignorant. Diesbezüglich.
Orders of Ignorance Ignoranz 1ter Ordnung: Ich weiss etwas bestimmtes nicht. Wenn ich etwas nicht weiss, geht das auch ok. Wenn in meiner Anforderung steht „Backgroundcolor bitte aus dem Styleguide.“, dann weiss ich zwar die Farbe nicht, ich kann aber nachgucken, nachfragen oder ähnliches.
Orders of Ignorance Ignoranz 2ter Ordnung: Ich weiss nicht, was ich nicht weiss. Hier kommen wir bei Donald Rumsfeld an, oder bei unserem Business- uns fehlt nicht nur eine Antwort, wir wussten vorher noch nicht mal, dass wir fragen müssen. Klassiker sind natürlich Bugs, aber auch inkompatible Libraries, Webservices oder sonstige Schnittstellen. Aber ich weiss was ich machen kann, um es herauszufinden - im agilen meist einfach machen, die fragen kommen schon von alleine.
Orders of Ignorance Ignoranz 3ter Ordnung: Ich weiss nicht wie ich herausfinde, was ich nicht weiss. Und was ist, wenn wir es nicht ausprobieren können? Das sind natürlich zum einen schlecht probierbare Dinge wie die Bugs im Notfallprogramm unseres Kernkraftwerkes unter realen Bedingungen, aber auch einfache Dinge wie zukünftige Nutzerwünsche vor Launch.
Orders of Ignorance Ignoranz 4ter Ordnung: Ich weiss nicht, dass es unterschiedliche Arten von Nichtwissen gibt. Das wird die anwesenden Informatiker freuen - es gibt auch Meta-Ignoranz, wenn ich nicht weiss, dass es unterschiedlichen Arten von Nichtwissen gibt.
Orders of Ignorance Ignoranz 4ter Ordnung: Es gibt nur 1te Ordnung: Ich weiss etwas bestimmtes nicht. Und genau da liegt eines der Management-Probleme: es gibt nur Nichtwissen erster Ordnung. Ich muss vorher alle richtigen Fragen stellen, dann weiss ich alles und kann nach Plan vorgehen.
CHAOS REPORT 2011 WASSERFALL 29% 57% 14% Successful Challenged Failed Quelle: Standish Group Chaos Report 2011 Mit wieviel Nichtwissen wir es zu tun haben habe ich schon am Detailbeispielen gezeigt, aber das gilt natürlich auch für das Gesamtbild. Wenn wir schon alles wüssten, brauchten wir nur nach Plan zu arbeiten. Fakt ist aber, dass am Ende das Nichtwissen über den ganzen Projekterfolg entscheidet.
CHAOS REPORT 2011 AGILE 9% 49% 42% Successful Challenged Failed Quelle: Standish Group Chaos Report 2011 Ich hatte ja schon erwähnt, dass agil besser mit nichtwissen umgeht, und deshalb etwas besser darsteht. Nichtsdestotrotz kommen wir auch hier nicht über 42% erfolgreiche Projekte.
Scope Creep Dark Matter 50% Wir geben unserem Nichtwissen sogar Namen!
Wie geht man mit solchen Welten um? Genau das wollte auch IBM wissen, und deshalb haben sie 1999 Dave E.Snowden beauftragt. Und zwar konkret:
Das wollte auch diese Firma wissen.
Dave Snowden Und die hat diesen Menschen beauftragt, das herauszufinden. Er kommt aus Wales und forscht an der Komplexitätstheorie im Bereich Sensemaking.
Study the actual, not the official management practice Und IBM hat ihm einen sehr schönen Auftrag gegeben: die echten Managementmethoden, die praktiziert wurden, und nicht die offiziellen anzugucken. Und da gab es ein interessantes Ergebnis. Mit einem interessanten Namen.
Cynefin Lebensraum, Platz Und zwar mit dem Cynefin-Framework. Ich hoffe ich spreche es richtig aus, mein walisisch ist etwas eingerostet. Cynefin beschreibt meine Umgebung, die Welt, in der ich lebe - und zwar inklusive Ort, Kultur und Leuten.
Komplex Kompliziert Chaotisch Einfach Verwirrung Und so sieht das aus. Und mit diesen Quadranten kam herr snowden am ende heraus Er sagt: Manager nehmen ihre Arbeitswelt als komplex, kompliziert, chaotisch oder einfach wahr. Und je nach Wahrnehmung agieren sie anders.
Einfach Der Zusammenhang zwischen Ursache und Wirkung ist bekannt, vorhersagbar und wiederholbar. Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine Überraschungen zu erwarten.
Einfach Beispiele: Email schreiben Browser bedienen Es ist keine Rückfrage notwendig Im Software Development gibt es kaum Beispiele für solche Tätigkeiten, selbst ein CRUD oder ein zusätzliches Formular braucht Rückfragen.
Einfach Erkennen Kategorisieren Reagieren Best Practice Weil man auf bekanntem Gelände ist kommt man gut und planbar voran. Das sind genau die Tasks, die wir gut schätzen können, ohne erst groß spezifizieren und planen zu müssen.
Kompliziert Ursache und Wirkung sind über Zeit und Raum getrennt, aber nachvollziehbar und wiederholbar. Wenn ich im komplizierten Quadranten bin ist es nicht mehr trivial, aber machbar. Es ist besser, wenn ich eine Ausbildung und/oder Erfahrung mitbringe. Wird auch Knowable genannt, man kann es also sicher wissen, wenn man will.
Beispiele: CRUD Layout anpassen Es kann immer wie geplant umgesetzt werden. KompliziertBei uns in der IT gibt es leider nur wenige Beispiele für solche Sachen, vielleicht der 10te CRUD im gleichen System.
Erkennen Analysieren Reagieren Kompliziert Good Practice Im Gegensatz zu simple komme ich nicht einfach über blosses draufschauen zum Ziel. Ich muss tatsächlich die notwendigen Informationen einholen,
Chaotisch Der Zusammenhang zwischen Ursache und Wirkung ist nicht erkennbar. Da wirds gemein. Es gibt keinen erkennbaren Zusammenhang zwischen Ursache und Wirkung.
Beispiele: Heisenbugs Hackereinbruch „Hoffentlich bringt das jetzt was.“ ChaotischIn der Praxis gibt es auch regelmässig solche Situationen.
Handeln Erkennen Reagieren Chaotisch Novel Practice Wie gehe ich vor - ich probiere etwas aus und gucke, ob das klappt. Kennt Ihr Shotgun Debugging? Ich tweake an diversen Stellen im Code und gucke, ob sich was ändert. Wer hat das schon mal gemacht?
Komplex Im Nachhinein ist ein Zusammenhang zwischen Ursache und Wirkung erkennbar. Es ist nicht vorhersagbar, aber eine Wiederholung kann passieren. Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine Überraschungen zu erwarten.
Beispiele: Schachspiel Innovative Software Komplexe Software Ich weiß noch nicht, was am Ende genau herauskommen wird. KomplexKomplexe Tätigkeiten sind unser tägliches Brot.
Probieren Erkennen Reagieren Komplex ... Practice In einem komplexen System probiere ich etwas aus, erkenne die Wirkung und reagiere darauf. Aber ich habe einen vorteil gegenüber der chaotischen Welt, und es haben sich bestimmte Praktiken bewährt. Welche erkläre ich gleiche.
Komplexe Systeme Wir haben es meistens mit komplexen systemen zu tun. Viel second order ignorance bedeutet, dass nicht alles im Vorfeld knowable ist. Wasserfall ist ein modell, das in der komplizierten Welt mit first order ignorance funktionieren würde, aber in einer Welt mit second order ignorance scheitern muss. Simple ist es manchmal, und das ist auch super so. chaotisch ist es auch manchmal, und das ist nicht so super so. meistens ist es bei uns komplex.
Komplexe Systeme bedeutet, dass ich verschiedene Komponenten habe, die autark agieren. Diese Komponenten können selbst simpel sein, oder komplex. Oder Chaotisch. Aber ich kann aus den Einzelnen Komponenten nicht ableiten, wie sich das Gesamtsystem verhält.
Das liegt daran, dass die Elemente interagieren. Es gibt viele Interaktionen zwischen den Teilen des Systems, und sie reagieren aufeinander. Kleine Änderungen können grossen Wirkungen haben (Schmetterlingseffekt). Ich kann nicht im Vorhinein wissen, wie alle Teile sich gemeinsam auf Zeit verhalten werden.
Beispiele? Kennt jemand Beispiele für solche Systeme in seiner Arbeitswelt?
Team Scrummaster Product Owner Senior Dev Junior Dev QA User Experience
      Workflow Engine ORM User Management Business Objects E-Commerce-Module Software Web Frontend Auch Software selbst ist ein komplexes System. Gerade in der Entwicklung, wenn noch nicht klar ist, wie alle Teile genau aussehen könen bzw welche Konsequenzen die Interaktionen haben.
Erst im Nachhinein ist ein Zusammenhang zwischen Ursache und Wirkung erkennbar. Es ist nicht vorhersagbar, aber eine Wiederholung kann passieren. Und wenn man sowas vor Augen hat ist auch das Verhalten plausibel: Wenn ich ein Team wieder so zusammen an ein neues Projekt setzte, kann ein ganz anderes Ergebnis herauskommen. Wenn ich die gleiche Architektur für eine andere Lösung einsetze kann sie funktionieren, muss aber nicht. Sogar im gleichen System muss es nicht mehr funktionieren, weil es sich selbst schon bewegt hat.
„Insanity: doing the same thing over and over again and expecting different results.“ Und das ist gemein, was das schlicht unser normaler Wissen ausser Kraft setzt. In komplexen Systemen erwarten wir unterschiedliche Resultate, wenn wir mehrfach das gleiche machen.
„You can‘t control what you can‘t measure.“ Tom DeMarco Auch dieser Ausspruch von Tom DeMarco gilt nicht. Ich kann in einem komplexen System zwar messen, aber ich kann deshalb noch lange nicht kontrollieren. Für welche Art von Systemen gilt dieser Satz?
?Aber was kann ich dann machen? Wie kann ich in so einer Branche überhaupt was sinnvolles tun, wenn ich mich auf nichts verlassen kann?
Emergente Praktiken Probieren Erkennen Reagieren Das hatte uns Cynefin ja schon gesagt. Ich probiere, ich erkenne, und ich reagiere darauf. Und es gibt ein paar Dinge die ich probiere, bei denen im Erkennen immer herauskommt „Das funktioniert.“
Wenn etwas in 75% der Fälle geholfen hat, werde ich es auch weiterhin probieren. Und wenn eine der probierten Sachen in 80% der Fälle funktioniert, dann wende ich sie in Zukunft auch an.
Pair Programming Test Driven Development Sustainable Pace Collective Code Ownership Story Points ... Emergente PraktikenUnd genau diese agilen Prinzipien sind emergente Praktiken. Dinge von denen man mal gemerkt hat, dass Software häufig, nicht immer, besser funktioniert wenn man sie macht.
Sie funktionieren nicht immer, aber oft. Emergente PraktikenEmergente Praktiken sind Verhaltensmuster des komplexen Systems, nicht der Einzelelemente. Ich kann sie nicht erzwingen. Sie gelten nicht immer. Aber oft. Es kann sein, dass sie aufhören, in meinem System zu funktionieren. Das ist der Grund, warum die agilen Methoden empirisch so schön nachweisbar sind, wissenschaftlich aber nicht. Weil sie in einem komplexen System passieren.
Die Heuristik funktioniert, nicht das einzelne Element. Story Points Avg Hours 1 21 2 52 3 64 5 100 8 111 Velocity Hours 8+8=16 111+111= 222 5+3+2+2+2+1+ 1=16 100+64+52+52 +52+21+21= 365 Mike cohn hat sich mal die Mühe gemacht mittlere Zeiten für Story Points zu ermitteln. Wenn ich die durchschnittlichen Zeiten von Story Points nehme und addiere komme ich auf eine Summe, die aller Statistik nach nicht das gleiche Aussagen kann. Wenn ich eine normale Anzahl Stories über mehr als 10 Sprints nehme gibt mir die Velocity trotzde mehr Aufschluß über Team-Performance und Releaseplanung als Alternativen.
Komplex Kompliziert Chaotisch Einfach Verwirrung Und jetzt kommen wir zu dem Punkt, wo die meisten Management-Probleme herkommen. Wenn ich nicht weiss, in welchem Quadranten ich arbeite, dann bin ich in der Mitte - in der Verwirrung. Und in dem Fall wird auf den Quadranten defaulted, in dem man sich am sichersten fühlt.
Komplex Kompliziert Chaotisch Einfach Verwirrung Probieren Erkennen Reagieren Erkennen Analysieren Reagieren Handeln Erkennen Reagieren Erkennen Beurteilen Reagieren Und jetzt kommen wir zu dem Punkt, wo die meisten Management-Probleme herkommen. Wenn ich nicht weiss, in welchem Quadranten ich arbeite, dann bin ich in der Mitte - in der Verwirrung. Und in dem Fall wird auf den Quadranten defaulted, in dem man sich am sichersten fühlt.
Default to Comfort Zone != Komplex Management Brainfucks Und genau da kommen die Management Brainfucks her. Wenn ein Manager sich nicht bewusst ist, dass er in einer komplexen Welt arbeitet, und deshalb auf seine Komfortzone zurückgreift.
Verwirrung Kompliziert Erkennen Analysieren Reagieren Wasserfall Detailliertes Pflichtenheft Micromanagement Meilensteinplan Agil zum Reporting feste Ziele Good Practice Wenn er denkt er wäre in einer komplizierten Welt, und man könnte alles im vorhinein wissen oder Fragen, dann möchte er Planen, Messen, Kontrollieren und Steuern. Und man sieht dort Dinge wie wasserfalliges Vorgehen, die Fragen nach Pflichtenheften als Dokumentation des vollständigen benötigten Wissens etc.
Verwirrung Standardverfahren Standardprozesse Handlungsanweisungen Dokumentation Fixer Baukasten Einfach Erkennen Beurteilen Reagieren Best Practice Wenn er denkt er wäre in einer einfachen Welt, dann fordert er die Regeln der Welt an. Man erkennt es: Standardverfahren/prozeduren, Handlungsanweisungen, Dokumentation, fixe Baukästen, generatoren und module als Lösungen für _alles_. Baukästen sind gut für die simplen Teile, aber nicht für komplexe Systeme.
Default to Comfort Zone Pair Programming „Wir haben nicht die Ressourcen zum Pair Programming.“ Emergente Praktiken Probieren Erkennen Reagieren Noch mal zur Erinnerung: wenn ich weiss, dass ich in der komplexen Zone bin, versuche ich kontinuierlich zu probieren, kontinuierlich zu erkennen und kontinuierliche zu reagieren. und am Ende habe ich ein Set von emergenten Praktiken, die mir häufiger Erfolg gebracht haben als andere. Aber was heisst das konkret?
Komplex Pair Programming Ok, wir probieren das einfach mal aus und beobachten es. Wenn der Manager weiss, dass er in der komplexen Welt unterwegs ist würde er es probieren wollen - aber nicht einmal, sondern mehrfach, und jeweils beobachten ob man im nachhinein einen Zusammenhang zwischen Pair Programming und Funktionalität erkennen kann. Würde man es offiziell einführen, wenn es funktioniert?
Komplex Wenn es funktioniert wird es nur nicht abgeschafft. Das braucht keine Entscheidung. Nein - emergent heisst ja genau, dass sich die Praktiken durchsetzen, die Funktionieren. Und sie werden nicht offiziell eingeführt, sondern man wiederholt einfach nur die Probieren- Schritt.
Kompliziert Pair Programming Eine Gruppe arbeitet mit Pair- Programming und eine ohne, und am Ende gucken wir, wer mehr Zeit pro Storypoint verbraucht hat. Wenn der Manager sich in einer komplizierten Welt sieht dann will er es messen. Vielleicht würde er mir sogar die Empirie glauben. Wenn es nicht funktioniert würde er aber wissen wollen, warum wir von den empirischen Daten abweichen.
Kompliziert Pair Programming Ursache und Wirkung sind klar erkennbar. Ich mache es einfach wieder so. Er glaubt, dass Ursache und Wirkung nachvollziehbar aneinanderhängen und man ein positives Ergebnis verlässlich reproduzieren kann.
Einfach Pair Programming Wir müssen die Features damit umgesetzt bekommen, da können wir nicht die Zeit damit verschwenden. Für den Manager in einer einfachen Welt ist es - Überraschung - einfach. Er rechnet kurz die verfügbaren Stunden pro Feature durch und stellt fest, dass man den Sprint nur zu Ende bekommt wenn man nicht im Pair arbeitet. Es ist eine Zeitfrage, und Developmentzeit und Produktivität verhalten sich linear.
Einfach Pair Programming Produktivität wird unmittelbar durch Entwicklerstunden verursacht. Er glaubt, dass Ursache und Wirkung nachvollziehbar aneinanderhängen und man ein positives Ergebnis verlässlich reproduzieren kann. Kann er damit Erfolg haben?
!101% more productive Und ich erinnere an vorhin - Pair Programming ist empirisch sehr erfolgreich. Trotzdem möchte man dem nicht glauben, wenn es der eigenen Weltsicht nicht entspricht. Und wird empirisch nicht sehr erfolgreich sein.
Wie erkläre ich es also meinem Manager?
Emergent Practice Gar nicht! Gar nicht. Es sind emergente Praktiken. Der Zusammenhang ist im Nachhinein feststellbar, nicht vorher.
JUST DO IT. Gar nicht. Es sind emergente Praktiken. Der Zusammenhang ist im Nachhinein feststellbar, nicht vorher.
JUST DO IT. Probieren Erkennen Reagieren Gar nicht. Es sind emergente Praktiken. Der Zusammenhang ist im Nachhinein feststellbar, nicht vorher.
Safe Projects Probieren Erkennen Reagieren Zum Beispiel über Safe Projects, bei denen wenig Risiko im spiel ist.
Slackdays Coding Dojos Probieren Erkennen Reagieren Ich probiere die Methoden an Slackdays aus.
Opportunities: Bugfixing beim Launch Probieren Erkennen Reagieren Oder ich nutze eine Ausnahmesituation. Ich kenne eine Firma, die hat beim Hardcore- bugfixing bei einem Launch mit Pair Programming angefangen, und es funktioniert bis heute.
Heimlich ausprobieren. Probieren Erkennen Reagieren Oder einfach auch nur heimlich ausprobieren.
Überreden. Probieren Erkennen Reagieren Oder ich nutze Statistiken wie in diesem Vortrag um meinen Chef zu überreden. Das ist aber ein Fake, weil er dann unter Umständen immer noch denkt, er könne sich darauf verlassen. kann er aber nicht.
Überreden. Probieren Erkennen Reagieren Fake! Oder ich nutze Statistiken wie in diesem Vortrag um meinen Chef zu überreden. Das ist aber ein Fake, weil er dann unter Umständen immer noch denkt, er könne sich darauf verlassen. kann er aber nicht.
Probieren Erkennen Reagieren Komplex
Retrospektiven Probieren Erkennen Reagieren Wenn man Scrum macht gibt es eine explizite Infrastruktur für Erkennen und Reagieren. Die Retrospektive.
Am Ende des Coding Dojos Probieren Erkennen Reagieren Wenn man kein Scrum macht am Ende des Coding Dojos eine Kurzretro, ob es was hilft.
Auch alte Praktiken bewerten und Alternativen diskutieren. Probieren Erkennen Reagieren Wichtig dabei ist, dass man nicht nur das neue Benchmarked, sondern auch bei alten Methoden über Änderungen und Experimente nachdenke.
Probieren Erkennen Reagieren Komplex JUST DO IT. Also im Fazit: es einfach machen. Wenn es funktioniert, wird es niemand abschaffen. Wenn es nicht funktioniert, willst Du es ohnehin selbst abschaffen.
Danke! http://slideshare.net/johannhartmann https://joind.in/8752 
Links: Cynefin allgemein: http://cognitive-edge.com/blog/entry/5855/cynefin-papers-a-summary/ Cynefin für Entwickler: http://lizkeogh.com/2012/03/11/cynefin-for-devs/ Kleine Teams vs grosse Teams http://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient- than-large-teams/ Agile Methoden empirisch betrachtet: http://www.amazon.com/Business-Value-Agile-Software-Methods/dp/1604270314 http://davidfrico.com/agile-book.htm Five Orders of Ignorance http://www-plan.cs.colorado.edu/diwan/3308-s10/p17-armour.pdf The Waterfall Accident http://pascal.gugenberger.net/thoughts/waterfall-accident.html Productivity vs Overhours http://lunar.lostgarden.com/Rules%20of%20Productivity.pptx
Addon-Slides
Zusammenhänge, die wir herstellen konnten. Und wenn es noch mehr Argumente braucht: ich kann es zwar nicht garantieren dass es bei euch funktioniert, aber ich kann erzählen, welchen Zusammenhang wir festgestellt haben.
      Workflow Engine ORM User Management Business Objects E-Commerce-Module TCO: 75% Maintenace Web Frontend Am meisten Zeit verbringt man mit der Software nach der initialen Fertigstellung, man geht von ca 3/4 der Aufwände aus, die nach dem Release passieren. Maintenance gibt es weil es unknown unknowns gibt. Features die der Kunde erst kennt wenn er die Software sieht und nachdenkt. Und weil nachträgliche Änderungen langsamer sind als initiale Entwicklung, und weil lesen von software langsamer ist als schreiben von software. Wichtig ist also das wissen über die Zusammenhänge und Effekte innerhalb der Software.
Collective Code Knowledge Es ist gut, wenn jeder möglichst viele Teile vom System versteht, um ein paar der Effekte seiner Handlung einschätzen zu können. Dazu brauche ich verteiltes Wissen, dass mir erheblich mehr Benefit gibt als Spezialisierung.
      Workflow Engine ORM User Management Business Objects E-Commerce-Module PP Web Frontend Wenn man Pair Programming macht kann man besser überschauen, welche Änderung in den Business Objects welche Auswirkungen im Rest des Systems hat, und was daraus folgt. Das liegt zum einen daran, dass der Navigator sich darum kümmern kann, während der Driver auf den Code Fokussiert ist.
      Workflow Engine ORM User Management Business Objects E-Commerce-Module TDD Web Frontend Bei Test Driven Development macht man das Netz der Abhängigkeiten explizit, indem man sie als Test oder als MockUp manifestiert. Generell programmiert man mit TDD mit weniger Seiteneffekten.
      Workflow Engine ORM User Management Business Objects E-Commerce-Module Collective Code Ownership Web Frontend Ähnlich wirkt auch Collective Code Ownership - weil jeder jeden Code anfasst lernt er immer mehr über die Effekte im Netz. Und weil er die Seiteneffekte kennt
      Workflow Engine ORM User Management Business Objects E-Commerce-Module Low Prio First Web Frontend Das gleiche gilt für Low-Prio-Tickets, die einen grossen Netzwerkeffekt haben - sie verzinsen sich durch andere Tickets, und deshalb lohnt es sich, sie vorzuziehen.
Team > Indivuum Scrummaster Product Owner Senior Dev Junior Dev QA User Experience Das ist auch der Grund, warum das Team mehr zählt als das Individuum. Vernetzte Effekte lassen sich am besten über mehrere Leute klären als individuell. Wenn das Team keine Verantwortung übernimmt weil der Senior sie aktiv wahrnimmt und kompetent ist, dann ist die Produktivität schlechter als wenn alle Ihr Wissen über das Netz einbringen. Individuen sind nicht gut in Komplexität.
Probieren und Emergenz erzeugen Optimieren für Netze -> TEAM Priorisieren und Verteilen für Komplexität

Check these out next

Management brainfucks

Recommended

More Related Content

Slideshows for you(20)

Similar to Management brainfucks(20)

More from Johann-Peter Hartmann(19)

Recently uploaded(20)

Management brainfucks