Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agile Coach zu werden ist nicht schwer... - mit Notizen

Gerrit Beine
December 02, 2015

Agile Coach zu werden ist nicht schwer... - mit Notizen

Eine Fundamentalkritik am agilen Coaching

#agile #cc-by #from-slideshare
https://www.slideshare.net/gerritbeine/agile-coach-zu-werden-ist-nicht-schwer-mit-notizen

Gerrit Beine

December 02, 2015
Tweet

More Decks by Gerrit Beine

Other Decks in Business

Transcript

  1. 1

  2. Die letzten Jahre waren für Agile Methoden sehr erfolgreich, sehr

    leicht. Nun bekommt die Agilität das gleiche Problem, das die Banken vor ein paar Jahren hatten: Es gibt haufenweise Coaches, die ihrer eigenen Wahrnehmung nach sehr erfolgreich waren, weil das gesamte System richtig gut gelaufen ist. Sie hatten nie Gelegenheit, ihre Methoden zu reflektieren oder in andere Kontexte zu übertragen. Sie haben auch keine Chance dazu, weil sie in der Regel in Organisationen unterwegs sind, ihnen keine Reibungsfläche bieten. Solche agilen Coaches verhalten sich #schwarmdumm. Ich nennen solche Coaches Sunshine Coaches. 3
  3. Solche Sunshine Coaches verfechten ihre Methode als die ultimative. Kämpfen

    z.B. gegen Job-Titel. Warum machen die das? Letztens erlebte ich eine Diskussion um die Frage, ob es Junior ScrumMaster geben darf. Da kann man drüber diskutieren. Oder man kann es einfach ok finden ohne es gleich zu adaptieren. Wem das nützt, der soll doch einen Junior ScrumMaster haben. Bei adesso haben wir dieses Jahr ein Trainee-Programm für agile Methoden gestartet. Mal gucken, was daraus wird. Ich hoffe, Junior ScrumMaster und Junior ProductOwner, die dann großartige Scrum Master und ProductOwner werden. Aber bis dahin sind sie Juniors. Für mich heißt das, dass das Kollegen sind, denen ich in größerem Ausmaß mit Rat und Tat zur Seite stehe – eben um sie großartig zu machen. 4
  4. Das Problem ist, wenn man sowas abschafft und dabei sich

    selbst belügt. Warum nennt sich der ehemalige CHRO (Chief Human Resources Officer) jetzt CMO (Chief Motivation Officer) und nicht einfach nur Motivation Officer? Weil er der Häuptling ist, bleiben will und bleiben wird. Alles andere ist Quatsch und nicht Teil des Problems. Wer glaubt, durch das Abschaffen von Job-Titeln Neid zu eliminieren, folgt einer Vogel-Strauß-Taktik und glaubt auch, dass Zitronenfalter Zitronen falten. Wenn Neid zwischen Kollegen in einer Organisation auftritt, hat man ein ganz anderes Problem als Job-Titel. Es gibt Organisationen, die schaffen Job-Titel ab und funktionieren super. Es gibt Organisationen, die behalten ihre Job-Titel und funktionieren genauso super. Und es gibt Organisationen, die schaffen Job-Titel ab, denken sich Fantasie-Titel aus und schaffen es, sich grandios selbst zu belügen. 5
  5. Coaches, die mit so einfachen Rezepten kommen, machen dann Überraschungsei-

    Consulting. Es klingt gut. Die Hülle schmeckt lecker. Und wenn man sieht, was dabei rauskommt, ist man deprimiert. 6
  6. Das gleiche gilt übrigens auch für Hierarchien. Wo immer Menschen

    in Gruppen zusammenkommen, entstehen Hierarchien. Sie zu bekämpfen ist ebenso falsch wie sinnlos. Die Frage, der wir uns stellen müssen ist eine ganz andere: Ist die Hierarchie die wir haben funktional oder dysfunktional? Das ist bei einer expliziten Hierarchie im Übrigen um ein Vielfaches leichter als bei einer Schattenhierarchie. 7
  7. Ich glaube, das hat viel mit Selbstverständnis zu tun. Ich

    kenne viele Agile Coaches, die die Welt retten müssen. Ja, müssen. Glauben sie. Dabei müssten sie nur tun, was sie vielen Managern predigen: Loslassen. Wenn sie ihre verbissenes Bild von Agilität loslassen, dann haben sie die Chance, wirksam zu werden. Es gibt aber noch eine andere Gruppe und deren Selbstverständnis ist gefährlich. Das sind die, die glauben, dass sie die Welt retten können. Weil sie den Stein der Weisen gefunden haben. Ich nenne die Agile Quaida. Wobei das unfair ist, mit Terroristen kann man verhandeln. 8
  8. Ich möchte mit einem Beispiel einsteigen, das ein typisches Muster

    vieler Konflikte von Agile Quaidazeigt. Einstmals unterhielt ich mich mit einem Agile Coach auf einer Konferenz über das Thema Schätzen. Er war No Estimates-Verfechter und erklärte, dass User Stories nur funktionieren, wenn sie alle die Größe 1 haben. Ich meinte, dass das Blödsinn sei. Seine Antwort: Deine Meinung ist mir zu absolut. Da ist man dann erstmal sprachlos. Psychologen nennen das, was meinem Diskussionspartner passierte Kognitive Dissonanz. 9
  9. Kognitive Dissonanz erklärtsich relativ einfach anhand dessen, was wir wahrnehmen

    können. Wir laufen ja alle mit einem Bild der Wirklichkeit in Kopf durchs Leben und manchmal passt das halt nicht zusammen mit dem was wir wahrnehmen. Dann ist die Wirklichkeit eben kaputt. Nicht unser Bild der Wirklichkeit. Das ist ein großes Problem, wenn wir als Coaches unterwegs sind. Keines, das wir wirklich lösen können, aber eines dessen wir uns bewusst sein müssen. Es gibt keine ultimativen Lösungen und keine absoluten Aussagen, so lange es um Themen wie Agilität geht. Es gibt Muster, die in bestimmten Kontexten funktionieren –und in anderen eben nicht. Das was wir als Agile Coaches leisten müssen, ist solche Muster zu erkennen, zu beschreiben und zu transportieren. Und zu erkennen ob und wie sie in unserem Kontext wirken. Weil wir grade bei kognitiver Dissonanz sind... 10
  10. Hat jemand dieses Buch gelesen? Ich habe mir das mal

    angetan. Abgesehen davon, dass schon im Untertitel ein Kommafehler ist, hat dieses Buch wenig mit Agilität zu tun. Der Autor hat Agilität weder verstanden, noch dazu recherchiert. Alle systematischen Fehler der Beweisführung, die der den Agilisten vorwirft, macht er selbst. Fazit zum Inhalt: nicht vorhanden. Aber dieses Buch ist wichtig. Es ist das vielleicht wichtigste Buch, das jemals über Agilität geschrieben wurde. Weil es etwas zum Ausdruck bringt, das in der Agilen Welt gerne ignoriert wird: Angst! Angst vor Veränderung, Angst vor der Zukunft, Angst vor der Angst an sich. Wer bei diesem Buch zwischen den Zeilen liest, sieht die nackte, kalte Angst vor einer Welt, die zu komplex ist, um sie mit den alten, bekannten Mitteln zu beherrschen. Dieses Buch ist die panische Angst vor einer Welt, die wir nicht verstehen. 11
  11. Ich komme nun zum Thema Steampunk Management. Kenntjemand Steampunk? Steampunk

    ist cool. Es begann mal als Literaturgattung, eine Art Science Fiction im viktorianischen Zeitalter. Man hat dort dampfmaschinengetriebene Fahrzeuge, Computer und sogar iPhones. Alles mit Dampfmaschinen. Deshalb heißt das Steampunk. Mittlerweile hat das sogar Einfluss auf‘sReal Life genommen. Leute laufen in Steampunk-Kostümen durch die Gegend. Das Ganze geht einher mit einer starken Glorifizierung der viktorianischen Zeit. Mein Fall ist das nicht, man denke nur mal an die Zahnhygiene damals, aber was soll‘s. Wem‘sgefällt. Was ist jetzt das Problem damit? 12
  12. Das ist Science Fiction im Jahre 1987. Eleganz, Stolz, Hochtechnisierung...

    Genauso stellen sich viele Agile Coaches Agilität vor. So sauber, schnell und elegant soll die perfekte agile Organisation sein, in der wir arbeiten wollen. 13
  13. Die Realität schaut leider etwas anders aus. Irgendwie nicht so

    traumhaft. Es gibt viel zu tun, und am Ende bekommt man trotzdem nur eine Steampunk-Version dessen, was man erreichen wollte. Aber warum ist das so? Warum ackern sich Agile Coaches in den Burnout und warum funktioniert Agilität nicht? Warum ist das, was alles leichter macht, so schwer? 14
  14. Steampunk Managamentist schlimmer als Taylorismus. Wenn ich auf eine 21-Jahrhundert-Organisation

    Taylorismus anwende, dann klappt die einfach zusammen. Die ist nicht mehr lebensfähig. Steampunk Management macht viel schlimmeres mit Organisationen.... Ich versuche das mal zu erklären. 15
  15. Das ist der Old Taxi Park in Kampala,Uganda. Ein komplexes

    adaptives System. Es funktioniert imPrinzip nach den gleichen Mechanismen wie ein Softwareprojekt. Wenn ein Steampunk Manager ein komplexes System betrachtet, dann sieht er nicht das Bild, das wir gerade sehen. 16
  16. Ein Steampunk Manager sieht so etwas. Ein lineares System, wie

    z.B. eine Dampfmaschine. Es gibt einen Regler, an dem man dreht und dann passiert das Richtige. Wenn wir jetzt einen Steampunk Manager auf ein komplexes adaptives System loslassen, dann passiert folgendes... 17
  17. Das Scaled Agile Framework ist so ein Steampunk-Management-Tool. Es verkauft

    sich wie warme Semmeln, hat aber mit Agilität nicht viel zu tun. Und genau deshalb wird SAFewird gerne gebashed. Weil es nicht agil ist. Sehe ich auch so. Aber ich finde SAFegenial. Wer erlebt gerade einen Moment kognitiver Dissonanz? Leffingwell hat uns – neben einer schier endlosen Anzahl von Big Pictures für alle Modelle skalierter Agilität – ein Framework gegeben, in dem sich eine klassische Organisation wiederfindet. SAFeist kein Zielbild, da widerspreche ich Leffingwells Gefolgsleuten aufs Schärfste. SAFeist ein Weg zu einem Ziel, das wir nicht darstellen können. Und SAFeholt alle die ab, die Angst haben. Es gibt Sicherheit, Orientierung. Manchmal zu viel, aber das ist OK. SAFeist der Anfang einer langen Reise. 18
  18. SAFehilft uns Brücken zu bauen für Organisationen, die aus den

    verschiedensten Gründen nicht gleich die perfekte agile Organisation werden können. Das ist manchmal nervend, aber so ist die Welt. Bis die Natur den Menschen hervorgebracht hat, sind ein paar hundert Millionen Jahre vergangen. Manche Dinge brauchen eben Zeit. Und Brücken wie das SAFe. 19
  19. Wir müssen lernen, Dinge wie SAFeals Brücken zu begreifen, die

    wir bauen können. Als Beispiel für das Bauen von Brücken eine kleine Anekdote: Mir ist das selbst vor ein paar Jahren passiert, als ich in einem Projekt mit einem ScrumTeam gearbeitet habe, in dem ein Architekt war, der die Function Point Methode geliebt hat. Er meinte, dass eine Schätzmethode mit weniger als zwei Nachkommastellen nichts taugt, weil sie nicht präzise genug sei. PlanningPoker war nicht so sein Ding. Ich habe am Anfang nicht kapiert, was sein Problem ist. Dabei war es ganz einfach Es gibt keine objektive Realität, sein mentales Modell war anders als meines. Also habe ich in einer der lange, dunkeln Winternächte, die ich als Consultant in eiskalten, unbeheizten Hotelzimmern verbringen durfte etwas Geniales erdacht... 20
  20. ...ein Präzisions-Planning-Poker-Set. Damit bin ich dann zu dem Team gegangen

    und alles war ok. Nach einem Sprint kam der Mensch mir plötzlich im Gang entgegen, das Gesicht zur Faust geballt. Er war zwei Köpfe größer als ich und hatte dreimal so dicke Oberarme. Ich dachte schon: Jetzt ist‘s aus. Da grinst der mich an und sagt: Du Fuchs. Danach war alles gut. Das Placebo hatte gewirkt. Ich lebe noch. Nebenbei: Ein Tipp am Rande. Wenn man das Präzisions-Set mit Pi/4 statt PI beginnen lässt, dauert es wesentlich länger, bis die Leute bemerken, was man da eigentlich treibt. 21
  21. Wir haben natürlich die Erfahrung, das PlanningPoker funktioniert. Aber Erfahrung

    ist nicht vermittelbar. Sie muss erlebt, gesammelt, gemacht werden. Und manchmal werden die falschen Erfahrungen gemacht. Die prägen dann. Das ist lästig, vor allem, wenn man sie Menschen abtrainieren muss. 22
  22. An dieser Stelle sind wir Agile Coaches extrem gefährdet, uns

    schwarmdumm zu verhalten. Wir kommen zu oft mit unserem mentalen Modell, das notwendigerweise begrenzt ist mehr Schaden anrichten, als wir richtig machen. 23
  23. Hier hat Bertrand Meyer mit seinem schrecklichen Buch sogar recht.

    Ich erlebe es häufig, dass selbsternannte Agile Coaches unreflektiert Lösungen für ein singuläres Problem in einem definierten Kontext zur ultimativen Wahrheit erheben. Dann passiert das, was Gunter Dueck auf der linken Seite dieses Diagramms dargestellt hat. Es gibt eine dumm-einfache Lösung für ein komplexes Problem. Auch dazu wieder ein Beispiel.... 24
  24. Das ist Little‘s Law. Es wurde 1961 im Rahmen der

    QueueingTheory mathematisch bewiesen und bildet die Grundlage von Lean. Die Aussage lautet: Die Wartezeit von Elementen L in einem System ist gleich dem Produkt ihrer durchschnittlichen Ankunftsrate ƛ und ihrer Verweildauer W. 25
  25. Ein genialer Coach hat die Formel erweitert. Um skalieren zu

    können und zu berechnen, wie viele Mitarbeiter für die Beschleunigung eines Projektes notwendig sind. Was er nicht bedacht hat... 26
  26. ...solche Ideen hatten schon ganz andere. Und dass das nicht

    funktioniert, wurde auch schon erkannt. Naja, so ist das manchmal im Leben. 27
  27. Es gibt einigefundamentale Voraussetzungen für die Anwendbarkeit von Little‘sLaw. Z.B.

    ein stabiles System. Das ist gerade ein System, das nicht beliebig erweitert wird. Vor allem wird es nicht durch simple Multiplikation erweitert. 28
  28. Das Problem ist: nichts skaliert proportional. Auch nicht mit Little‘s

    Law. Ein Elefant ist nicht einfach eine große Maus. Die Suche nach dem perfekten Framework führt nirgendwohin. Würde man eine Maus auf die größeeines Elefanten skalieren, würde sie sterben. Große Systeme funktionieren anders als kleine Systeme. Aber wenn man Little‘s Law erweitert, hat man natürlich den Stein der Weisen gefunden.... 29
  29. Meine Botschaft an Euch ist: Entspannteuch. Agilität ist nicht verkrampft.

    Agilität steht ganz am Anfang. Agilität 2015 ist nicht, was Agilität 2001 war. Und Agilität 2025 wird nicht sein, was Agilität 2015 ist. Baut Brücken. Hört auf Lösungen zur propagieren,sondern sucht Muster in den Problemen. Begreift die Welt als komplexes System und hört auf für Agilität zu kämpfen. Nehmt die Entropie hin, akzeptiert sie als den natürlichen Zustand des Universums und helft dabei, mit ihr umzugehen. Entspannt euch. 30
  30. Zum Abschluss noch ein Zitat aus einem brillianten TED Talk

    von Dan Gilbert. Was Dan Gilbert sagt, trifft auch auf uns Agile Coaches zu. Wir sind nicht fertig. Wir sind alle Work-in-Progress. Aber unser Job ist es, die Veränderung der Welt, für alle die, die Werte schaffen sollen, leicht zu machen. 31
  31. 32