Donnerstag, 8. April 2021

Alternative Metriken für eine agile Transition

Bild: Wikimedia Commons / James Petts - CC BY-SA 2.0

Eigentlich sollte es gar nicht so schwer sein herauszufinden mit welchen Metriken sich der Erfolg einer agilen Transition validieren lässt. Einige davon hatte ich schon einmal aufgeschrieben, unter anderem kämen da Time to Market, Feedback Implementation Time, (Mean)Time to Recovery und Time to Process Adaption in Frage. Eine häufige Sorge ist dabei aber, dass sie alle dazu führen können, dass alle Erwartungen und Verantwortungen nur auf die unteren Hierarchieebenen abgewälzt werden.


Aufbauend darauf stellt sich die Frage, was für weitere Metriken es geben kann, an denen sich auch das Management messen lassen könnte. Ausgehend davon, dass es in der agilen Zielwelt unter anderem für die richtigen Rahmenbedingungen um möglichst autonome Teams zuständig sein wird wäre dieser Bereich ein naheliegender Ansatz. Und auch für diese Zielzustands-Rahmenbedingungen gibts bereits Definitionen: flache Hierarchien, wenige organisatorische Silos, möglichst wenige Abhängigkeiten.


Bevor das operationalisiert wird aber noch eine letzte Vorbemerkung. Da jeder Einzelfall immer einzigartig ist und da eine agile Zielorganisationen hohe Grenzwerte zulassen kann und muss sollte es sich bei allen folgenden Metriken um die Durchschnittszahlen der gesamten Organisation handeln. Dadurch bleiben Ausnahmen noch immer möglich, es kann aber nicht dazu kommen, dass sie zur Regel werden. Und jetzt in medias res, hier sind Ideen für die alternativen Transitions-Metriken:


I. Anzahl der Menschen die einem Product Owner eine Entscheidung untersagen können

Dass diese Zahl bei Null liegen könnte werden zwar nur Scrum-Fundamentalisten glauben, wie hoch sie im Ist-Zustand fast jeder grösseren Firma ist, ist aber selbst für deren Angehörige immer wieder erschreckend. Vorstände gehören dazu, verschiedene Bereichs-, Abteilungs-, Initiativen-, Programm- und Projektleiter, dazu meistens Fachabteilungs-, Produkt- und sonstige Manager sowie Angehörige der Vertriebs-, Anforderungsmanagement-, Rechts-, Datenschutz- und Compliance-Abteilungen. In Summe kommt so schnell eine mittlere zweistellige Personenzahl zusammen, die entweder Sitz in Lenkungs-Gremien oder Vetorecht hat. Ein gutes Transitionsziel kann sein, diese Zahl einstellig werden zu lassen.


II. Anzahl der Menschen die einem Team die Art der Umsetzung vorschreiben können

Auf den ersten Blick ein ähnlicher Fall, nur mit anderen Beteiligten, auf den zweiten mehr. Zu den disziplinarischen Vorgesetzten kommen hier die Architekten, Lead Developer, Test-, Release-, Integrations- und sonstigen IT-Manager, dazu aber auch andere Angehörige der unteren Hierarchie-Ebenen. Wenn andere Teams die selben Services und Komponeneten benutzen ist es schliesslich nur natürlich, dass sie Entscheidungen widersprechen dürfen von denen sie betroffen sind. Ein Transitionsziel auch diese Zahl einstellig werden zu lassen muss daher nicht nur zur Entflechtung von Mitspracherechten führen sondern auch zur Entflechtung von IT-Systemen.


III. Anzahl der organisatorischen Einheiten die beteiligt sein müssen um ein crossfunktionales Team zu bilden

Auch hier gilt: selbst für die Angehörigen grosser Firmen ist immer wieder erschreckend wie gross diese Zahl sein kann wenn End to End-Verantwortung erreicht werden soll. Der PO hängt im Produkt-, der Scrum Master im Projektmanagement, Entwickler in der Entwicklung, Tester in der QA, UXler, Release-Manager und Business Analysten können eigene Abteilungen haben und der Produktions-Betrieb wird oft sogar von eigenen Gesellschaften verantwortet. Alleine um das Customer-Vendor Antipattern zu vermeiden macht es Sinn hier die Zahl zu reduzieren. Das ideale Transitionsziel wäre eine Eins, aber auch eine niedrige einstellige Zahl wäre fast überall eine Verbesserung.


IV. Anzahl der Teams denen ein durchschnittlicher Mitarbeiter der Ausführungsebene gleichzeitig angehört

Ein Phänomen das häufig gemeinsam mit einem funktionalen Abteilungsschnitt auftritt ist die gleichzeitige Zugehörigkeit einzelner Personen zu mehreren Teams, z.B. wenn sich zwei UX-Designer auf mehr als zwei Projekte aufteilen müssen. Die dadurch entstehenden negativen Effekte (Terminkonflikte, Kontext-Wechsel, etc.) sind zwar bekannt, trotzdem sind in grossen Organisationen fünf bis zehn gleichzeitige Mitgliedschaften nicht ungewöhnlich. Da manche Hochspezialisierungen kaum vermeidbar sind (z.B. Juristen oder Penetrationstester) ist ein Transitionsziel von Eins zwar wenig realistisch, ein Durchschnittswert zwischen Eins und Zwei kann aber angestrebt werden.


V. Anzahl der Genehmigungsschritte die ein Team durchlaufen muss um mit einem Endkunden reden zu können

Auch hier kann mehr dahinterstecken als man zunächst ahnt. Das erste und offensichtlichste Hindernis sind natürlich andere Einheiten die bisher das Monopol auf den Endkundenkontakt hatten (häufig Vertrieb, Marketing und/oder Kundendienst), dazu kommt aber auch, dass in der Budgetierung von Entwicklungsteams meistens kein Posten für Kunden-Gespräche vorgesehen ist, bzw. dass dieser aufwändig beantragt und genehmigt werden muss. Ein gutes Transitionsziel in diesem Bereich wäre die Zahl Null, was in der Umsetzung nicht nur zum Abbau von Kommunikationsbarrieren führen würde sondern auch zum Ende von Micromanagement-Versuchen über das Budget.


VI. Anzahl der Genehmigungsschritte die ein Team durchlaufen muss um alle (!) Zahlen zum eigenen Produkt zu erhalten

Apropos Budget. Vor allem Finanz-Zahlen, aber auch Absatzmengen und Nutzungsdaten sind in vielen Firmen für die Entwicklungsteams gar nicht oder nur erschwert zugänglich. Wie aber soll ein Team Intrapreneurship (wirtschaftliches Denken und Handeln) eintwickeln wenn ihm weder bewusst ist welche Kosten es verursacht noch welche Umsätze und Gewinne es erwirtschaftet? Auch hier ist das ideale Transitionsziel die Zahl Null, aber selbst eine Reduzierung auf den niedrigen einstelligen Bereich würde fast überall ein deutliches Mehr an Transparenz und deutlich weniger Herrschaftswissen bedeuten.


Wie oben gesagt, das Erheben und gezielte Senken derartiger Zahlen kann ein wirkungsvoller Weg sein um zu verhindern, dass die Änderungs-Aufwände (bewusst oder unbewusst) ausschliesslich auf die Teamebene gewälzt werden. Wer so vorgeht kommt am Verändern der Rahmenbedingungen nicht vorbei - und das ist auch gut so, denn ohne das haben nur die wenigsten Transitionen eine wirkliche Aussicht auf Erfolg.

Montag, 5. April 2021

Agile Rhapsody

 Ich muss mich im voraus entschuldigen, an der einen oder anderen Stelle klingt dieses Lied ein kleines bisschen schief. Aber da müssen wir jetzt durch, denn was diese Damen und Herren aufgenommen haben ist eine Coverversion von Queens Bohemian Rhapsody, mit auf Scrum und Kanban umgedichteten Texten. Und diese Kombination kann nicht unbeachtet bleiben.



Ganz nebenbei: gefühlt gibt es auf dieser Seite mittlerweile schon so viele "Agile Lieder", dass ich fast über eine eigene Kategorie nachdenken könnte.