Es geht nicht um Velocity. Ich glaube sogar, dass das Konzept der Velocity kontraproduktiv ist. Deshalb erzähle ich auch nichts von Hyperproductive

Transkript

1 1

2 Es geht nicht um Velocity. Ich glaube sogar, dass das Konzept der Velocity kontraproduktiv ist. Deshalb erzähle ich auch nichts von Hyperproductive Teams. Das macht Jeff Sutherland. 2

3 Es geht um Business Value. High Performance Teams produzieren Business Value. Und zwar mehr davon als andere Teams. Das Blöde ist nur, dass die meisten Organisationen den Business Value nicht messen können. Deshalb messen sie das Team. Das ist eigentlich traurig. Velocity ist eine Metrik, Business Value ist ein Wert. Das ist der Unterschied. Metriken kann ich fälschen, Werte nicht. 3

4 Auf der Agile World 2013 gab es einen Vortrag zum Thema Flow. Danach entstand eine Diskussion, in der viel über Taylorismus gesprochen wurde. Da kam nach meinen Gefühl viel Angst zum Ausdruck. Angst vor zu viel Flow, davor ausgebeutet zu werden. 4

5 Was der Mann gemacht hat, hat Peter F. Drucker mal gut zusammengefasst: Durch Management-Methoden die Produktivität der Industrie um den Faktor 50 gesteigert. Das war die große Leistung des 20 Jahrhunderts. Der Punkt ist, und das hat Peter F. Drucker auch gesagt: Im 21. Jahrhundert muss so eine Steigerung im Bereich der Wissensarbeit geschehen. Deshalb glaube ich, dass ein Taylor heute das Agile Manifest unterzeichnet hätte. 5

6 6

7 Ich kam einmal zu einem Team, das in einem großen Scrum Projekt arbeitete. Das Team musste sich an Regeln halten, die für alle Teams im Projekt galten, weil so ein Projekt nur durch das strikte Einhalten gemeinsamer Regeln funktionieren kann. Eine der Regeln war, dass alle Tasks im Planning mit Stunden geschätzt werden mussten und im JIRA dokumentiert werden mussten. Das Team startete einen zwei Wochen-Sprint mit 20 geschätzten und dokumentierten Tasks. Was passierte? Genau, der Sprint ging schief. In der Retrospektive wurde dann beschlossen, was getan werden muss, um das zu ändern. 7

8 Die Änderung war: noch genauer Schätzen. Das ist natürlich Käse, und deshalb kamen am Ende nur noch 10 Tasks raus. Der Sprint ging natürlich wieder schief. Ein linearer Forecast hätte im nächsten Sprint zu 0 Tasks geführt. Als ScrumMaster platzt man in so einer Situation fast. Es ist aber wichtig, das Team solche Fehler machen zu lassen. 8

9 Ich kenne viele ScrumMaster, die wissen wie s geht. Die sagen dann ihren Teams: Macht es so und so und dann macht ihr es richtig. Wenn ich dann zu ihnen sagen: was Du da treibst, ist nicht agil, das ist genau das tayloristische, gegen das Du immer wetterst, gucken sie mich entsetzt an. ScrumMaster haben auch einen Coaching-Auftrag. Coaching heißt, jemanden zur Erkenntnis zu führen. Der Punkt ist: Wenn ich jemandem sage, wie er etwas machen soll, erreiche ich bestenfalls eine Verhaltensänderung durch Nach-ahmung. Was für ein High Performance Team notwendig ist, ist eine Verhaltensänderung durch Nach-denken. Man muss einen Fehler gemacht haben, um den Lösungsweg schätzen zu können. Natürlich soll der ScrumMaster dem Team Best Practices an die Hand geben. Und: Nein, das dauert nicht länger, es ist nur anstrengender für den ScrumMaster. Der Trick ist: kontrolliertes Scheitern. 9

10 In der folgenden Retro habe ich dem Team gesagt, sie sollten darüber nachdenken, dass ein Task nicht länger als einen Tag dauern sollte. Im Team war ein Physiker, man sieht, was da raus kam. Zwei Wochen Sprint. Das sind 10 Arbeitstage (normalerweise). Bei einem 7-Personen-Team sollten mindestens 70 Tasks am Board hängen. Das wurde in der Retro akzeptiert. Klingt auch erstmal logisch. Ist aber gar nicht so einfach. Hindernisse: Schätzen dauert lang, Dokumentieren dauert lang. Das hält das Team von guten Tasks ab. Das ist ein Impediment, das wir eliminieren müssen. Problem: Organisationsregel, projektweit gültig. 10

11 Die Lösung ist, den Wert und die Kosten dieser Aktivitäten zu messen. Hier hilft uns unverhoffterweise Taylor höchstselbst. 11

12 Also ermitteln wir mal, was uns so eine Aufgabe kostet. Ich habe dann die Zeit gestoppt, die das Team mit den Schätzungen verbracht hat und die Zeit gestoppt, die für das Eintragen und Verwalten der Tasks benötigt wurde. Mit den marktüblichen Tagessätzen habe ich dann einen Preis pro Task im Tool nennen wir es J. ermittelt. Der war ganz schön hoch und das bei Lean Management! 100 Tasks kosten uns da ungefähr 1700 Euro. Pro Sprint. Das sind mindestens zwei Personentage bezahlt für ja, wofür eigentlich? 12

13 Das Ziel agiler Methoden sind nicht glückliche Teams. Das Ziel ist Business Value, die glücklichen Teams entstehen dann automatisch. Mit Business Value kann der ScrumMaster unglaublich viel durchsetzen. Das ist auch sehr anstrengend, aber das ist es wert. Damit kauft der ScrumMaster die Freiheit für das Team, die es braucht, um ein High Performance Team zu werden. 13

14 Nach einer Weile hatte das Team 200 Tasks am Board. Im Sprint hatten die richtig Flow, konnten parallelisieren und sich selbst organisieren. 14

15 15

16 Die Anzahl der Tasks pendelte sich zwischen 100 und 150 pro Sprint ein. Das Planning dauerte nur noch zwei Stunden das Team hatte plötzlich Zeit, sich mit Business Value zu beschäftigen. 16

17 Der erste Schritt ist vollbracht Wir wissen jetzt, wie so ein Team lernt und wie man die Organisation dazu bringt, das Team etwas Sinnvolles machen zu lassen. 17

18 Die große Frage, die sich immer wieder stellt ist: Welche Leute sind in so einem Team? Das Ganze ist mehr als die Summe seiner Teile. Das mag bei Lego Duplo zutreffen. Bei Teams ist man ganz schnell an dem Punkt, bei dem das Ganze weitaus weniger ist, als jedes Teil für sich allein. 18

19 Link zum Bild: Eine Firma, mit der ich gerarbeitet habe, hatte mal ein Scrum Team aus ihren 10 besten Consultants zusammengestellt. Jeder hatte den Ruf, eine 1-Personen-Armee zu sein. Das Team ist grandios gescheitert, weil sie keinen Team-Spirit entwickeln konnten. Solche Leute sind bewundernswert und extrem wertvoll, wenn sie allein Probleme lösen. Im Team stehen sie sich aber oft gegenseitig im Weg, da kann man auch als ScrumMaster oft nicht viel ausrichten. Der Glaube, 10 solche Leute wären als Team die Überflieger, ist ein typischer Management Brainfuck. 19

20 Erfahrung ist in der Wissensarbeit nur die halbe Miete. Letztens war ein Artikel im HBR, dessen Fazit war, dass man sich beim Recruiting von Leuten nicht primär auf deren Erfahrung sondern auf deren Potential konzentrieren sollte. Link: Dass das mit den 10 Top-Entwicklern nicht klappt, habe ich ja gerade schon erzählt. Aber wie kann ich Leute identifizieren, die ein hohes Potential haben? Gleich vorweg: es ist weder der IQ noch der GMAT-Score, der einem da irgendwas hilft. Assessment Center sind dafür auch totaler Blödsinn. Die wichtige Eigenschaft ist: Neugier! Neugierige Menschen habe ich als Menschen mit Potential kennengelernt. Und als kommunikative Menschen, Neugier setzt Kommunikationsfähigkeit voraus. 20

21 Veränderung im Team sind ein heikles Thema. Oft bekomme ich zu hören: Probleme muss der ScrumMaster lösen, das Team muss stabil bleiben. Teamstabilität ist nicht gleichzusetzen mit dem Nichtverändern der Teamzusammensetzung! Teamstabilität bedeutet, Sustainable Pace. Ich habe dreimal Leute aus Teams nehmen lassen und mich einmal geweigert, jemanden ins Team aufzunehmen. Als ScrumMaster. Das fühlte sich nicht gut an 21

22 Wann muss man Leute aus dem Team nehmen? Erstens: Wenn jemand trotz Coaching die nötige Leistung nicht bringen kann, muss man ihn austauschen. Ich glaube fest, dass es richtige Aufgaben für jeden Mensch gibt. Aber: Nicht jeder Mensch hat für jede x-beliebige Aufgabe das gleiche Potential. Das zu erkennen ist gute Führung. Ein ScrumMaster muss dabei mit dem Management zusammenarbeiten, wenn ein High Performance Team entstehen soll. Zweitens: Wenn jemand kein agiles Mindset entwickeln kann, muss man ihn austauschen. Das kann auch bedeuten, dass man auf Qualifikationen im Team vorübergehend verzichtet. Vielleicht tut das mal kurz weh. Aber dauerhafte Störenfriede tun viel mehr weh. Das Team wird dann aber stabiler, das Vertrauen wächst und auch die Fähigkeiten. Und drittens ihr werdet es kaum glauben: Wenn jemand zu gut ist, sollte man ihn austauschen. Seniore Entwickler, graue Eminenzen, so gut sie sein mögen, bremsen oft ohne es zu wollen das Team in seiner Entwicklung. Ein Kollege wusste alles, war sogar im Urlaub erreichbar. Der stand kurz vor dem Burn Out, aber man wollte ihn nicht austauschen, weil das Team Angst hatte. Irgendwann hat es doch geklappt und das Team wurde produktiver. Ein Wunder? 22

23 23

24 Auch der ScrumMaster sollte nicht ewig beim Team bleiben. Irgendwann kann er dem Team nichts mehr geben. Das ist so, das kann man nicht ändern. Der ScrumMaster sollte dann gehen. Aber es sollte einen Nachfolger für den ScrumMaster geben, sonst 24

25 drohen Gefahren. Die drohen übrigens auch mit ScrumMaster. Zum Beispiel wird die Zuverlässigkeit des Teams, die hohe Produktivität, als normal empfunden. Es gibt Organisationen, die streichen dann die Stelle des ScrumMasters. Das ist selten dämlich, denn dann geht das Team kaputt. Habe ich zweimal erlebt. Auch das Team läuft Gefahr, die eigenen Produktivität als normal zu empfinden und hört auf, besser zu werden. Hier muss man gegensteuern. Und dann gibt es doch Momente, in denen was schief läuft. Die ganze Organisation steht Kopf und der neue Chief Executive Business Kasper führt Command & Control ein statt eine Retrospektive zu machen. Das kann ein High Performance Team zerstören, daran kann ein ganzes Unternehmen kaputt gehen. Das habe ich auch erlebt. Leider. 25

26 26