Ihnen nicht – Schon gar nicht der Organisation
So steht es geschrieben: So war es. Und jetzt? „Agile sucks“
- Individuen und Interaktionen über Prozesse und Tools
- Funktionierende Software über umfassende Dokumentation
- Zusammenarbeit mit Kunden über Vertragsverhandlungen
- Reagieren auf Veränderungen statt Befolgen eines Plans (hier weiter)
Dieses Manifest hat sich in jeden Winkel der modernen Unternehmenslandschaft eingeschlichen. Überall haben Unternehmen eine „agile Transformation“ durchlaufen, und auch heute noch folgen immer mehr. Und doch: Es ist ein Rückgang zu verzeichnen. Zweifel? Kritik? Ablehnung? Einige Manager sind nach wie vor und absolut verliebt in das Thema … Aber Entwickler hassen es. Das hat seinen Grund.
Moment, was?
Ja, entschiedene Kritik wird seit Jahren durch die Branche geflüstert, und es gibt eine Sache, die bei der überwiegenden Mehrheit wahr ist – sie kommt nicht von denen, die die Arbeit erleichtern, sondern von denen, die sie tatsächlich erledigen. Warum gibt es diese Diskrepanz?
Agilität ist eher eine Philosophie als ein starrer Prozess. Die Wahrscheinlichkeit, sich sehr gut mit einem durchschnitt-lichen Menschen über Philosophie zu unterhalten, ist faktisch geringer als mit einem Geisteswissenschaftler. Die Prozesse, die wir im Namen von Agile erfinden, sollen uns helfen, die Kernprinzipien des Manifests zu fördern, aber keiner ist darauf ausgelegt, Ihren Arbeitstag mit Gewalt zu diktieren.
In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und stimmt dann sein Verhalten entsprechend ab und passt es an.
In meiner Erfahrung habe ich immer wieder gesehen, dass Scrum mehr Herausforderungen mit sich bringt, als es löst. Ich könnte zwar argumentieren, aber ich würde es nicht unbedingt jedem raten, es ganz zu vermeiden. Mein Rat ist, das Team es ausprobieren zu lassen, wenn es möchte. Wenn es nicht klappt, besteht die agile Reaktion darin, den Prozess schnell zugunsten eines besser funktionierenden Prozesses fallen zu lassen oder ihn zumindest an die Vorlieben des Teams anzupassen.
„Agil … ist eine Einstellung, keine Technik mit Grenzen.“ — Alistair Cockburn
Darin liegt das Problem. Unternehmen wollen in der Regel alles von oben nach unten kontrollieren und begrüßen selten (wenn überhaupt) die Idee, dass Mitarbeiter (zuviel mitdenken und) das Unternehmen für sie leiten. Solange den an der Arbeit Beteiligten nicht die volle Kontrolle über den Prozess gewährt wird, hat eine echte „agile Transformation“ nicht stattgefunden sondern immer nur ein „so tun als ob.“ Mit anderen Worten, man könnte sagen, dass es zwei Varianten der Idee gibt: Ein „echtes“ Agile und „Unternehmens“-Agile.
Ich könnte den Artikel hier beenden, aber die Probleme, die sich aus dieser Tatsache ergeben, haben Wurzeln geschlagen und sich zu gefährlicheren Extremen ausgebreitet, die es wert sind, ins Rampenlicht gerückt zu werden. Damit sind wir bei der nächsten Stufe in der agilen Evolution von Unternehmen angelangt: SAFe.
Ganz Sicher. Sicher?
Das „Scaled Agile Framework“ (kurz SAFe) legt noch mehr Prozess-Overhead auf Scrum oder Kanban auf. Es werden Konzepte wie PI (Program Increment) Planung, ARTs (Agile Release Trains) und mehrere Hierarchieebenen vorgestellt. Mit anderen Worten, es bringt jeden Koch zur gleichen Zeit in die Küche (an den einen Herd) und erwartet, dass jeder von ihnen seine aktuellen Projekte und Zukunftspläne überprüft – was bedeutet, dass mehr Menschen als je zuvor mehr Zeit in Meetings verbringen und sie von der aktiven Arbeit abhalten. Es priorisiert die Vorhersehbarkeit und erfordert eine umfangreiche Planung für Monate im Voraus. Sicher, es mag schön sein zu sehen, woran andere Teams ab und zu arbeiten, aber am Ende des Tages ist der Wertgewinn im Vergleich zu den Kosten unbedeutend. Und da war doch noch was zum Thema Planen …
Die Ironie ist, dass bei der Skalierung kleine Ineffizienzen mit Ihnen wachsen. Kennen Sie, die IT Wesheit: „Shit in, shit out. More shit in, more …“ Was einst eine kleine Unannehmlichkeit war, wird mit einer größeren Belegschaft immer deutlicher, was das Unternehmen dazu veranlassen sollte, unproduktive Praktiken zu streichen. Genau das ist ja mein Thema. Als ob es komisch ineffizient wäre, macht aber SAFe das Gegenteil und erklärt sich selbst als „skalierbar“. Wirklich?
Schauen wir uns das noch einmal an.
- Individuen und Interaktionen über Prozesse und Tools (hier steht nichts von exessiven Planen)
- Eine Fülle von hohem Prozess-Overhead. Häufige Bereitstellung funktionierender Software
- Stunden, die für Besprechungen verloren gehen, während die Entwicklung angehalten wird.
- Reagieren auf Veränderungen statt Befolgen eines irre langen Plans (siehe weiter oben)
Betonung auf Vorhersehbarkeit und Planung.
Das meiste, was es zu SAFe macht, schafft es irgendwie, es gleichzeitig zum agilen Antichristen zu machen. Die ursprünglichen Autoren des Agilen Manifests mögen weniger extreme Worte haben, aber ich habe noch keinen von ihnen gesehen, der SAFe unterstützt, obwohl ich heftige Kritik von ihnen gesehen habe. Es war ein Prozess, der aus und in die Unternehmenswelt hinein geboren wurde; schon gar nicht bei Snowbird.
Gepaart mit all den irreführenden Leistungskennzahlen, die mit Boni und Entlassungen verbunden sind, verwandelt SAFe Ihr Unternehmen garantiert in eine Burnout-Fabrik. Und das ist eine ganz andere Dose der Pandorra …
Metriken: Kann man so oder so sehen
Wenn Sie jemals in Scrum gearbeitet haben, haben Sie Ihre Geschichten auf den Punkt gebracht. Lassen Sie uns darüber sprechen. Wir haben ein ganzes Verfeinerungsmeeting, das der Zuweisung von Punkten für Geschichten als Team gewidmet ist, was unweigerlich zu einer Menge Bikeshedding und letztendlich zu einer Zeitleiste führt. Ich denke, die meisten Teams verstehen, dass 5 Punkte nicht mit 5 Tagen gleichzusetzen sind, aber selbst sie, die Teams, erliegen mit der Zeit oft dieser Wahrnehmung. Punkte sollten dem Team helfen, einzuschätzen, ob eine Story klein genug ist, um diese zügig zu erledigen. Ihr Zweck war es nie, als Leistungskennzahlen oder Prognosetools zu dienen.
Einige argumentieren, dass die Verfeinerung des „Sprint-Pokers“ Diskussionen fördert, die Faktoren offenbaren, die bisher nicht berücksichtigt wurden. Vielleicht ist da etwas Wahres dran… Aber es ist nur präventiv. Die Diskussion findet entweder vor oder nach dem Start statt, aber es ist nicht so, dass sie nie stattfinden wird. Die Schätzung von Story Points dient nur dazu, den Start zu verzögern. Wir bereiten uns nicht in Agile vor, wir reagieren auf Vorgaben. Müssen Sie mir nicht glauben, Was Ron Jeffries zu diesem Thema zu sagen hat: “ … Schätzungen, sei es in Punkten oder Zeit, sind zu vermeiden.“ Wenn es jemals eine Autorität auf diesem Gebiet gäbe, dann wäre es der Typ, der die Story Points überhaupt erst erfunden hat.
„Das Schätzen von Aufgaben wird Sie verlangsamen. Tun Sie es nicht.“
— Jeff Sutherland, Erfinder von Scrum
Ich höre immer die übliche Antwort – mal mehr oder weniger laut: „Wenn wir unsere Geschichten nicht einschätzen, wie sollen wir dann unsere Geschwindigkeit verfolgen ??“ Darauf gebe ich zwei Antworten:
- Erstens können Sie die Geschichten einfach so zählen, als ob jede einen Punkt wert wäre. Dies bietet oft eine genauere Prognosemetrik, da historische Daten zuverlässiger sind als Spekulationen über die Zukunft. Die ganz Großen und die ganz Kleinen gleichen sich aus, vor allem, wenn das gleiche Team die Geschichten konsequent verfeinert. Im Idealfall sollte das Team wirklich gut darin werden, Geschichten so lange zu zerlegen, bis sie nur so lange wie möglich abgeschlossen sind.
- Zweitens ist die Geschwindigkeit nicht wichtig. Ich weiß, das mag kontrovers erscheinen, aber die Geschwindigkeit wird weder im Scrum-Leitfaden noch im Agilen Manifest ein einziges Mal erwähnt. Das wurde später (schlecht) drangeklebt! Es ist erst im Laufe der Zeit in der Community entstanden, und der allgemeine Konsens ist, dass es nur vom Team, für das Team verwendet werden sollte. Wenn die Geschwindigkeit für jemanden außerhalb des Teams wichtig ist, deutet dies auf einen Missbrauch der Metrik hin.
Um es noch einmal zu wiederholen: Die Geschwindigkeit ist als Leistungsmetrik nicht nützlich. Das Management glaubt so oft fälschlicherweise, dass die Geschwindigkeit eine Zahl ist, die verbessert werden muss, aber die Geschwindigkeit ist nicht etwas, das man bestimmt, sondern etwas, das man entdeckt. Seine einzige Funktion besteht darin, zu verstehen, wie viel Arbeit ein Team in einem Sprint sicher leisten kann – und das ist genau der Grund, warum ich es nicht für eine notwendige Kennzahl halte.
Anstatt uns auf eine bestimmte Menge an Arbeit innerhalb einer willkürlichen Zeitspanne festzulegen, sollten wir uns darauf konzentrieren, jeden Tag so viel qualitativ hochwertige Arbeit wie möglich zu leisten. Verpflichtungen tragen weder zur Verbesserung der Qualität noch zur Quantität der geleisteten Arbeit bei, aber sie könnten Druck ausüben, um Abstriche zu machen und die Tests in regelmäßigen Abständen zu überstürzen. Das bringt mich zurück zu meinen Vorbehalten gegenüber Scrum im Allgemeinen, aber ich schweife ab.
Es genügt zu sagen, dass Geschwindigkeit und Engagement ein ideales Umfeld für das Gedeihen toxischer Managementstile schaffen. Das soll nicht heißen, dass toxisches Management unvermeidlich ist, sondern nur, dass sich eine Person mit solchen Neigungen wie zu Hause fühlen wird.
Schlussfolgerung
Das wahre Konzept von Agile ist auch heute noch sehr aktuell. Im Kern geht es um kontinuierliche Verbesserung, Anpassungsfähigkeit und kleine Arbeit. Irgendwo begraben unter all den Prozessen und Metriken gibt es eine gute Idee, wo alles begann.
Es ist eine Schande, dass reine Ideen verwässert werden, nachdem sie durch die Unternehmensmaschinerie gefiltert wurden, was die Frage aufwirft, ob es für ein großes Unternehmen überhaupt möglich ist, die Idee im Geiste dessen zu übernehmen, was sie sein sollte. Oder vielleicht ist es eines dieser Konzepte, das in der Theorie großartig ist, aber niemand kann die letzte Barriere überwinden: den Menschen. Vielleicht ist das ein Artikel für ein anderes Mal…