38-mal heruntergeladen
Hochgeladen vonJohann-Peter Hartmann
Surviving Complexity
Die Präsentation behandelt die Herausforderungen und Wahrnehmungen im Bereich der Softwareentwicklung, einschließlich der ineffizienten Teamentwicklung und der Schwierigkeiten im Management komplexer Systeme. Es wird auf verschiedene Managementansätze eingegangen, wobei der Fokus auf der Notwendigkeit liegt, Unterschiede zwischen einfachen, komplizierten, chaotischen und komplexen Situationen zu erkennen. Dave Snowden's Cynefin-Modell wird als Rahmen vorgestellt, um diese Herausforderungen anzugehen und emergente Praktiken zu erkennen, die in komplexen adaptiven Systemen entscheidend sind.
Weitere ähnliche Inhalte
![Philosophy screws it all up (Pecha Kucha) [Java Forum Stuttgart 2017]](https://cdn.slidesharecdn.com/ss_thumbnails/philosophyscrewsitallup-pechakuchajfs2017-170709191249-thumbnail.jpg?width=640&height=640&fit=bounds)
Surviving Complexity
- 1. Surviving Complexity http://slideshare.net/johannhartmann Dienstag, 24. Juni14 Hallo! Das da ist Rex Kramer, Gefahrensucher aus dem Kentucky Fried Movie. Der Johannes meinte auf einer der letzten Konferenzen zu mir „kannst du nicht mal sowas wie den Talk „Management Brainfucks“ bei uns machen, aber ohne das wort „Fuck“ zu erwähnen. Da habe ich ja gesagt, klar immer, wenn Judith auch da ist sowieso. Ich weiss gute Gesellschaft zu schätzen. Aber das Thema in 25 Minuten - das ist eine Gefahrensucheraufgabe.
- 2. !Consultant „Manager“ Hacker Dienstag, 24. Juni14 Eine Präamble vorweg: ich bin kein Consultant, ich berate nicht und will auch gar nicht beraten. Ich bin Gründer, Geschäftsführer und CTO eines Softwaredienstleisters mit knapp 80 Kollegen, habe in diesem Kontext auch Erfahrungen als Gründer einer Security-Firma und Early-Seed-Investor bei Firmen wie Swoodoo oder Makara. Unternehmer oder, mir persönlich am liebsten, Hacker ist treffender. Ich komme also aus der Realität, auch wenn ein paar der kommenden Slides ein bischen theoretisch sind. Vor ein paar Jahren habe ich einen Workshop auf der Webinale über DevOps mit BDD gemacht :-)
- 3. Die wichtigste Nebenrolle zu JudithsTalk. ManagementDienstag, 24. Juni 14 Judith und ich haben schon aus Versehen Vorträge zusammengehalten, und sind gerne auf den gleichen Themen unterwegs - so auch heute. Netterweise kommen wir immer von unterschiedlichen Seiten bei den gleichen Themen an. So auch heute :-). So ein bischen doppelt ist drin, aber das mache ich ganz schnell :-).
- 4. Die fieseste Branche derWeltDienstag, 24. Juni 14 Wir sind erwiesenermassen die fieseste Branche der Welt.
- 5. 39% in Time, Scope& Budget Dienstag, 24. Juni 14 Schauen wir uns doch mal unsere Branche an - wir ITler liefern, wenn man dem Standish Group Chaos Report trauen darf, nur in 39% der Fälle das, was wir versprochen haben zum richtigen Zeitpunkt, mit den versprochenen Kosten. Das ist mal unglaublich, dass wir damit durchkommen und bislang keiner auf die Idee kam, einfach mal die ganze Branche zu feuern. Ist es bei Euch deutlich besser? Das ist der Lake Wobegon Effekt, 80% aller Leute halten sich für überdurchschnittlich.
- 6. Häufig 20 % Selten oder Nie 50 % Gelegentlich 30 % Dienstag,24. Juni 14 Ebenfalls aus dem Chaos Manifest 2013: Es wird nicht besser wenn man anschaut, was wir da meist verspätet oder nie liefern - die Hälfte aller Features wird selten oder nie genutzt. Es gibt nur 20% Features, die wirklich oft genutzt werden.
- 7. Brooks‘s Law Adding manpower toa late software project makes it later. Dienstag, 24. Juni 14 Jetzt könnte man sagen, wir sind schlicht alle inkompetent. Aber das stimmt nicht, wir sind nur komisch. Wer kennt Brooks‘s Law? Wer glaubt, dass es zutrifft? Auch hier verhält sich Software sehr seltsam. Ich habe 5 Leute, die in 1 Monat 20 Features schaffen. Wenn ich da noch 5 Leute dazustelle, dann schaffen die 10 nur noch 18? Sollte hier nicht zumindest was Dreisatz-ähnliches gelten?
- 8. Wie lange brauchen 100.000Zeilen Code? > 20Personen: 8.9Monate <= 5Personen: 9.1Monate Dienstag, 24. Juni 14 Aus einer Studie von Doug Putnams QSM über mehr als 500 Projekte: Teams mit weniger als 6 Personen brauchen im Mittel nicht nennenswert länger als Teams mit über 20 Personen, um 100.000 Zeilen Code zu erstellen.
- 9. Pair-Programming 1+1 = 3? Dienstag,24. Juni 14 Der Dreisatz geht in der Softwareentwicklung noch weiter kaputt, wenn man sich zum Beispiel Dinge wie Pair Programming anschaut. Das wird durch beliebige Studien unter Labor- wie Realbedingungen belegt, Pair Programming ist produktiver als die Entwicklung von 2 Personen jeweils alleine.
- 10. 50Dienstag, 24. Juni14 Noch seltsamer wird es, wenn man sich die Performance von Teams anschaut - eine einfache Arbeitsgruppe, bei der man nicht Zusammenarbeitet ist zB effektiver als ein Team im entstehen - dafür kann ein sehr gut funktionierendes Team auch Faktor 50 über dem Branchenschnitt ( Borland / Bell Labs) produktiv sein. Es kann aber auch sein, dass man auf Höhe des Pseudoteams bleibt.
- 11. Wie soll manso etwas bitteschön managen?!Dienstag, 24. Juni 14 Wenn man sich diese Dinge anschaut fragt man sich natürlich - wie soll das bitteschön gemanaged werden? Wie soll man damit umgehen?
- 12. Dienstag, 24. Juni14 Das wollte auch diese Firma wissen.
- 13. Dave Snowden Dienstag, 24.Juni 14 Und die hat diesen Menschen beauftragt, das herauszufinden. Er kommt aus Wales und forscht an der Komplexitätstheorie im Bereich Sensemaking. Wie cool ist das bitteschön. Und weil es wirklich dafür sorgt, dass viele Dinge auf einmal Sinn ergeben, geh ich da auch noch mal drauf ein :-).
- 14. Study the actual, not the „official“ managementpractice Dienstag, 24. Juni 14 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.
- 15. Komplex Kompliziert Chaotisch Einfach Verwirrung Dienstag,24. Juni 14 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.
- 16. Einfach Der Zusammenhang zwischen Ursacheund Wirkung ist bekannt, vorhersagbar und wiederholbar. Dienstag, 24. Juni 14 Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine Überraschungen zu erwarten. Hier weiss ich alles, was ich wissen muss.
- 17. Einfach Beispiele: Email schreiben Browser bedienen Esist keine Rückfrage notwendig Dienstag, 24. Juni 14 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.
- 18. Einfach Erkennen Kategorisieren Reagieren Best Practice Dienstag, 24.Juni 14 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.
- 19. Kompliziert Ursache und Wirkungsind über Zeit und Raum getrennt, aber nachvollziehbar und wiederholbar. Dienstag, 24. Juni 14 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 gibt es Dinge, die ich anfangs noch nicht weiss, in die ich erst Gehirnschmalz stecken muss.
- 20. Beispiele: Formulare / Reports Layout Eskann immer wie geplant umgesetzt werden. KompliziertDienstag, 24. Juni 14 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.
- 21. Erkennen Analysieren Reagieren Kompliziert Good Practice Dienstag, 24.Juni 14 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.
- 22. Chaotisch Der Zusammenhang zwischen Ursacheund Wirkung ist nicht erkennbar. Dienstag, 24. Juni 14 In Chaotisch wirds gemein. Es gibt keinen erkennbaren Zusammenhang zwischen Ursache und Wirkung. Man weiss nicht, was kommt, und man weisst dementsprechend auch nicht, wie man sich vorbereiten soll.
- 23. Beispiele: Heisenbugs Hackereinbruch „Hoffentlich bringt dasjetzt was.“ ChaotischDienstag, 24. Juni 14 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.
- 24. Handeln Erkennen Reagieren Chaotisch Novel Practice Dienstag, 24.Juni 14 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.
- 25. Komplex Im Nachhinein istein Zusammenhang zwischen Ursache und Wirkung erkennbar. Es ist nicht vorhersagbar, aber eine Wiederholung kann passieren. Dienstag, 24. Juni 14 Komplex ist gemein. Im Nachhinein kann ich den Zusammenhang zwischen Ursache und Wirkung nachvollziehen. Vorher kann ich die Wirkzusammenhänge nicht sehen, und dementsprechend nicht mit Ihnen planen. Aber ich verstehe sie, während ich im komplexen System agiere.
- 26. Beispiele: Schachspiel Innovative Software ! KleineSoftware Ich weiß noch nicht, was am Ende genau herauskommen wird. KomplexDienstag, 24. Juni 14 Komplexe Tätigkeiten sind unser tägliches Brot in der IT. Das gilt aber auch für die Business- Seite, speziell im Umgang mit Menschen und Märkten.
- 27. Probieren Erkennen Reagieren Komplex Emergente Praktiken ? Dienstag, 24. Juni14 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, nämlich emergente. Emergent heisst: von alleine entstehend, auftauchend oder wachsend. Aber warum ist das so?
- 28. Komplexe Adaptive Systeme Dienstag, 24. Juni14 Das liegt am Verhalten von komplexen Systemen, konkret an komplex adaptiven Systemen. Was ist so ein System?
- 29. Komplex Einfach Einfach Chaotisch Einfach Komplex Kompliziert Dienstag, 24. Juni14 Komplexe Systeme bedeutet, dass ich verschiedene Komponenten habe, die autark agieren. Diese Komponenten können selbst simpel sein, oder komplex. Oder Chaotisch. Wenn ich das jetzt vorhersagen sollte würde ich mir jedes Teil angucken und daraus die Summe ausrechnen.
- 30. Einfach Einfach Chaotisch Einfach Komplex Kompliziert Dienstag, 24. Juni14 Aber genau das kann ich nicht - denn die Elemente selbst sind vernetzt und reagieren aufeinander.
- 31. verstärken dämpfend Einfach Einfach Chaotisch Einfach Komplex Kompliziert Dienstag, 24. Juni14 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 genau auf die Weise entstehen Schmetterlingseffekte, bei denen durch kleinen Ressourcenaufwand erhebliche Wirkung erzielt wird.
- 32. Einfach Einfach Chaotisch Einfach Komplex Kompliziert Dienstag, 24. Juni14 Daneben gibt es auch Einflüsse von aussen, auf die Ebenfalls reagiert wird und die das Verhalten der einzelnen Elemente und des Gesamtsystems beeinflussen. Damit das System auf Ausseneffekte reagieren kann müssen diese gleich schnell oder schneller durchgeführt werden können.
- 33. ! " # $ % & Workflow Engine ORM User Management BusinessObjects E-Commerce-Module Software Web Frontend Dienstag, 24. Juni 14 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.
- 34. Team Scrummaster Product Owner Senior Dev JuniorDev QA User Experience Dienstag, 24. Juni 14 Und natürlich das Team selbst ist zB eins. Es gibt Leute die sich in Kooperation verstärken, es gibt Leute, die sich ausbremsen. Es gibt Momente, in denen es unglaublich gut läuft. Wer trifft die Entscheidungen in einem Team?
- 35. Dienstag, 24. Juni14 Ein klassisches Beispiel für ein Komplexes Adaptives System ist eine Ameisenkolonie. Die einzelne Ameise versteht nicht die ganze Kolonie, und kann auch nicht einordnen, welche Rolle sie im Gesamtsystem spielt. Die Intelligenz findet nicht im Individuum statt, sondern im System - im Verhalten der Gesamten Kolonie - statt.
- 36. Masterplan. Reaktion auf Umgebung Dienstag, 24.Juni 14 Es gibt also keinen Masterplan, über den das ganze System funktioniert - sondern die einzelne Ameise reagiert auf ihre Umgebung, und arbeitet im Sinne von Cynefin simple - erkennen von Quantitäten oder Qualitäten von Sinneseindrücken, dann wird ein einfacher Ablaufplan abgespult. Trotzdem ist die Ameisenkolonie als ganzes im Stande, eine grössere Struktur zu bilden und komplizierte Prozesse am Leben zu erhalten.
- 37. Hierarchie. Selbstorganisation Dienstag, 24. Juni14 Die Organisation entsteht durch die Aktionen, die Reaktionen und die Kooperation von Leuten. Es gibt keine Hierarchie, bei der irgendjemand eine Entscheidung trifft, die dann an andere zur Umsetzung übergeben wird. Weil niemand das Gesamtbild haben kann, kann auch niemand alleine eine gute Entscheidung treffen.
- 38. Schon 10% dynamischeAnteile ergeben ein komplexes System. Dienstag, 24. Juni 14 Gerhard Wohland nennt das in seinen Denkwerkzeugen „Rot“ für dynamische und „Blau“ für steuerbare Prozesse, in Cynefin gesprochen simpel oder kompliziert.
- 39. Komplex Kompliziert Chaotisch Einfach Probieren Erkennen Reagieren Erkennen Analysieren Reagieren Handeln Erkennen Reagieren Erkennen Beurteilen Reagieren Verwirrung Dienstag,24. Juni 14 Schauen wir noch einmal auf das Diagramm von vorhin. Neben den 4 Kategorien gibt es noch eine fünfte - hier schwarz und nämlich Verwirrung. Verwirrung entsteht dann, wenn man die bevorzugten Methoden eines Quadranten benutzt, aber die Realität um einen herum sich anders gestaltet.
- 40. Standardverfahren Standardprozesse Handlungsanweisungen Dokumentation Fixer Baukasten Einfach Best Practice Strategien: Dienstag,24. Juni 14 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.
- 41. Strategien: Kompliziert Wasserfall Detailliertes Pflichtenheft Micromanagement Meilensteinplan Agil zumReporting Feste Ziele Good Practice Dienstag, 24. Juni 14 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.
- 42. •Detaillierter Spielplan •Milestones Tor1 (Minute 20), Tor 2 (Minute 40), Gegentor (Minute 60) •Der Trainer gibt detaillierte Anweisungen •Spieler haben nur Verantwortung für ihren Bereich •Jahresbonus für Ballkontakte und Km Kompliziert Dienstag, 24. Juni 14 Aber nehmen wir mal ein Beispiel aus einer anderen Welt - die gerade aktuell ist, Entschuldigung für das Foto von 2012. Wer glaubt an einem WM-Titel, wenn Deutschland so spielt?
- 43. •Selbstorganisiert •Team! •Adaptiv •Cross-Funktional •Emergente Praktiken: 5-3-2,3-4-3 Komplex Dienstag, 24. Juni 14 Stattdessen verhält sich das Fussballteam fast lehrbuchmässig wie der Umgang mit Komplex- Adaptiven Systemen. Sie sind selbstorganisiert - der Trainer schreit zwar vom Rand, wird aber nur wahrgenommen wenn der Spieler selbst hinguckt. Er analysiert dafür die ganze Zeit den Gegner, die Mitspieler und verfolgt den Ball. Es werden Dinge probiert, nach Instinkt, und Dinge die funktionieren werden wiederholt.
- 44. Warum wollen Manager komplexeAufgaben kompliziert lösen? Dienstag, 24. Juni 14 Wie komplexe Systeme bzw. komplexe-Adaptive-Systeme funktionieren wissen wir eigenlich seit Mitte der achtziger Jahre. Und seit Mitte der neunziger Jahre wissen wir auch, wie das Management von solchen Systemen geht. Trotzdem versuchen wir es immer anders. Warum ist das so?
- 45. Dienstag, 24. Juni14 Gerhard Wohland gibt eine Begründung dafür, und nennt ihn die Taylor-Wanne. Bis zum Anfang des 20. Jahrhunderts konnten wir fabelhaft mit Komplexität umgehen, weil wir handwerklich arbeiteten. Mit der Industrialisierung gab es auf einmal eine andere Erfolgsgeschichte - die Managementseite, die komplizierte Aufgaben übernahm und die ausführende Seite, die simple Aufgaben übernahm. Das war eine Erfolgsgeschichte. Leider hat aber genau bei der IT und später dann mit Netz und Globalisierung bei anderen das Gegenteil eingesetzt - es gibt wieder mehr Komplexität. Aber wir sind noch die alte Erfolgsgeschichte gewöhnt, auch wenn sie heute nicht mehr funktioniert. Unternehmen, die mit Komplexität umgehen können üben genau den Marktdruck aus, die die klassischen Unternehmen erleiden müssen.
- 46. Need for Closure Dienstag, 24.Juni 14 Unser Gehirn möchte nicht mit vagen, unbestimmten und sich ändernden Dingen zu tun haben, wie ein komplexes System sie mitbringt. Es möchte verlässliche Antworten und Lösungen wie simple Systeme mit Best Practices und komplizierte Systeme mit Good Practices erzeugen.
- 47. Kontrollillusion Dienstag, 24. Juni14 Daneben ist unser Gehirn nicht für Komplexität ausgelegt. Unsere Heuristiken wollen etwas anderes. Zum Beispiel die Kontrollillusion: wir glauben Dinge steuern zu können, die faktisch praktisch nur zum kleinsten Teil von uns gesteuert werden. Das gilt nicht nur für Lotto, das gilt auch für Management von IT-Projekten.
- 48. Extrinsic incentive bias Dienstag, 24.Juni 14 Der extrinsic incentive bias zeigt, dass wir zwar bei uns selbst im Regelfall intrinsische Motivationen unterstellen, bei anderen aber denken, dass sie extrinsisch motiviert sind. Dementsprechend vertrauen wir selbstorganisierten Themen nicht so richtig, sondern möchte lieber selbst steuern. Wer hat einen Jahresbonus?
- 49. Bitte kein Komplex! Dienstag, 24.Juni 14 Unser Gehirn möchte also nicht komplex, sondern bevorzugt andere Varianten.
- 50. Surviving ComplexityDienstag, 24. Juni14 Aber wie gehe ich mit Komplexität um? Was sind emergente Praktiken, die häufig funktionieren? Hier gehe ich schnell durch, damit es irgendwie zu schaffen ist.
- 51. Surviving „When we created Scrumwe did not talk about Lean, we talked about complex adaptive systems.“ Jeff Sutherland Dienstag, 24. Juni 14 Tatsächlich kommt zB explizit Scrum aus der Diskussion komplexer Adaptiver Systeme.
- 52. Development Surviving Agile Methoden: Extreme Programming Scrum CrystalClear Feature Driven Development Dienstag, 24. Juni 14 Die agilen Methoden sind emergente Praktiken. Dinge, von denen man durch Erfahrungen und Experimente in der Praxis festgestellt haben, dass sie oft funktionieren.
- 53. Surviving •Funktionieren häufig, nichtimmer •Funktion startet & endet spontan •entstehen durch Praxis •brauchen Feedbackmechanismen Emergente Praktiken Dienstag, 24. Juni 14 Das heisst, dass agile Methoden nicht immer funktionieren müssen. Aber sie funktionieren statistisch häufig. Um festzustellen ob sie bei mir funktionieren muss ich sie ausprobieren. Es kann sein, dass sie funktionieren, es kann sein, dass sie nicht funktionieren. Es kann sein, dass sie spontan aufhören zu funktionieren und später wieder beginnen.
- 54. Surviving DevOps Continuous Deployment Lean Startup Kanban Emergente Praktiken Dienstag,24. Juni 14 Emergente Praktiken gibt es natürlich nicht nur im Development, sondern auch in Produktion, in Produktentwicklung etc. Dort sind sie ebenfalls durch Erfahrung entstanden und sind geblieben, weil sie sich bewährt haben. Sie stammen nicht aus einem theoretischen Modell, sondern aus der Praxis.
- 55. Organisation Surviving Einfach/Kompliziert Komplex Management On-DemandLeadership Gesteuert Selbstorganisiert Zentral Dezentral Budgetiert Marktgesteuert Positionen Rollen Regeln Kultur Matrix Gilden/Communities Organigramm Netzwerk Dienstag, 24. Juni 14 Das endet aber nicht bei der Softwareentwicklung. Für praktisch jeden Aufgabenbereich im Unternehmen gibt es Methoden, die für komplexe und damit auch sich dynamisch wandelnde Aufgaben taugen.
- 56. Organisation Dienstag, 24. Juni14 Hier habe ich mal ein Beispiel aus Betacodex, bei dem keine klassische Hierarchie mehr existiert, und die Zentrale eine ganz andere Rolle hat - nämlich Services und Synergieeffekte auf Wunsch der äusseren Organisationseinheiten zu liefern.
- 57. Holacracy „no job titles,no managers, no hierarchy“ Dienstag, 24. Juni 14 Das klingt auf den ersten Blick sehr weitreichend, passiert aber - einer der bekanntesten Fälle ist Zappos. Getitelt wurde das mit
- 58. Development OperationsProduktentwicklung Marktdruck Management Organisation Agile KaskadeDienstag,24. Juni 14 Und so sieht das konkret aus, wenn der Markt mehr Dynamik fodert: Weil die Produktentwicklung zu langsam für den Markt ist, muss sie flexibel werden und landet im agilen. Wenn es dort funktioniert bleibt man an den Operations hängen, die noch Freezes und monatliche Releases fahren, und dort wird Continuous Deployment und DevOps eingeführt. Sobald der Kanal zum Kunden steht stimmt Qualität und Quantität in der Produktentwicklung nicht mehr, und auch dort wechselt man zu kundennahen, dynamischen Verfahren. Auf dieser Strecke, beginnend mit IT, stört klassisches Management als Querschnittsfunktion zunehmend, und hier werden Themen wie Servant Leadership, Management 3.0 etc diskutiert. Und am Ende dreht sich die komplette Organisation zu einer dezentralen, marktgesteuerten und dynamischen.
- 59. •Agil, DevOps etckonsequent •Teams wählen Teamstellvertreter •Operations:Backlog über DevOps-Gilde •Servant Leadership über Visual Kanban •Quartalsweise Bewertung der Management-Runde •Emergente Entscheidungsverfahren •Unternehmensretrospektiven •Openspace, Slacktime, ... Eigene Erfahrungen Dienstag, 24. Juni 14 Es gibt eine Reihe von Sachen, die wir schon machen und die gut funktionieren.
- 60. Hingehen: http://intrinsify.me/ http://stoosnetwork.org/ Management 3.0, AgileManagement Innovations, Holacracy Lesen: Nils Pflaeging: „Organisation für Komplexität.“ Steve Denning: „Radical Management“ Jurgen Apello: „Management 3.0“ Gerhard Wohland: „Denkwerkzeuge für Höchstleister“ Dienstag, 24. Juni 14
- 61. Danke! Surviving Fragen -> hartmann@mayflower.de GuteFragen -> @johannhartmann Dienstag, 24. Juni 14
- 62.
- 63. Einfach Kom pli ziert Komplex Chaotisch Close to CertaintyFar from Certainty Farfrom Agreement Closeto Agreement Wie planbar ist die Umsetzung? Wie sicher ist meine Anforderung? Dienstag, 24. Juni 14 Wie finde ich heraus, ob mein Problem komplex ist?
- 64. Einfach Kom pli ziert Komplex Chaotisch Close to Certainty Far from Certainty Farfrom Agreement Closeto Agreement Dienstag,24. Juni 14 Die Stacey-Matrix gibt einem die Möglichkeit, die Aufgaben einzuordnen - und zwar nicht nur in die Quadranten aus Cynefin, sondern auch Klassifiziert nach Vorhersehbarkeit und Einigkeit über die Ausführung. Agreement ist die Einigkeit über die Anforderungen, die das System leisten muss, die Certainty ist die technische Umsetzbarkeit.
- 65. Anforderungen Surviving Produktvision Personas User Stories Product Owner SprintReviews / Backlog Grooming Dienstag, 24. Juni 14 Agiles Anforderungsmanagement hat ein anderes Ziel: es geht nicht darum etwas bestimmtest zu implementieren, sondern das zum Zeitpunkt der implementierung bekannte wertvollste. Um das herausfinden zu können braucht man ein gemeinsames Bild vom Produkt und der Wertschöpfung dahinter - und dazu dienen diese Tools.
- 66. Surviving Continuous Integration Continuous Deployment ReleaseBurndown Variabler Scope Releasemanagement Dienstag, 24. Juni 14 Im Komplexen ist Releasemanagement nicht plangetrieben, sondern vor allem empirisch - man versucht also auf dem Weg Daten zu erzeugen und zu sammeln, die möglichst wertvoll sind - und mit diesen kontinuierlich neu zu planen.
- 67. Surviving Architektur Walking Skeleton Emergente Architektur AgileModeling Architectural Spikes Dienstag, 24. Juni 14 Architektur in komplexen Systemen ist ebenfalls empirie- und kooperationsgetrieben.
- 68. Surviving Staffing T-Shaped Personen Teamverantwortung Cross-Functional Teams EmergenteRollen !Titel & Positionen Dienstag, 24. Juni 14 Selbstorganisierte Teams, kollektive Intelligenz und schnelles Lernen stellt auch Anforderungen an das Staffing. Es gibt keine fixierten Positionen und Titel, keine Hierarchien. Aufgaben werden gemeinsam von einem crossfunktionalien Team bearbeitet, das sich selbst organisiert. Es gibt keine individuelle Accountability.
- 69. Surviving Entscheidungen Teamentscheidungen/Konsent Emergente Entscheidungen Jede Entscheidungauf Widerruf Dienstag, 24. Juni 14 Das hat auch folgen auf die Entscheidungsfindung. Individuelle Spezialistenentscheidungen sind gut in komplizierten Umgebungen, Standards in einfachen Umgebungen. Komplexe Umgebungen brauchen möglichst viel Intelligenz bzw. Impact-bewertung, deshalb sind sie nicht individuell, sondern werden gemeinsam gefunden - das heisst aber nicht demokratisch, sondern eben Konsent, Decider, Decision Matrix etc.
- 70. Surviving Management !Entscheidungen Servant Leadership Stewardship Bossless Teams Adaptiv! strategisch Inspiration Dienstag, 24. Juni 14 Das Management dreht sich ebenfalls deutlich. In komplexen Umgebungen ist eine hierarchische Entscheidung der Versuch, sie am Punkt der maximalen Inkompetenz zu treffen. Statt dessen muss hier Leadership passieren, sprich: die Teams selbst müssen in die Lage versetzt werden, gute Entscheidungen zu treffen und gut zu arbeiten. Und das gibt ganz neue Aufgaben.
- 71. Surviving Organisation Querschnittteams Autonomie = Transparenz= Verantwortung !Bonus Dienstag, 24. Juni 14