Die agile Geschwindigkeitslüge

“Mein Auftrag ist es, hier Geschwindigkeit reinzubringen!” Mit diesen markigen Worten wird die Agile Transition in so manch einer Firma eingeläutet. Das häufige Ergebnis: Die Fluktuation beim Personal steigt und die versprochenen Zuwächse an Produktivität bleiben aus. Genau mit dieser Aussage wird agiles Arbeiten oft verkauft: Agile Methoden sollen Tempo in vermeintlich lahme Organisationen bringen. Mit solchen Verheißungen wird dem Auftraggeber nicht nur zu viel versprochen, sondern er wird in die Irre geführt und der wahren Chancen der agilen Arbeit beraubt. Ich nenne das die agile Geschwindigkeitslüge! Aber wie kam es überhaupt dazu, dass agile Arbeit so falsch interpretiert wird? Wie kann es sein, dass agiles Arbeiten oft mit Schnelligkeit gleichgesetzt wird?

Die Kunst der Erledigung doppelter Arbeit in der halben Zeit

Agilität ist mittlerweile ein Management-Hype. So unerträglich, dass ich bereits “Stoppt Agilität”¹ proklamiert habe. Natürlich sagt der Begriff “Agilität” an sich schon etwas aus: Behende, beweglich und schnell, all das ist mit dem Adjektiv agil gemeint. Und die Erfinder von Scrum setzten mit Ihrem Bestseller, “Scrum, The Art of Doing Twice the Work in Half the Time” auch noch einen drauf. Das ist doch mal was: Die doppelte Arbeit in der Hälfte der Zeit? Der Entscheider rechnet zügig durch: “Aha, also 300% Steigerung der Effizienz? Das klingt doch wirklich gut, das machen wir jetzt auch.”

Zusätzlich werden im agilen Kontext auch oft Sport-Metaphern genutzt. Scrum als Begriff ist dem Rugby entlehnt, Sprint u.a. eine Disziplin in der Leichtathletik und Velocity ist ein anderes Wort für Geschwindigkeit. Es ist also wenig überraschend, dass agile Methoden häufig über einen Geschwindigkeitsvorteil verkauft werden.

Aber ist Geschwindigkeit bei agilen Methoden wirklich das Ziel oder nicht eher das Ergebnis einer besseren Arbeitsweise? Bohren wir dazu etwas tiefer und schauen auf den Begriff “Velocity”, einer der Kern-Metriken agiler Methoden und Scrum.

Die agile Metrik Velocity

Die Velocity ist eine der bekanntesten Metriken in agilen Methoden. Worum geht es? Mit der Velocity misst ein Team, wie viel Arbeit in einem Sprint erledigt wird. Die Arbeit selbst misst das Team in Story Points oder Aufwandspunkten. Die Story Points geben pro Anforderung oder User Story den ungefähren Aufwand zur Erledigung an. Im Laufe der Sprints, so jedenfalls die Theorie, pendelt sich eine konstante Team-Velocity ein. Also eine Art “Geschwindigkeit” mit der das Team seine Aufgaben abarbeitet und unterwegs ist.

Das klingt erst einmal richtig gut: Eine Kennzahl, die die Geschwindigkeit eines Teams misst? Für den unbedarften Manager ist es jetzt naheliegend Nägel mit Köpfen zu machen. Kann ich diese Metrik nicht einfach auf alle Teams anwenden? Wie ist die Velocity von Team A gegenüber Team B? Warum bricht die Velocity in Team C ein? Wer ist daran Schuld? Und überhaupt, wie kann ich die Velocity möglichst kontinuierlich steigern? Gerade zu dem letzten Punkt gibt es unzählige Artikel im Netz. Oft werden diese Beiträge übrigens von Tool-Herstellern geschrieben, die Ihre Produkte verkaufen wollen. So hat bspw. im Jahr 2016 der Tool-Hersteller VersionOne etwas blauäugig folgende Statistik veröffentlicht²:

Woran erkennen Sie den Erfolg in agilen Projekten?

VersionOne fragte seine Kunden: Wie messt ihr den Erfolg in agilen Projekten? Das Ergebnis ist für mich niederschmetternd: Mit klaren Abstand war die tägliche Prüfung der Team-Velocity auf Platz 1. Auf den Plätzen zwei und drei stand die Kontrolle der BurnDown-Charts, was die Sache auch nicht viel besser macht, wenn damit die Geschwindigkeit der Abarbeitung kontrolliert wird. Die aus meiner Sicht erste direkt nutzbare Metrik, “Work in Progress”, rangierte auf Platz 8.³ 

Kundennutzen in Qualität statt Geschwindigkeit

Warum ist die Velocity oder das Denken in Geschwindigkeit überhaupt gefährlich? Die Velocity führt nicht nur dazu, dass reine Quantität gemessen wird. Es ist viel schlimmer: Wenn Druck zur Erhöhung der Velocity ausgeübt wird, dann wird schlechte Arbeit belohnt. Der Entwickler schreibt einfach weniger Tests, arbeitet nachlässiger und schon erhöht sich die Velocity. Und wenn es bei Agilität um eines überhaupt nicht geht, dann ist das die Steigerung des Outputs bis hin zu Nonsens. Es geht um die Generierung von Kundennutzen in Qualität. Der Kundennutzen lässt sich aber nicht in Story Points messen.

Übrigens: Das agile Framework SAFe treibt das Thema Velocity auf eine unrühmliche Spitze: Dort gibt es sogar “normalisierte” Story Points, damit sich teamübergreifend alle Äpfel und Birnen vergleichen lassen.

Ein gut funktionierendes Team ist wie eine gute Band

Scrum und agile Methoden können durchaus Ihre Projekte schneller machen. Geschwindigkeit oder viel mehr Produktivität ist aber eher ein mögliches Ergebnis und nicht das Ziel von agiler Arbeit. Zunächst einmal macht Scrum die Dinge sogar etwas langsamer: Daily Standups, Refinement, Planning und die Retrospektive, all diese Meetings kosten ganz viel Kraft und Zeit. Scrum spielt seine Stärken erst aus, wenn Ruhe herrscht und das Team im Gleichklang arbeiten kann. Wenn Developer, Scrum Master und Product Owner am gleichen Strang ziehen und ihren eigenen Rhythmus für das Team gefunden haben. Ja, ich bin sogar der Meinung, das Ganze hat sogar etwas mit Musik und Harmonie zu tun. Es geht nicht darum, schneller zu werden, es geht darum harmonischer zu werden. Die Messung Velocity sollte nur eines bezwecken: Das Team soll seinen Rhythmus und seine eigene Geschwindigkeit entdecken.

Und wie kommt die von Jeff Sutherland versprochene erhöhte Produktivität zustande? Wie kommt es zur doppelten Menge an Ergebnissen in der Hälfte der Zeit? Ganz einfach, in dem Ruhe herrscht und ein optimal zusammengestelltes Team Schutz, Zeit und Klarheit gewinnt, die richtigen Entscheidungen zu treffen. Das ist der Kern des Ganzen: Gute und geradezu spitzenmäßige Arbeit basierend auf bestmöglichen Entscheidungen. Und bestmögliche Entscheidungen entstehen durch kurze Intervalle und direktes Feedback der Beteiligten.

Das Anti-Dopamin: Wenn du es eilig hast, gehe langsam

Ich plädiere daher für Folgendes: Wenn Sie wirklich agil und produktiv mit Ihrem Team arbeiten wollen, dann gehen Sie lieber langsamer und ruhiger vor. Ignorieren Sie als Manager Metriken wie die Velocity. Interessieren Sie sich bitte überhaupt nicht dafür, wie viele Stories ihr Team schafft oder nicht schafft. Achten Sie lieber auf eine gute Zusammensetzung des Teams, auf Struktur, Rhythmus und ungestörtes Arbeiten. Interessieren Sie sich für die inhaltliche Arbeit ihrer Teams, denn Nichts demotiviert Teams mehr als Führungskräfte, die Produkte keines Blickes würdigen. Ich verspreche Ihnen, die gewünschte Geschwindigkeit und Performance stellt sich ganz von allein ein. Und vielleicht brauchen Sie dazu noch nicht einmal Scrum. Und wenn ein Berater sagt: “Mein Auftrag ist es, hier Geschwindigkeit reinzubringen!”, dann jagen Sie ihn bitte zum Teufel. Entschuldigung!

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie den wöchentlichen Newsletter von t2informatik mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Buchtipp: It Doesn’t Have to Be Crazy at Work

Zum Schluss möchte ich einen Buchtipp geben. Leider gibt es das Buch derzeit nur in Englisch verfügbar, aber ich bin überzeugt, dass es bald auch in Deutsch erscheint. Jason Fried und David Heinemeier Hansson sind Geschäftsführer der Firma Basecamp und haben schon die sehr erfolgreichen Bücher Rework und Remote geschrieben.

In Ihrem neuesten Buch It Doesn’t Have to Be Crazy at Work beschreiben die Autoren, warum ruhige und kontinuierliche Arbeit langfristig erfolgreicher als Projektstress, Fristen oder der Versuch, die Geschwindigkeit von Teams zu steigern, ist. Die Grundaussage ist fast schon banal: Lasst die Leute in Ruhe arbeiten und stört sie bitte nicht. Übrigens wird bei Basecamp auch agil gearbeitet, aber nicht in Form von Scrum.

[1] Stoppt Agilität – Blogbeitrag über Agilität und den Agilitätswahn
[2] Ron Jeffries beschäftigte sich intensiv mit der Grafik von VersionOne: Do you want Crappy Agile?
[3] Alle aufgeführten Metriken haben eine gute und schlechte Seite. Richtig eingesetzt ist die Velocity für das Team in der Selbsteinschätzung sehr hilfreich. Die Kundenzufriedenheit (customer satisfaction) ist hilfreich, benötigt aber sehr viel Übersetzung, damit das Team daraus konkrete Maßnahmen ableiten kann. Auch die Metrik Work in Progress kann missbraucht werden, wenn damit beispielsweise die Auslastung aller Mitglieder im Team angestrebt wird.
[4] Normalisierte Story Points in SAFe

Dies ist der zweite Teil der Triologie von André Claaßen zur agilen Arbeit. Der erste Teil ist der bereits erwähnte Artikel „Stoppt Agilität“. Der dritte Teil heißt „Der agile Etikettenschwindel“.

Und hier finden Sie weitere Beiträge von André Claaßen im t2informatik Blog:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.