In dieser Session wird mit verbreiteten Irrtümern, falschen Versprechen und falsch verstandenen Philosophien aufgeräumt. Es geht um die freie Zeit, die ein ScrumMaster hat. Um den Unterschied zwischen Agilität und inkrementellem Arbeiten. Es geht um feste Preise und Termine. Darum, was Velocity wirklich bedeutet. Warum Aufwand eine Rolle spielt und wer mit wem darüber reden darf. Es geht um glückliche Entwickler, Kunden und Manager. Glückliche Manager, die skalieren. Und wozu man Manager benötigt. Es geht um Kultur. Darum, was geschätzt wird und warum KPIs Projekte töten. Es geht um Business Value und warum Agilität gerade erst anfängt.

1. 1

2. Ich mache das mit den agilen Sachen seit 2001.
Und seitdem habe ich eine Geste besonders verinnerlicht.
Ihr könnt die gerne mal mit mir gemeinsam zelebrieren.
Brillenträge: Bitte vorher die Brille abnehmen, sonst besteht Verletzungsgefahr.
Und nun alle zusammen.
Irgendwie befreiend, oder?
Nun die Herausforderung: Wann immer ihr während des folgenden Vortrags den Impuls verspürt, diese Geste auszuführen – unterdrückt sie.
Damit habt ihr dann schon den ersten Schritt zur Qualifikation zum Agile Coach getan.
Mir sind in all den Jahren drei Gruppen von Menschen begegnet:
Pragmatiker, die Agilität als Idee betrachten, die Software-Entwicklung leichter machen kann.
Die Kollegen von Agil Quaida, die das Management abschaffen wollen und für die jede betriebswirtschaftliche Betrachtung ein Sakrileg ist.
Und die Steampunker. Über die erzähle ich nachher noch ausführlich.
2

3. Das ist der Old Taxi Park in Kampala, Uganda.
Ich hatte das große Glück dort 2007 als Entwicklungshelfer sein zu dürfen.
Im Old Taxi Park habe ich gelernt, warum Agilität funktioniert.
Wenn ich nach Mbale möchte, gehe ich zum Old Taxi Park, suche ein passendes Matatu (das sind die weißen Busse) und handle mit dem Fahrer einen Preis aus.
Irgendwann geht es dann los.
Und kurioserweise schaffen es die Fahrer ihre Matatus aus diesem Gewirr heraus zu manövrieren.
Wie die das machen, ist für Außenstehende nicht einsehbar.
Aber es funktioniert.
Ein so komplexes System funktioniert vollständig selbstorganisiert.
Nein, es ist kein Wunder.
Warum funktioniert es dann?
Weil es einfache Regeln gibt und alle Vertrauen in diese Regeln haben.
Ich vertraue dem Fahrer, der Fahrer vertraut den anderen Fahrern und alle anderen Fahrer vertrauen meinem Fahrer.
Und das reicht aus, um dafür zu sorgen, dass dieses System funktioniert.
3

4. Weil wir grade beim Thema Vertrauen sind:
Eine Rolle, die im wesentlichen auf Vertrauen basiert, ist der Product Owner.
Es ist gleichzeitig die am meisten fehlbesetzte Rolle in Organisationen, die gerne agil sein wollen.
Solche Organisationen besetzen die Position des Product Owners mit Requirements Engineers, Business Analysten oder Projekt Managern...
4

5. ...und erhalten Product Engineers, Product Analysts und Product Manager.
Die Rolle heißt aber weder Product Engineers noch Product Analysts noch Product Manager.
Und das ist Absicht.
5

6. Die Rolle heißt Product Owner.
Und hierbei ist Owner das starke Wort.
Ein Product Owner lebt für sein Projekt, er steht für den ökonomischen und fachlichen Erfolg des Projektes.
Ein guter Product Owner unterschreibt für sein Projekt mit seinem Blut.
(Ok, das ist vielleicht etwas übertrieben, aber die Übertreibung macht‘s deutlich.)
6

7. Für Product Owner gilt das Highlander Prinzip:
Es kann nur einen geben.
Auch in skalierten Umgebungen gibt es einen Product Owner und nicht mehrere.
Er kann Assistenten haben, aber der Product Owner ist immer nur einer.
Der Unterschied zwischen Highlandern und Product Ownern ist übrigens folgender:
Wenn es bei den Highlandern nur noch einen gibt, sind alle anderen kopflos.
Bei den Product Ownern ist‘s genau umgedreht: Da ist das Projekt kopflos, wenn es mehr als einen gibt.
7

8. Die Frage nach mehr als einem Product Owner bringt mich direkt zum ersten Brainfuck.
Immer wieder begegnet mir die Frage, ob es in einem agilen Projekt einen Projektleiter geben darf.
Die Kollegen von Agil Quaida schreien nun immer: Nein, das wäre Anbiedern ans Management.
Ich sehe das pragmatischer: Natürlich darf es einen Projektleiter geben.
Der Product Owner hat die Hoheit über das Budget und wenn er Unterstützung in der Projektführung benötigt, kann er sich selbstverständlich einen Projektleiter als Assistenten holen.
8

9. Im Kontext der Projektleiter-Diskussion gibt es auch immer wieder Diskussionen um Festpreisprojekte.
Der Brainfuck, dass Agilität und Festpreise nicht zusammenpassen, ist weit verbreitet.
Ich halte ihn für ziemlichen Blödsinn.
9

10. Feste Preise sind hervorragend mit Agilität kompatibel.
Das Problem in Deutschland ist nur, dass wir, wenn wir von festen Preisen reden, etwas anderes meinen.
Nämlich feste Scopes.
Das ist schlecht.
Warum, wird gleich deutlich.
10

11. Gleich neben den festen Preisen stehen feste Termine.
Der Brainfuck, dass Terminzusagen mit Agilität nicht kompatibel sind, kommt interessanterweise hauptsächlich aus unterfahrenen Teams.
Aber auch das ist falsch.
11

12. Feste Termine passen ganz hervorragend zu Agilität.
Agile Teams liefern beständig und kontinuierlich.
Es ist überhaupt kein Problem zu einem festen Termin zu liefern.
Was nicht geht, ist exakt zu bestimmen, was zu einem definierten Termin geliefert wird.
Das ist immer Kaffeesatzleserei.
12

13. Projezieren wir das mal auf das magische Dreieck des Projektmanagements.
Das kennt ihr sicherlich alle: Budget, Termin und Scope.
In agilen Projekten machen wir üblicherweise zwei Dinge fest:
Das Budget und den Termin.
Was flexibel ist, ist der Scope.
Und hier liegt unser Problem in Deutschland.
Wir denken, wenn wir den Scope vorab festzurren, stehen Budget und Termin automatisch auch fest.
Aber...
13

14. ...wie wir schon aus der New School of IT gelernt haben, sind wir gar nicht in der Lage den Scope vorab wirklich zu definieren.
Es geht einfach nicht. Das wissen wir seit mindestens 20 Jahren.
(Wer Boehm gelesen hat, weiß es seit 1981, aber den liest heute kaum noch jemand ;-)
14

15. Softwareprojekte sind komplexe Systeme, agile Projekte also auch.
Das bedeutet, damit sie funktionieren, bedarf es Vertrauen.
Wie im Old Taxi Park.
Bezogen auf das magische Dreieck des Projektmanagements kann man also folgendes sagen:
15

16. Ich weiß, was es mich kostet und wann ich es habe.
Und ich weiß, dass es das Beste sein wird, was unter diesen Rahmenbedingungen realisiert werden kann.
Mehr geht nicht.
Auch nicht mit noch mehr Analyse, Konzeption und dem ganzen Kram.
Ich muss so einem Team auch mal vertrauen.
16

17. Wenn der Product Owner die am meisten fehlbesetzte Rolle in der agilen Welt ist, dann ist der Scrum Master die am meisten falsch verstandene Rolle.
Dabei ist es relativ egal, ob man die Rolle Agile Coach, Agile Master oder Kanban Evangelist nennt.
Der Typ Mensch ist immer der gleiche.
Vor kurzem kam ein Scrum Master bei einem Kunden zu mir und meinte: „Mein Chef hat mich gefragt, was ich als Scrum Master den ganzen Tag mache.“
Ich: „Ja, und?“
Er: „Naja, was sage ich ihm?“
So eine Frage, wie sie der Chef da stellt, ist natürlich selten dämlich.
Mit sowas kann man Unternehmen ganz hervorragend kaputtkontrollieren.
Ich meinte also zu dem Scrum Master: „Sag ihm: das gleiche wie Du.“
17

18. Aber, wenn ich ehrlich bin, dann ist die Frage, was so ein Scrum Master den ganzen Tag macht, schon interessant.
Um diese Frage zu beantworten, muss man erst mal schauen, welche Fähigkeiten ein Scrum Master eigentlich hat.
18

19. Den Impediment Resolver kennen sicherlich alle.
Kaum gibt‘s ein Impediment, räumt er es aus dem Weg.
Ein Klassiker.
19

20. Das andere Ende der Fähigkeiten ist Empathie.
Ein guter Scrum Master räumt nicht nur aus dem Weg, er kann sich in andere Menschen hineinfühlen.
Ein Scrum Master fühlt, wie es seinem Team geht, wenn er morgens das Bürogebäude betritt.
Ein Scrum Master schmeckt, wie es einem Projekt geht und wann er handeln muss.
20

21. Scrum Master haben die Fähigkeit, andere Perspektiven einzunehmen.
Sie sehen Dinge, die andere nicht sehen, z.B. das Team oder Product Owner und halten ihnen einen Spiegel vor.
21

22. Scrum Master erkennen Zusammenhänge, logische, soziale und alle anderen auch. Und sie können sie darstellen, erklären und Handlungsoptionen aufzeigen.
22

23. Manchmal ist ein Scrum Master auch so eine Art Landarzt.
Die Kunst zu erkennen, ob ein Team oder eine Organisation gerade eine Chemo-Therapie benötigt oder ob Placebo reichen, gehört zum Handwerk jedes guten Scrum Masters.
23

24. Ganz wichtig für Scrum Master:
Schon bevor die neue Abteilungsleiterin ihren ersten Arbeitstag hat, weiß er, wie viel Stück Zucker sie im Kaffee am liebsten hat.
Scrum Master haben Charme und erreichen damit eine ganze Menge für ihre Projekte.
24

25. Und das allerwichtigste:
Scrum Master sind gnadenlos im Verhandeln.
Für ihr Team, für ihr Projekt, für ihre Organisation.
(Für den Profit ;-)
Zu diesem Bild noch ein Hinweis an alle, die hin und wieder Vorstellungsgespräche mit Kandidaten für Scrum Master führen.
Das Bild ausdrucken und über den Tisch schieben.
Danach die Frage stellen: Können Sie sich mit diesem netten Herrn identifizieren?
Die Reaktionen darauf sind total spannend.
Egal wie die Reaktion ausfällt, man weiß, ob der Kandidat ein Scrum Master sein kann oder nicht.
25

26. Das waren die aus meiner Sicht sieben wichtigsten Fähigkeiten, über die ein Scrum Master verfügen sollte.
Es gibt sicherlich noch andere mehr, aber mit diesen sind meine Scrum Master bisher sehr weit gekommen.
Neben all den Dingen, die ein Scrum Master können muss, gibt es aber auch ein paar wesentliche Dinge, die er nicht können muss.
Dazu gehört, ich hoffe, ihr seht es mir nach...
26

27. ...Programmieren.
Tatsächlich ist das keine entscheidende Fähigkeit für einen Scrum Master.
Interessanterweise wählen aber viele Organisationen ihre Scrum Master genau danach aus.
Das liegt daran, dass die Rolle Scrum Master oft nicht verstanden wurde.
27

28. Und das führt dann zu Stellenanzeigen, bei denen man gar nicht genug Hände hat, so oft möchte man sich an den Kopf greifen.
Aktuell gibt es übrigens einen Trend zu Scrum Master / Testmanager.
Als seriöse Fachzeitschrift würde ich mich ja weigern, solche Stellenanzeigen zu drucken.
Aber in dem Segment funktioniert die Pressefreiheit nach wie vor ganz hervorragend.
28

29. Zurück zum Thema:
Nach der Auflistung der Fähigkeiten eines Scrum Masters steht immer noch die Frage, was er denn nun den ganzen Tag macht.
29

30. Dazu müssen wir uns auf einen Exkursion begeben.
Nach Hanoi.
Legenden erzählen, dass es vor vielen Jahren in Hanoi eine Rattenplage gab.
Der damalige Chef von Hanoi verkündete, dass jeder, der ihm eine tote Ratte brachte, dafür Geld bekommen sollte.
Natürlich wurde er von toten Ratten überhäuft.
Blöderweise änderte das nichts an der Anzahl der lebenden Ratten.
Die Leute züchteten einfach Ratten, um sie zu töten.
Dieses Beispiel wird gerne zitiert, wenn es um falsche Incentivierungsmodelle geht.
Das ist aber falsch.
Diese Geschichte ist ein hervorragendes Beispiel für miserable KPIs.
Der Key Performance Indicator war in diesem Fall die Anzahl der toten Ratten.
Nur steht die Anzahl der toten Ratten eben nicht unbedingt in Bezug zur Anzahl der lebenden Ratten.
Das hatte man damals übersehen.
Was lernen wir daraus?
Folgendes: Wann immer man einen KPI definiert, werden Menschen einen Weg finden, den KPI zu erfüllen, ohne dabei sinnstiftend oder wertschöpfend tätig zu sein.
Ich habe einen Teil meines Lebens in der DDR zugebracht.
Ich weiß, dass es so ist.
30

31. Die Kurzversion davon lautet: Wer misst, misst Mist.
Und aus diesem Grund ist ein Scrum Master den größten Teil des Tages mit Nicht- Messen beschäftigt.
31

32. Oder, um es mit Yogi Berra zu sagen: You can observe a lot by just watching.
Und was betrachtet der Scrum Master?
32

33. Nun, im Wesentlichen vier Dinge:
Sein Team, seinen Product Owner, seine Organisation und die Engineering Practices.
Je nach Zeitpunkt ist die Intensität der Beobachtung eine andere, aber es sind immer diese vier Bereiche, die im Fokus des Scrum Master stehen.
33

34. Leider wird der Scrum Master häufig als Reporter von Velocity betrachtet.
Das ist falsch, wie auch das häufig anzutreffende Verständnis von Velocity falsch ist.
34

35. Mir begegnen häufig Organisationen, die glaube, Velocity sei die Arbeitskapazität eines Teams.
Das ist – meiner Meinung nach – falsch.
Der Begriff Velocity ist hier leider etwas irreführend.
35

36. Fakt ist: Die Velocity hilf uns nicht dabei, herauszufinden, wie viel Wert ein Team geschaffen hat.
36

37. Der Outcome eines Teams ist der Customer Value.
Dieser setzt sich zusammen aus dem Wissen, das ein Team anhäuft und dem Business Value, den der Kunde mit der Software realisieren kann.
Normalerweise folgt der kumulierte Customer Value dieser Kurve.
37

38. Velocity ist nicht die Arbeitskapazität eines Teams, sondern seine Lernkurve.
Das ist ein wichtiger Unterschied, den man verstehen muss.
Je länger ein Team mit einer Methode, Technologie oder Domäne arbeitet, desto mehr Zeit hatte es, seine Arbeitsweise zu optimieren.
38

39. Deshalb sieht die Kurve der Velocity pro Sprint richtig guter Teams auch der Kurve des Outcome sehr ähnlich.
Ich habe hier mal versucht, das auf die Tuckman-Phasen der Teambildung zu projezieren.
Richtig gute Team, die von einem guten Scrum Master begleitet werden, fangen nach den Forming- und Storming-Phasen an, richtig aufzudrehen.
Das klappt aber nur, wenn es ein Vollzeit-Scrum Master ist.
Teilzeit Scrum Master haben keine Chance, ihre Teams zu High Performance Teams aufzubauen.
Deshalb ist ein Teilzeit-Scrum Master ökonomisch totaler Unsinn.
Merke: Ein Teilzeit-Scrum Master bedeutet einen halbe Entwickler mehr.
Ein Vollzeit-Scrum Master bedeutet einen Multiplikation in der Lernkurve des Teams.
Und damit auch die Möglichkeit, entsprechend mehr Business Value in der gleichen Zeit zu schaffen.
39

40. Wenn man diese Kurve kennt, besteht die große Gefahr, dass man versucht ist, die Velocity durch Maßnahmen zu steigern.
Davon sollte man die Finger lassen.
Das klappt nicht.
Eine höhere Velocity muss aus dem Team heraus kommen.
Sie kann nicht von außen gesteigert werden.
40

41. Wenn ich dann doch mal einen Manager treffe, der von einem Team verlangt, die Velocity zu steigern, empfehle ich immer, die Schätzungen zu verdoppeln. Das ist valide und schnell umgesetzt. Damit sind die KPI-Junkies glücklich. Das coole ist, dass man das sogar rückwirkend machen kann. Spätestens dann sollten die KPI-Junkies merken, dass sie Blödsinn fordern. Manche merken es aber auch dann nicht.
41

42. Das ist ein normales Planning Poker Set.
Wenn man einfach bei jeder Schätzung die nächsthöhere Karte nimmt, steht der Steigerung der Velocity nichts mehr im Wege.
Neben den Steigerung gibt‘s aber noch eine Spezies, die viel gefährlicher ist.
Die Präzisionsschätzer.
42

43. Vor einer Weile war ich mal in einem Projekt, in dem ein Teammitglied immer meinte, die Story Points wären nicht valide.
Seine Begründung lag darin, dass sie keine Nachkommastellen haben.
Und Schätzungen seien nur valide, wenn sie Nachkommastellengenauigkeit haben.
Ich habe mir da ewig Gedanken drüber gemacht und kam schließlich auf die Idee, PI einzusetzen.
Wenn man als Consultant in diesen langen, dunklen, einsamen Nächten in eiskalten Hotelzimmern sitzt, in Städten, in denen man nicht mal seinen Hund aussetzen würde, kommen dann Ideen wie...
43

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

45. Ich komme nun zum Thema Steampunk.
Kennt jemand 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‘s Real 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‘s gefällt.
Um Euch ein Gefühl dafür zu geben...
45

46. ...hier ein Bildvergleich.
Das ist Science Fiction im Jahre 1987.
Eleganz, Stolz, Hochtechnisierung...
46

47. Und das ist die Steampunk-Interpretation des gleichen Raumschiffs.
Irgendwie vertrauenerweckend, oder?
47

48. Und bevor jetzt irgendjemand behauptet, ich wäre zu einseitig, was Science Fiction angeht.
Es gibt auch Steampunk Jedis.
The Empire Steams Back.
48

49. Genug der Vorrede, das Thema war Steampunk Management.
Meiner Ansicht nach ist Steampunk Management das Lösen von Problemen des Jahres 2014 mit Methoden des viktorianischen Zeitalters.
49

50. Steampunk-Management funktioniert mit stark vereinfachten Menschenbildern.
Wie sie damals im viktorianischen Zeitalter eben so üblich waren.
Zum Vergleich ist hier das 5. Agile Prinzip.
Es dreht sich um Motivation, Vertrauen und ein geeignetes Umfeld.
50

51. Dafür ist im Steampunk Management kein Platz.
Im Steampunk Management zwängt man seine Mitarbeiter in geistige Korsetts um ihre intellektuelle Bewegungsfreiheit maximal einzuschränken.
Steampunk Manager sind sehr linear in ihrem Denken.
51

52. Wenn ein Steampunk Manager ein komplexes System betrachtet, wie z.B. den Old Taxi Park, dann sieht er nicht das Bild, das wir gerade sehen.
52

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

54. Und das Ergebniss davon ist dann so etwas.
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.
Man kann es als zögerlichen Einstieg in die agile Welt betrachten, aber definitiv nicht mehr.
Viele sehen es aber als Zielbild einer agilen Organisation.
54

55. Und diese Leuten machen dann Überraschungsei-Consulting.
Es klingt gut.
Die Hülle schmeckt lecker.
Und wenn man sieht, was dabei rauskommt, ist man deprimiert.
Kurzum: Steampunk-Tools wie SAFe sind ein kleiner Schritt, aber keinesfalls das Ende der Straße.
55

56. Um Agilität zu verstehen und auch ihre Bedeutung für‘s Management müssen wir uns mit Kultur beschäftigen.
56

57. Kennt jemand dieses Bild?
Kennt jemand Cargo Cult?
Der Begriff Cargo Cult wurde von Richard Feynman geprägt.
Er bezog sich damit auf die Eingeborenen der Inseln im Südpazifik, die nach dem zweiten Weltkrieg Flugzeuge und Funktürme aus Holz bauten.
Der Grund dafür war, dass die während des Krieges stationierten amerikanischen Soldaten abgezogen waren und darauf hofften, mit diesen Aktionen wieder Flugzeuge anzulocken, die Fracht abwerfen würden.
Sie hatten den größeren Zusammenhang nicht verstanden, sondern betrieben einfach einen Kult um diese Fracht.
Eben Cargo Cult.
Viele Organisationen machen das ganz ähnlich.
Das erkennt man an Ideen wie diesen.
57

58. Die Krönung des Cargo Cult ist die Idee, keine vollständige Agilität zu benötigen.
Das ist so, als würde man zum Zahnarzt gehen und von ihm gesagt bekommen:
Wir müssen das richtige Karies-Maß für Sie finden.
Die Wahrheit ist: Einschränken von Agilität ist schlecht.
Einschränken von Agilität bedeutet, die Selbstorganisation einzuschränken.
Und das ist kontraproduktiv für die Innovationskraft von Unternehmen.
58

59. Außerdem bedeutet das Einschränken von Agilität, ein eingeschränktes Menschenbild zu vertreten.
Und damit ist man dann wieder beim Steampunk Management.
59

60. Der wesentliche Punkt, wenn man Agilität einführen möchte, ist eine Kultur des Vertrauens.
Aber Vertrauen fällt schwer, insbesondere in Steampunk Organisationen.
60

61. Für viele Steampunk Manager ist das so, als würde man ihnen einen Arm abtrennen. Und da ist dann dieser Phantomschmerz wo früher die Kontrolle war. Gefühlte Kontrolle, echte gab es nie.
61

62. Johann-Peter Hartmann hat von einiger Zeit etwas sehr kluges gesagt, dass dieses Problem auf den Punkt bringt:
Es gibt kein Übermaß an Selbstorganisation (Agilität).
Es gibt nur einen Mangel an gemeinsamen Zielen.
Und diesen Mangel muss man beseitigen.
62

63. Insbesondere, wenn man skalieren will.
Das mit der skalierten Agilität ist auch so ein Brainfuck.
63

64. Hier ist noch eine Folie, die ich aus unserer New School of IT geklaut habe.
Ich schätze Mary Poppendieck sehr, aber hier hat sie sich vertan.
Der erste Teil des Zitates ist einfach falsch.
64

65. Agilität geht immer mit Disziplin einher.
Agilität ohne Disziplin existiert nicht.
Wenn man Beispiele für Disziplin finden will, gibt es zwei Gruppen von Menschen, die man sich anschauen kann:
Zen-Buddhisten und agile Teams.
Der Unterschied zwischen beiden ist, dass die User Experience bei agilen Teams more enriched ist.
65

66. Fakt und traurige Wahrheit ist:
Man kann Agilität nicht skalieren.
Man kann nur Kultur skalieren.
Und das ist auch der korrekte Weg.
66

67. Agilität ist ein Wertegerüst, Agilität ist ein Mindset.
Beides sind grundlegende Bestandteile einer Kultur.
Und darum kann man durchaus eine agile Kultur skalieren.
Meine Frau ist nicht nur viel klüger als ich, sondern auch noch Kulturwissenschaftlerin.
Die hat mir das erklärt und mein tägliches Erleben bestätigt dies.
67

68. Damit man die Kultur in einem komplexen System wie dem Old Taxi Park oder einer Organisation skalieren kann, muss man sich mich fundamentalen kulturbildenden Techniken vertraut machen.
Zwei davon sind Nachahmen und Verstehen.
Nachahmen ist die Grundlage von Schrift, Musik und Sprache, auch wenn das Nachahmen heute durch das Urhebergesetzt erschwert wird.
Verstehen ist die Grundlage von systematischem Wissenserwerb und dem Schaffen gemeinsamer Ziele..
Und damit haben wir auch schon das Handwerkszeug für Management in agilen Organisationen.
68

69. Manager in agilen Organisationen führen durch Beispiel, sie animieren zum Nachahmen der agilen Werte.
69

70. Und sie führen durch das Schaffen gemeinsamer Ziele, sie arbeiten für das Verstehen und arbeiten damit für die Kultur der Organisation.
Es ist faszinierend, zu beobachten, wie sich Manager dahingehend entwickeln.
Am Anfang fällt es ihnen sehr schwer, insbesondere das Loslassen alter Gewohnheiten.
Aber irgendwann erkennen sie den Vorteil des Loslassens.
70

71. Denn: Wer loslässt hat zwei Hände frei.
Und mit zwei freien Händen kann man die wirklich wichtigen Dinge anpacken.
Das mach nicht nur jede Menge Spaß, das bringt auch die Organisation voran und stärkt die Kultur.
71

72. Und wenn man dann einen Manager sieht, dem vor Freude die Tränen in den Augen stehen, weil der Sprint Review seiner Teams so genial gelaufen ist, dann weiß man, dass man als Coach einen guten Job gemacht hat.
72

73. 73

74. Und ich bin jetzt fertig. Macht was draus!
74

75. 75