„„Muss mit der Zeit besser werden.“ Das ist ein Statement, das, wenn ich das in meinen Seminaren sage, die Leute wirklich aufregt. Man kann wirklich sehen, wie sie getriggert werden, und dann habe ich meistens eine 20-minütige Diskussion. Und das ist gut, diese Diskussion zu führen, denn ich stehe dazu: Die Velocity sollte langfristig in einem Scrum Team nach oben gehen. Wenn dann die Diskussion entbrennt und ich gefragt werde, wie ich das denn begründe und wie ich denn dazu komme, drehe ich das meistens um und frage: „Warum sollte die Velocity eigentlich nicht nach oben gehen?“ Denn am Ende des Tages investiert die Organisation in die Rolle des Scrum Masters. Scrum Master, insbesondere gute, sind nicht billig. Das heißt, wir reden über eine Menge Geld, die da investiert wird, besonders wenn die Firma viele Scrum Teams hat und dementsprechend Scrum Master. Und die Aufgabe der Scrum Masters ist es ja, sich darum zu kümmern, das Team zu beschützen, das reibungslose Arbeiten zu ermöglichen, Impediments aus dem Weg zu räumen und so weiter. Das sind ja alles Faktoren, die die Produktivität steigern. Warum sollte sich das dann nicht in der Velocity, in der Produktivitätskennzahl, niederschlagen?

Der zweite Punkt ist: Wir haben eben diesen Fokus auf Impediment Removal, also das Beseitigen von Hindernissen, die uns verlangsamen. Möchten wir diese Hindernisse uminterpretieren in Chancen, schneller zu werden? Das heißt, wenn ich immer das Gebäude wechseln muss, um etwas auszudrucken, und wir dann auf die Idee kommen – so langweilig das Beispiel gerade ist – dass wir eigentlich den Drucker auf unserem Gang oder in unserem Team bräuchten, weil wir tatsächlichen Bedarf an Ausdrucken haben, dann ist das eine Produktivitätssteigerung, die sich hoffentlich irgendwann bemerkbar macht. Und das wird jetzt kein großer Effekt sein, aber die Summe der kleinen Effekte macht das halt aus.

Der dritte Punkt ist, dass wir eine Retro machen. Wir investieren zum Beispiel 90 Minuten alle zwei Wochen mit dem ganzen Team. Die könnten auch etwas anderes in der Zeit machen. Und wenn die Retro richtig gemacht ist, dann wollen wir doch, dass dort Probleme auf den Tisch kommen, dass sie ausgeräumt werden und dass auch Kaizen, also Selbstverbesserungs-Items, dort identifiziert werden. Und das ist auch mein letzter Punkt – es gibt wahrscheinlich noch eine ganze Menge mehr –, aber die Kaizens, diese Selbstverbesserungs-Items, kontinuierliche Verbesserungsprozesse, die sollen ja im Scrum gemacht werden. Es soll mindestens ein Kaizen-Item im Sprint gemacht werden. Viele Teams machen das eben nicht und deswegen werden sie auch nicht schneller. Tatsächlich können darüber hinaus noch weitere Kaizens gemacht werden. Das heißt, der Product Owner kann weitere einpriorisieren. Und das, wenn es denn möglich ist, wenn die sonstige Arbeit das zulässt, ist oft eine gute Entscheidung.

Und wenn man jetzt mal überlegt: Wir bezahlen extra eine Person, die dafür sorgen soll, dass wir schneller werden. Wir nehmen uns extra Zeit für Meetings, die nur diesen Zweck haben. Wir kümmern uns – und das heißt ja auch oft, Geld einzusetzen, nämlich den Drucker zu kaufen – darum, dass die Arbeitssituation verbessert wird. Und wir arbeiten an uns selbst in den Kaizens. Also zum Beispiel schicken wir die Leute auf teure Trainings, wir investieren in eine bessere IT-Infrastruktur und so weiter. Wenn wir all diese Dinge machen, die produktivitätssteigernd wirken, warum sollte dann eigentlich die Produktivität, in ihrer Kennzahl ausgedrückt, nicht nach oben gehen? Meine Antwort ist: Natürlich sollte sie das!

Und wenn es nicht passiert, ist es für mich als Coach ein riesen Warnsignal. Dann geht sofort bei mir die Lampe an, weil ich mich frage: Was ist denn da eigentlich los? Irgendetwas wird in dieser Prozesskette nicht richtig funktionieren. Und ganz oft ist das auch ein entscheidendes Merkmal dafür, für mich zumindest, ob dort Pseudo-Scrum gemacht wird. Alle haben die Titel Scrum Master, Product Owner, die Meetings werden auch gemacht, aber sie werden nicht richtig umgesetzt, sondern pro forma durchgeführt. Denjenigen, die das richtig machen und sich wirklich dahinter klemmen, sieht man dann auch die entsprechenden Produktivitätssteigerungen.

Jetzt gibt es zwei ganz wichtige Einschränkungen. Die erste Einschränkung ist: Wenn wir sagen, die Velocity soll nach oben gehen, meinen wir nicht in jedem Sprint, sondern wir sagen, es sollte ein positiver langfristiger Trend da sein. Es ist ganz normal, dass die Velocity fluktuiert, dass sie um ein zentrales Maß schwankt – das ist völlig normal. Teams haben gute und schlechte Sprints, Menschen haben gute und schlechte Tage. Aber langfristig sollte der Trend doch nach oben zeigen. Stellen Sie sich das mal vor, der Trend zeigt nicht nach oben, sondern nach unten. Da wären Sie doch auch in Alarmbereitschaft, um zu gucken, was in dem Team eigentlich los ist. Und auch ein gleichbleibender Trend ist nicht akzeptabel, wenn man kontinuierlich darin investiert, dass das Team besser, schneller und effektiver wird. Also Langfristigkeit ist das entscheidende Wort. Kurzfristig ist es kein Problem, aber langfristig sollte die Velocity nach oben gehen.

Die zweite wichtige Einschränkung ist Folgendes: Sie müssen diese Information sehr vorsichtig benutzen. Auf Englisch sagt man „to hold loosely“, also man sollte sie ganz leicht in der Hand halten. Denn was passieren würde, wenn Sie jetzt losgehen und in Ihrer Organisation bei Ihren Teams gucken und sehen, die Velocity steigt nicht, und Sie anfangen, zum Beispiel die Scrum Master anzuschreiben und zu sagen: „Okay, die Boni werden nur ausgezahlt, wenn die Velocity steigt“, wäre Folgendes: Die Schätzungen würden nach oben gehen. Es würde eine Schätzungsinflation stattfinden. Die Velocity würde steigen, aber Sie haben eigentlich nichts erreicht. Es wird nicht effektiver gearbeitet, sondern die Zahlen sind einfach nur beeinflusst worden. Und das muss gar nicht in böser Absicht geschehen – das ist einfach menschliches Verhalten.

Deswegen bitte, wenn Sie sowas sehen, dann sollten Sie das als Startpunkt für eine Unterhaltung nehmen. Wenn ich das als Coach sehe, gehe ich hin und frage: „Mir ist aufgefallen, dass die Velocity hier runter geht. Könnten wir uns mal drüber unterhalten, was dahinter liegen könnte, damit wir gucken können, ob wir das nicht abschalten können?“ Das könnte zum Beispiel sein, dass die Teamdynamik kaputt ist. Es könnte sein, dass sich tatsächlich nicht um Kaizens gekümmert wird. Es kann sein, dass die Scrum Master-Rolle nicht besetzt ist oder der Scrum Master sich um drei oder vier Teams kümmern soll und gar nicht genügend Kapazität hat. Aber die Grundsatzaussage stimmt trotz dieser zwei Einschränkungen: Die Velocity sollte langfristig nach oben gehen. Wenn sie das nicht tut, machen Sie kein richtiges Scrum. So kontrovers das auch ist.

Diese wie auch ähnliche fortgeschrittene Scrum-Konzepte und Themen zu Scale Business Agilität und mehr unterrichte ich regelmäßig in Seminaren. Wenn Sie daran Interesse haben, finden Sie mich auf teamflow.de.“