1

Stefan Roock

stefan.roock@it-agile.de

Henning Wolf

henning.wolf@it-agile.de

Hart aber herzlich

Was muss man alles erfahren, bis man agil ist?

Kernaussage: Das ganze Unternehmen muss sich ändern für die nachhaltige Einführung agiler Vorgehensweisen und das dauert Jahre. Es gibt drei überlappende Phasen bei der Einführung: Transparenz, Stabilität, Verbesserung

2

Stefan Roock Henning Wolf

http://www.it-agile.de

Agil mit Scrum, XP, FDD, Crystal seit 1999

Coach, Trainer, „Projektleiter“, Entwickler

Bücher über XP und Refactoring

Zertifiziert: Scrum Master, Scrum Product Owner, Scrum Practitioner, FDD, V-Modell XT

Für den Vortrag spielt Stefan den Projektleiter (PL) und Henning dessen Chef.

3

PL: Ich möchte mein neues Projekt agil durchführen. Und das versuche ich jetzt, meinem Chef zu „verkaufen“.

4

PL

Hey Chef. Ich will das neue Projekt agil durchführen. Und das funktioniert so.

Product Owner und Product Backlog

Sprint-Planning und Sprints

Laufende Software als Ergebnis

Selbstgesteuerte Teams.

Tägliche Abstimmung.

Mehr Details dazu gibt es bei http://www.it-agile.de

5

Transparenz Flexibilität Time-To-Market

PL

Das bringt Transparenz, Flexibilität und kürzere Time-To-Market

6

€ €

Chef

MACHEN

7

€ €

1 Woche später

Zeit vergeht: 1 Woche

8

Chef: Was bedeutet das denn nun? Das kann doch nicht wahr sein. Ich denke, mit agil wird alles viel besser.

PL: Du hast Recht. Die trödeln da ja nur rum. Ich künmere mich darum.

9

PL: Leute, so geht das nicht. Ihr seid viel zu langsam. Wir müssen die Termine halten. Wenn wir das nicht schaffen, können wir hier mit unseren agilen Vorgehensweisen einpacken.

10

€ €

4 Wochen später

Zeit vergeht: 4 Wochen

11

PL: Na, geht doch. Da hab‘ ich den Schneckies doch noch Feuer unter‘mHintern gemacht.

12

€ €

PL: Hier Chef, so sieht das Projekt doch schon besser aus. Ich habe das in Ordnung gebracht.

Chef: Und ich dachte schon, agil funktioniert nicht. Weiter so!

13

€ €

1 Woche später

Zeit vergeht: 1 Woche

14

Testabdeckung

50%

Chef: Guck‘ mal, das hat mir einer der Entwickler gegeben. Die Testabdeckung ist ganz schön gesunken.

PL: Oh ha. Das sehe ich zum ersten Mal. Nun gut, das reparieren wir in den nächsten Iterationen nebenbei.

15

€ €

1 Woche später

Zeit vergeht: 1 Woche

16

PL: Oh nein. Was ist denn da los. Das kann doch gar nicht wahr sein. Ein Burndown sollte doch runter gehen und nicht hoch. Ach so, das sind Bugs. Daher der Anstieg. Aber, wo kommen die ganzen Bugs denn her?

Chef: Haben wir beide das vielleicht verursacht? Im ersten Sprint fanden wir das Team zu langsam und dann haben wir Druck ausgeübt und dann waren sie auf einmal schneller.

PL: Argh. Die Entwickler haben dem Druck nachgegeben und die Qualität geopfert. Und das fällt uns jetzt auf die Füße.

17

Chef und PL zusammen: Übel, übel.

PL: Aber was machen wir denn jetzt?

18

Chef: John Wayne sagte einst: „Ein Mann muss tun, was ein Mann tun muss.“ Ich glaube, wir haben hier auch so eine Situation.

PL: Und was bedeutet das konkret.

Chef: Die Burndowns zeigen uns die Fakten, sie bringen uns Transparenz. Das ist gut. Wir haben das nur nicht erkannt. Wir hatten bisher ja nie Transparenz in den Projekten und wissen gar nicht, wie wir damitumgehen sollen.

19

PL: Dann müssen wir Descopen, also weniger Funktionalität als geplant ins nächste Release tun.

Chef: Ja, leider.

20

€ €

2 Monate später

Zeit vergeht: 2 Monate

21

Expect Trouble

PL: Kaum ist das Release Live, bekomme ich wütende Anrufe von enttäuschten Kunden. Es sind viel weniger Funktionen im Release, als wir versprochen haben.

Chef: Verübeln kann ich es Ihnen nicht. Ich werde wohl mit den Kunden sprechen müssen.

PL: Aber was willst Du Ihnen sagen?

Chef: Dass es uns leid tut. Da werden wir Zugeständnisse machen müssen und dann mehr Funktionen ins nächste Release packen.

22

Face the Facts

PL: Oh nein. Dann haben die das Problem beim nächsten Release doch wieder – nur schlimmer. Wir haben doch die Burndowns gesehen. Das ist offensichtlich die Geschwindigkeit, die wir im Moment erreichen können. Und das Team wird doch nicht dadurch schneller, dass wir den Kunden mehr versprechen. Das ist die Transparenz, die die agilen Vorgehensweisen versprochen haben. Jetzt müssen wir die gewonnene Transparenz auch nutzen!

Chef: Puh. Du hast Recht. Man, unter Stress kann man echt nicht mehr richtig denken.

23

Zuerst kommt Transparenz

Chef: Stimmt, wir müssen es ganz durchstehen. Ich werde keine Zugeständnisse gegenüber den Kunden machen, die wir letztlich nicht halten können.

War es das schon mit Vorteilen der Transparenz? Wir wissen jetzt, wie schlecht wir sind? Können wir damit noch irgendwas Konstruktives anfangen?

PL: Naja, wir können jetzt schauen, ob und welche Verbesserungen wirklich was bringen. Und Du könntest entscheiden, weniger Projekte durchzuführen oder mehr Entwickler einzustellen oder so. Und in jedem Projekt können die Produktmanager entscheiden, nur noch die wichtigen 80%-Lösungen bauen zu lassen und nicht immer die goldenen Wasserhähne bestellen.

24

€ €

2 Wochen später

Zeit vergeht: 2 Wochen

25

PL: Hallo Chef. Wie waren die Gespräche mit den Kunden.

Chef: Natürlich nicht so angenehm. Aber auch nicht so schlimm wie befürchtet. Die meisten Kunden haben die Ehrlichkeit geschätzt und ich denke wir werden keine Kunden verlieren.

Chef: Damit haben wir eine wichtige Lektion gelernt. Wir können nicht einfach auf der Führungsebene darüber phantasieren, was alles ins nächste Release kommen könnte und die Entwickler den Mist ausbaden lassen. Wir müssen in Zukunft anders mit den Kunden kommunizieren und dürfen ihnen nichts versprechen, was wir nicht sicher halten können. Und die Entwicklungsteams müssen wir stärker einbeziehen, wenn es um die Planung der Release-Inhalte gehen. Sie müssen ja mind. mal was zu den Aufwänden sagen.

PL: Ich finde, das sind sehr lobenswerte Änderungen bei uns. Da hat die ganze Katastrophe doch noch ihr gutes gehabt.

26

Chef: Dieses agile Vorgehen ist ja wirklich virulent. Ich dachte, wir könnten einfach in den Projekten agil vorgehen und jetzt stelle ich fest, dass ich Teile des Unternehmens umbauen muss. Marketing und Vertrieb müssen jetzt ganz anders arbeiten.

27

€ €

1 Woche später

Zeit vergeht: 1 Woche

28

PL: Hallo Chef, guck‘ mal. Jetzt ist es richtig übel. Wir sind nicht nur langsam. Wir bewegen uns gar nicht mehr vorwärts.

Chef: <sarkatisch> Super: Ein stabiles Burndown.

PL: Ha, ha, ha. Clown gefrühstückt?

29

Chef: OK, Spaß beiseite. Was machen wir denn jetzt damit? Anbrüllen hat beim letzten Mal ja nicht so gut funktioniert.

PL: Hm. Eigentlich soll das Team ja selbstgesteuert arbeiten. Die müssten das also selbst regeln.

Chef: Das scheint aber nicht zu funktionieren, oder?

PL: Nein, überhaupt nicht. Wenn ich nicht sage, wo es langgeht, rennen die vollkommen kopflos durch die Gegend.

Chef: Ich rufe mal eben einen alten Freund an. Der kennt sich mit Selbststeuerung aus. Mal sehen, was der sagt.

30

€ €

1 Tag später

Zeit vergeht: 1 Tag

31

Chef: Mein Kumpel sagt, man muss das Team führen – nicht inhaltlich, sondern durch den Prozess.

PL: Häh?

Chef: Du sagst Ihnen nicht mehr, was sie tun sollen und schon gar nicht, wie sie ihre Arbeit machen sollen. Aber Du gibst Deine Wahrnehmung der Dinge in das Team, z.B. „Ich habe mir das Burndown angesehen und das scheint mir auf Probleme hinzudeuten. Wie seht Ihr das?“ Du wirst also eine Art Moderator.

PL: Ah, verstehe. Das kann ich nachvollziehen. Es fühlt sich aber nicht so gut an. Früher war ich der Chef des Teams und jetzt habe ich nichts mehr zu sagen. Das kommt ja einer Degradierung gleich.

Chef: Nicht in meinen Augen. Du warst und bist dafür verantwortlich, dass die Projekte bestmöglich funktionieren. Und das macht man bei agilen Vorgehensweisen halt anders als klassisch. Und schließlich bist Du ja mit dem Vorschlag gekommen, agil vorzugehen. Jetzt solltest Du auch Deinen Teil dazu leisten.

PL: Das werde ich dann wohl müssen. Vielleicht gefällt es mir am Ende sogar.

Chef: Genau. Und wenn nicht, kannst Du ja immer noch kündigen ☺

32

€ €

2 Wochen später

Zeit vergeht: 2 Wochen

33

Chef: Das erinnert mich doch alles sehr an unsere ersten Wochen mit agilen Vorgehensweisen. Da hatten wir doch auch so einen plötzlichen Abfall. Müssen wir also wieder mit massenhaft Bugs rechnen?

PL: <grinst> Ich glaube nicht. Ich habe wie Du vorgeschlagen hast, die Moderatorenrolle eingenommen. Und siehe da, das Team hat nach kurzer Diskussion herausgefunden, was die Ursache für den Stillstand war: Alle eingeplanten Arbeiten waren durch ein Infrastruktur-Problem blockiert. Ich habe dann ein paar Kontakte hergestellt und etwas Budget freigegeben, um das Problem zu beseitigen. Und danach hat das Team wieder fahrt aufgenommen.

34

€ €

2 Monate später

Zeit vergeht: 2 Monate

35

Stabilität

Chef: Damit sind wir immer noch lange nicht so schnell, wie ich mir das wünschen würde.

PL. Stimmt. Aber wir haben inzwischen immerhin Stabilität in der Produktivität. Wir sind verlässlich langsam. Und das ist eine gute Basis für Verbesserungen. Denn nur so können wir einigermaßen verlässlich sagen, ob und wie sich bestimmte Verbesserungsmaßnahmen auswirken.

36

PL: Was willst Du denn verbessert haben?

Chef: Was kann ich denn kriegen?

PL: Naja, wir könnten jetzt versuchen, schneller neue Leute zu integrieren bzw. überhaupt mal neue Leute einarbeiten. Wir könnten die Qualitätsprobleme angehen. Wir könnten häufiger als alle 3 Monate ausliefern oder insg. Das Time-to-market einzelner Anforderungen verbessern. Aber bitte eins nach dem anderen. Was denkst Du?

Chef: Dann lass uns doch die Qualitätsprobleme angehen, damit wir das ein für alle mal vom Tisch haben.

PL: Wie soll die Qualität denn gemessen werden?

Chef: Anzahl von den Kunden gemeldete Bugs nach dem Release.

37

Bugs pro Release

200

100

PL: OK, dann gucken wir uns mal den aktuellen Stand an. Wir haben in jedem Release 60-80 Bugs.

38

€ €

1 Woche später

Zeit vergeht: 1 Woche

39

TDD

PL: Ich habe mit dem Team drüber gesprochen, was wir in Sachen weniger Bugs tun wollen. Und wir wollen jetzt testgetriebene Entwicklung (TDD) einführen.

Chef: So, so, was immer das ist, macht es, wenn es hilft.

PL: Ich erkäre Dir das mal ganz kurz: test-code-refactor

Mehr Details dazu gibt es bei http://www.it-agile.de

40

€ €

2 Monate später

Zeit vergeht: 2 Monate

41

Testabdeckung

50%

Geschwindigkeit

Chef: Wie läuft es mit TDD?

PL: Wie Du siehst, ist die Testabdeckung ordentlich angestiegen. Die neuen Teile haben sogar 75%, bei den alten wird es noch dauern. Aber die Geschwindigkeit ist erstmal leicht gesunken, aktuell fast wieder auf dem alten Niveau. Wir sind jetzt also wieder fast genauso schnell wie früher, aber mit besserer Qualität, wie wir glauben. Wir machen das auch konsequent, wenn wir Bugfixing betreiben: Erst einen test schreiben, der den Fehler findet, dann fixen. So haben wir nicht mehr den unangenehmen Effekt, dass dieselben Ecken immer wieder kaputtgehen.

Chef: Dann warten wir mal das nächste Release ab, ob es sich auch auszahlt.

42

Bugs pro Release

200

100

PL: Schau es Dir an. Wahnsinn, wie wenig Fehler dieses mal im Release waren!

Chef: Wow, das ist wirklich toll. Einer unserer wichtigen Kunden hat michsogar angerufen und gesagt, dass sie unsere neue Version extra länger getestet haben, weil seine Leute nicht so wie bei den letzten Auslieferungen Fehler gefunden haben! Das ist wirklich ein schöner Effekt an positiver Wahrnehmung bei den Kunden, bringt es uns auch intern noch mehr?

PL: Ja, guck mal hier (nächste Folie).

43

Geschwindigkeit

Features

Bugs

PL: Ich habe mal aufgezeichnet, welchen Anteil wir bei der Entwicklung an Bugfixing und welchen an neuen Features verbringen.

Chef: Cool, also selbst bei gleicher Geschwindigkeit schaffen wir jetzt effektiver das, was uns was nützt, nämlich mehr neue Features?

PL: Genau. Aber ich erwarte sogar noch mehr! Unser agiler Coach meint, dass wir vermutlich bald sogar noch schneller werden, weil das Design durch TDD so verbessert wird, dass Änderungen und Erweiterungen leichter werden. Wir dürfen also gespannt bleiben!

44

VerbesserungChef: Ah, jetzt sehe ich auch endlich mal, dass wir besser und schneller werden. Endlich wirkt sich agiles Vorgehen auch mal sichtbar finanziell aus.

45

€ €

Ende des Schauspiels

46

Transparenz

Stabilität

Verbesserung

Wir haben in Projekten beobachtet, dass sich die Einführung agiler Methoden in drei Phasen gliedern lässt:

•Transparenz

•Stabilität

•Verbesserung

Die Phasen überlappen sich, aber es gibt jeweils klare Schwerpunkte und meistens bringt es wenig, wenn man versucht, die ersten Phasen zu überspringen.

Und wie lange dauert der Spaß? Das kann schon mal 3 bis 5 Jahre dauern, bis agiles Vorgehen nachhaltig im Unternehmen installiert ist.

Natürlich kann man lange vorher z.T. erhebliche Verbesserungen erreichen und es gibt auch entsprechende Success-Stories dazu. Aber dann hat man die agile Vorgehensweise noch nicht nachhaltig im Unternehmen etabliert.

47

Und der Verbesserungsprozess muss immer weiter gehen, weil das hier gezeigte naive Modell der Prozessqualität nicht gilt.

48

Stattdessen nutzt sich die Prozessqualität über die Zeit ab – mind. im Verhältnis zum Markt. Daher muss man kontinuierlich verbessern, um die eigene Position zu halten.

49

http://www.it-agile.de

Vielen Dank für die Aufmerksamkeit, bei Fragen stehen wir Ihnen gerne zur Verfügung, auch auf unserem Messestand, per E-Mail, per Telefon oder über unsere Web-Site http://www.it-agile.de.