Slide 1

Slide 1 text

1

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

...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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

...solche Ideen hatten schon ganz andere. Und dass das nicht funktioniert, wurde auch schon erkannt. Naja, so ist das manchmal im Leben. 27

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

32