Hard-Agile: Durchsatz statt Velocity-Theater

Die Agile-Branche hat ein Problem

Irgendwann in den letzten zehn Jahren ist aus „funktionierende Software liefern” etwas anderes geworden. Etwas mit Zertifikaten, Happiness-Umfragen und Retrospektiven, in denen alle ihre Gefühle teilen, während das Backlog verrottet.

Wir nennen das Velocity-Theater.

Teams messen Story Points. Sie schätzen in Fibonacci-Zahlen. Sie feiern Sprint-Abschlüsse. Und am Ende des Quartals fragt das Management: „Warum ist das Feature immer noch nicht live?” Die Antwort ist eine Powerpoint-Folie mit einer steigenden Velocity-Kurve, die nichts bedeutet.

Velocity misst, wie viel ein Team sich selbst zutraut. Nicht, wie viel es liefert.

Wir haben das oft genug gesehen. Bei mittelständischen Softwarefirmen, bei internen Entwicklungsteams, bei Unternehmen, die „agil transformiert” wurden und danach langsamer waren als vorher. Das Problem ist nicht Agilität. Das Problem ist, was die Branche daraus gemacht hat.

Was wir stattdessen machen

Wir arbeiten nach dem, was wir Hard-Agile nennen. Das klingt provokant, ist aber einfach: Wir messen, was zählt. Keine abstrakten Punktesysteme. Keine relativen Schätzungen, die jedes Team anders interpretiert. Sondern Metriken, die jeder im Unternehmen versteht, vom Entwickler bis zum Geschäftsführer.

Durchsatz. Wie viele Aufgaben verlassen das System pro Woche? Nicht wie viele reinkommen. Nicht wie viele „in Progress” sind. Wie viele fertig sind.

Zykluszeit. Wie lange braucht eine Aufgabe von „angefangen” bis „ausgeliefert”? Nicht bis „fertig entwickelt”. Bis der Kunde es nutzen kann.

Fluss. Wo staut es sich? Wo warten Aufgaben auf Reviews? Wo blockiert eine Abhängigkeit alles andere?

Das ist die Kanban-Methode in ihrer reinen Form. Kein proprietäres Framework. Keine Zertifizierung. Keine zwei Tage Schulung, bevor irgendjemand anfängt zu arbeiten. Wir schauen uns an, was da ist, finden die Engpässe und machen es schneller.

Kanban beginnt mit dem, was da ist. Kein Big Bang. Kein „erst müssen wir alles umstellen”. Wir verbessern, was existiert.

Warum Scrum-Zeremonien oft nicht liefern

Scrum ist nicht schlecht. Scrum wird schlecht gemacht.

Zwei Wochen Sprint Planning. Daily Standups, die 45 Minuten dauern. Sprint Reviews, in denen das Team dem Product Owner erklärt, warum die Hälfte der Stories nicht fertig wurde. Dann eine Retrospektive, in der alle sagen, dass sie „bessere Kommunikation” brauchen.

Das Problem: Die Zeremonien werden zum Selbstzweck. Das Team verbringt 20 Prozent seiner Zeit mit Meetings über die Arbeit und 80 Prozent mit der Arbeit selbst, wenn es gut läuft. Oft ist das Verhältnis schlechter.

Wir streichen die Zeremonien nicht. Wir fragen bei jeder einzelnen: Trägt das zur Lieferung bei? Wenn ja, bleibt es. Wenn es ein Ritual ist, das niemand hinterfragt, weil „wir das halt so machen”, dann fällt es weg.

„Machen wir Scrum richtig?” ist die falsche Frage. Die richtige: „Liefern wir schneller als vor drei Monaten?” Wer sie nicht mit Zahlen beantworten kann, hat ein Messproblem. Und ein Messproblem ist ein Lieferproblem.

100-Tage-Zyklen statt endloser Sprints

Ein Sprint hat keinen natürlichen Endpunkt. Sprint 47 sieht aus wie Sprint 12. Niemand fragt: „Was haben wir in den letzten 47 Sprints eigentlich erreicht?”

Wir arbeiten in 100-Tage-Zyklen mit messbaren Zielen. Vor Tag 1 steht fest, was Erfolg bedeutet. Nach 80 Tagen messen wir: Ziele erreicht oder nicht? Kein Interpretationsspielraum. Zahlen.

Das verändert die Dynamik. Wenn das Team weiß, dass in 80 Tagen abgerechnet wird, fallen Diskussionen über Velocity-Punkte weg. Was zählt, ist: Liefern wir das, was wir versprochen haben?

Was bei Novadex passiert ist

Bei Novadex, einem Softwareunternehmen in Baden-Württemberg, haben wir die Entwicklungsorganisation umgebaut. SVN zu GitLab. Scrum zu Kanban. Bare Metal zu Kubernetes.

Das Ergebnis, das zählt: Zykluszeit auf 10 Tage reduziert.

Zehn Tage von „Aufgabe angefangen” bis „Feature beim Kunden”. Gemessen am laufenden System, Woche für Woche.

Das ist der Unterschied zwischen Velocity-Theater und Hard-Agile. Velocity hätte uns gesagt, dass das Team „52 Punkte pro Sprint” schafft. Was heißt das? Nichts. Zykluszeit sagt: In zehn Tagen ist es live. Das versteht jeder, auch das Management, das keine Ahnung hat, was ein Story Point ist, aber sehr genau weiß, was zehn Tage bedeuten.

Vorher war das Team gut. Danach war das Team schnell. Und das Team hat den neuen Prozess verinnerlicht, nicht bloß hingenommen, weil die Zahlen für sich sprechen. Kein Change Management nötig, wenn die Ergebnisse offensichtlich sind.

Das Rauschen abschalten

Die Agile-Branche hat ein Geschäftsmodell aus Zeremonien gebaut. Zertifizierungen. Coaching-Programme. Zwei-Tages-Workshops, nach denen sich alle besser fühlen und nichts anders machen.

Wir sind keine Agile Coaches. Wir kommen nicht, um Workshops zu geben, Retrospektiven zu moderieren oder Teams beizubringen, wie sie ihre Post-its besser sortieren.

Wir kommen, um zu messen, was geliefert wird. Um Engpässe zu finden. Um sie zu beseitigen. Und um nach 100 Tagen wieder zu gehen, weil das Team es jetzt selbst kann.

Alles andere ist Rauschen.