SlideShare ist ein Scribd-Unternehmen logo
1 von 75
Downloaden Sie, um offline zu lesen
1
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
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
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
...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
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
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
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
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
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
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
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
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
...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
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
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
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
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
Den Impediment Resolver kennen sicherlich alle. 
Kaum gibt‘s ein Impediment, räumt er es aus dem Weg. 
Ein Klassiker. 
19
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
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
Scrum Master erkennen Zusammenhänge, logische, soziale und alle anderen auch. Und sie können sie darstellen, erklären und Handlungsoptionen aufzeigen. 
22
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
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
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
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
...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
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
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
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
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
Oder, um es mit Yogi Berra zu sagen: You can observe a lot by just watching. 
Und was betrachtet der Scrum Master? 
32
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
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
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
Fakt ist: Die Velocity hilf uns nicht dabei, herauszufinden, wie viel Wert ein Team geschaffen hat. 
36
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
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
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
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
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
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
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
...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
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
...hier ein Bildvergleich. 
Das ist Science Fiction im Jahre 1987. 
Eleganz, Stolz, Hochtechnisierung... 
46
Und das ist die Steampunk-Interpretation des gleichen Raumschiffs. 
Irgendwie vertrauenerweckend, oder? 
47
Und bevor jetzt irgendjemand behauptet, ich wäre zu einseitig, was Science Fiction angeht. 
Es gibt auch Steampunk Jedis. 
The Empire Steams Back. 
48
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
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
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
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
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
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
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
Um Agilität zu verstehen und auch ihre Bedeutung für‘s Management müssen wir uns mit Kultur beschäftigen. 
56
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
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
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
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
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
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
Insbesondere, wenn man skalieren will. 
Das mit der skalierten Agilität ist auch so ein Brainfuck. 
63
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
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
Fakt und traurige Wahrheit ist: 
Man kann Agilität nicht skalieren. 
Man kann nur Kultur skalieren. 
Und das ist auch der korrekte Weg. 
66
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
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
Manager in agilen Organisationen führen durch Beispiel, sie animieren zum Nachahmen der agilen Werte. 
69
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
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
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
Und ich bin jetzt fertig. Macht was draus! 
74
75

Weitere ähnliche Inhalte

Was ist angesagt?

Arbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaArbeitswelt2020PechaKucha
Arbeitswelt2020PechaKucha
Elsy Zollikofer
 

Was ist angesagt? (19)

Performancemessung, jetzt in echt
Performancemessung, jetzt in echtPerformancemessung, jetzt in echt
Performancemessung, jetzt in echt
 
Das Ende der Karriere
Das Ende der KarriereDas Ende der Karriere
Das Ende der Karriere
 
Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommt
 
Die Architektur, die man kann
Die Architektur, die man kannDie Architektur, die man kann
Die Architektur, die man kann
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-Verträge
 
Einfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektesEinfangen eines technisch kaputten projektes
Einfangen eines technisch kaputten projektes
 
Legacy php - Sanieren oder Ablösen?
Legacy php  - Sanieren oder Ablösen?Legacy php  - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?
 
Erfolgreiche rewrites
Erfolgreiche rewritesErfolgreiche rewrites
Erfolgreiche rewrites
 
RoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für ChinaRoofTop Brains & BBQ: Ein Gästbuch für China
RoofTop Brains & BBQ: Ein Gästbuch für China
 
Arbeitswelt2020 pecha kucha
Arbeitswelt2020 pecha kuchaArbeitswelt2020 pecha kucha
Arbeitswelt2020 pecha kucha
 
Arbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaArbeitswelt2020PechaKucha
Arbeitswelt2020PechaKucha
 
Wetware Bugs and Refactoring
Wetware Bugs and RefactoringWetware Bugs and Refactoring
Wetware Bugs and Refactoring
 
DevOps jenseits der Tools
DevOps jenseits der ToolsDevOps jenseits der Tools
DevOps jenseits der Tools
 
Anforderungen haben immer Schuld
Anforderungen haben immer SchuldAnforderungen haben immer Schuld
Anforderungen haben immer Schuld
 
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-LockdownDer 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
Der 8-Stunden-Mythos - Entlarvt vom Covid-19-Lockdown
 
2013 OS E-Commerce Magento OXID Shopware
2013 OS E-Commerce Magento OXID Shopware2013 OS E-Commerce Magento OXID Shopware
2013 OS E-Commerce Magento OXID Shopware
 
2010 09 21 AdminCamp News Tuesday
2010 09 21 AdminCamp News Tuesday2010 09 21 AdminCamp News Tuesday
2010 09 21 AdminCamp News Tuesday
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
Whitepaper digitale Teamkultur
Whitepaper digitale TeamkulturWhitepaper digitale Teamkultur
Whitepaper digitale Teamkultur
 

Andere mochten auch

Clase 5 y_6_materias_primas_y_actividades_economicas
Clase 5 y_6_materias_primas_y_actividades_economicasClase 5 y_6_materias_primas_y_actividades_economicas
Clase 5 y_6_materias_primas_y_actividades_economicas
Carolina Garrido
 

Andere mochten auch (15)

Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management
Agility Brainfucks - Von Menschen, Bildern und Steampunk-ManagementAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management
 
Vom Projektleiter zum Product Owner
Vom Projektleiter zum Product OwnerVom Projektleiter zum Product Owner
Vom Projektleiter zum Product Owner
 
Presentación Ecomercia
Presentación Ecomercia Presentación Ecomercia
Presentación Ecomercia
 
Taller 2
Taller 2Taller 2
Taller 2
 
Comercia Global Payments
Comercia Global PaymentsComercia Global Payments
Comercia Global Payments
 
Costos segun su naturaleza
Costos segun su naturalezaCostos segun su naturaleza
Costos segun su naturaleza
 
Recursos naturales
Recursos naturalesRecursos naturales
Recursos naturales
 
Clase 5 y_6_materias_primas_y_actividades_economicas
Clase 5 y_6_materias_primas_y_actividades_economicasClase 5 y_6_materias_primas_y_actividades_economicas
Clase 5 y_6_materias_primas_y_actividades_economicas
 
Diferencia entre comercio internacional y exterior
Diferencia entre comercio internacional y exteriorDiferencia entre comercio internacional y exterior
Diferencia entre comercio internacional y exterior
 
Costo indirecto de fabricación ronny garza
Costo indirecto de fabricación  ronny garzaCosto indirecto de fabricación  ronny garza
Costo indirecto de fabricación ronny garza
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
 
Costos indirectos fabricación cif
Costos indirectos fabricación  cifCostos indirectos fabricación  cif
Costos indirectos fabricación cif
 
Costos Indirectos De Fabricacion
Costos Indirectos De FabricacionCostos Indirectos De Fabricacion
Costos Indirectos De Fabricacion
 
Costos De ProduccióN
Costos De ProduccióNCostos De ProduccióN
Costos De ProduccióN
 
Costos indirectos de fabricación cif
 Costos indirectos de fabricación cif Costos indirectos de fabricación cif
Costos indirectos de fabricación cif
 

Ähnlich wie Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen

eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo GmbH
 

Ähnlich wie Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen (20)

Pecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in CoolPecha-Kucha: Scrum in Cool
Pecha-Kucha: Scrum in Cool
 
Alles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 MinutenAlles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 Minuten
 
AYCON Festschrift - 2-te Auflage 2021
AYCON Festschrift - 2-te Auflage 2021AYCON Festschrift - 2-te Auflage 2021
AYCON Festschrift - 2-te Auflage 2021
 
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
eparo – IA und agile Softwareentwicklung verbinden (Vortrag IA-Konferenz 2009...
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Mythos High Performance Teams
Mythos High Performance TeamsMythos High Performance Teams
Mythos High Performance Teams
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
 
Digitalisierung alles in Bewegung
Digitalisierung alles in BewegungDigitalisierung alles in Bewegung
Digitalisierung alles in Bewegung
 
Arbeitsorganisation
ArbeitsorganisationArbeitsorganisation
Arbeitsorganisation
 
OKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im AgilenOKR, Ziele und Zielsysteme im Agilen
OKR, Ziele und Zielsysteme im Agilen
 
AgileAustriaConference2023_Der SM – Balancekünstler zwischen Teamsekretär und...
AgileAustriaConference2023_Der SM – Balancekünstler zwischen Teamsekretär und...AgileAustriaConference2023_Der SM – Balancekünstler zwischen Teamsekretär und...
AgileAustriaConference2023_Der SM – Balancekünstler zwischen Teamsekretär und...
 
Wie Agilität im Unternehmen zum Risiko werden kann_AAC2019
Wie Agilität im Unternehmen zum Risiko werden kann_AAC2019 Wie Agilität im Unternehmen zum Risiko werden kann_AAC2019
Wie Agilität im Unternehmen zum Risiko werden kann_AAC2019
 
Happy projects 2016 selbstorganisation in agilen projekten - 2016 - boris g...
Happy projects 2016   selbstorganisation in agilen projekten - 2016 - boris g...Happy projects 2016   selbstorganisation in agilen projekten - 2016 - boris g...
Happy projects 2016 selbstorganisation in agilen projekten - 2016 - boris g...
 
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
Lean Startup: Wie sieht der Einsatz von MVPs in der deutschen Praxis aus?
 
Product Owner 2 Product CEO
Product Owner 2 Product CEOProduct Owner 2 Product CEO
Product Owner 2 Product CEO
 
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
AGILE BEYOND BUZZWORD BINGO (MAGAZIN)
 
Lean Startup im Unternehmen - der IT-Leiter als Entrepreneur?
Lean Startup im Unternehmen - der IT-Leiter als Entrepreneur?Lean Startup im Unternehmen - der IT-Leiter als Entrepreneur?
Lean Startup im Unternehmen - der IT-Leiter als Entrepreneur?
 
22 wichtige Erkenntnisse aus 5 Jahren YUHIRO
22 wichtige Erkenntnisse aus 5 Jahren YUHIRO22 wichtige Erkenntnisse aus 5 Jahren YUHIRO
22 wichtige Erkenntnisse aus 5 Jahren YUHIRO
 
Agile Organisationen
Agile OrganisationenAgile Organisationen
Agile Organisationen
 

Mehr von Gerrit Beine

Backlog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
Backlog Priorisierung mit Cost of Delay & Monte Carlo SimulationenBacklog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
Backlog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
Gerrit Beine
 

Mehr von Gerrit Beine (20)

Auf Lesereise mit Frit und Fred
Auf Lesereise mit Frit und FredAuf Lesereise mit Frit und Fred
Auf Lesereise mit Frit und Fred
 
Mastering Cargo Cult
Mastering Cargo CultMastering Cargo Cult
Mastering Cargo Cult
 
Conway’s Law & Soziologie in der Software-Architektur
Conway’s Law & Soziologie in der Software-ArchitekturConway’s Law & Soziologie in der Software-Architektur
Conway’s Law & Soziologie in der Software-Architektur
 
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wird
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wirdBeyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wird
Beyond User Stories - Backlogs priorisieren, wenn es anspruchsvoll wird
 
Mastering Cargo Cult - Dunning, Kruger & die Agile Bias Curve
Mastering Cargo Cult - Dunning, Kruger & die Agile Bias CurveMastering Cargo Cult - Dunning, Kruger & die Agile Bias Curve
Mastering Cargo Cult - Dunning, Kruger & die Agile Bias Curve
 
Gut genug - Rahmenbedingungen für agile Architekturen
Gut genug - Rahmenbedingungen für agile ArchitekturenGut genug - Rahmenbedingungen für agile Architekturen
Gut genug - Rahmenbedingungen für agile Architekturen
 
Beyond Agile – Ungewissheit mit der Real Option Theory meistern
Beyond Agile – Ungewissheit mit der Real Option Theory meisternBeyond Agile – Ungewissheit mit der Real Option Theory meistern
Beyond Agile – Ungewissheit mit der Real Option Theory meistern
 
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...
Backlog Priorisierung 2020: Wertmodelle & Simulationen von Intangibles zur Pr...
 
Backlog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
Backlog Priorisierung mit Cost of Delay & Monte Carlo SimulationenBacklog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
Backlog Priorisierung mit Cost of Delay & Monte Carlo Simulationen
 
Der hyperbolische Thread-Koeffizient
Der hyperbolische Thread-KoeffizientDer hyperbolische Thread-Koeffizient
Der hyperbolische Thread-Koeffizient
 
Broken by Design
Broken by DesignBroken by Design
Broken by Design
 
Die Testedimaryp - Über die Antimonie des agilen Testens in der Praxis
Die Testedimaryp - Über die Antimonie des agilen Testens in der PraxisDie Testedimaryp - Über die Antimonie des agilen Testens in der Praxis
Die Testedimaryp - Über die Antimonie des agilen Testens in der Praxis
 
Vom Projektleiter zum Product Owner
Vom Projektleiter zum Product OwnerVom Projektleiter zum Product Owner
Vom Projektleiter zum Product Owner
 
Antifragilität
AntifragilitätAntifragilität
Antifragilität
 
Technische Schulden - mit Notizen
Technische Schulden - mit NotizenTechnische Schulden - mit Notizen
Technische Schulden - mit Notizen
 
Technische Schulden
Technische SchuldenTechnische Schulden
Technische Schulden
 
Die Product Owner Toolbox
Die Product Owner ToolboxDie Product Owner Toolbox
Die Product Owner Toolbox
 
Agile Coach zu werden ist nicht schwer... - mit Notizen
Agile Coach zu werden ist nicht schwer... - mit NotizenAgile Coach zu werden ist nicht schwer... - mit Notizen
Agile Coach zu werden ist nicht schwer... - mit Notizen
 
Agile Coach zu werden ist nicht schwer...
Agile Coach zu werden ist nicht schwer...Agile Coach zu werden ist nicht schwer...
Agile Coach zu werden ist nicht schwer...
 
Scaled, Distributed, Agile - Produktentwicklung auf neuen Wegen
Scaled, Distributed, Agile - Produktentwicklung auf neuen WegenScaled, Distributed, Agile - Produktentwicklung auf neuen Wegen
Scaled, Distributed, Agile - Produktentwicklung auf neuen Wegen
 

Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen

  • 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