Agile Transformation: Ziele & Metrics

Nach einer Umfrage von Deloitte behaupten 76% der Befragten, dass ihre Organisation Agile Transformation Ziele nicht misst oder transparent macht.

In Anbetracht der Tatsache, dass fehlende Zielsetzung einer der häufigsten Gründe zum Scheitern einer agilen Transformation ist, scheint diese Zahl fatal.

Aber welche Ziele sollten Organisationen für eine agile Transformation eigentlich setzen – und noch viel wichtiger: Wie misst man diese?

In diesem Artikel helfen wir Ihnen ihre Ziele zu definieren und entsprechende KPI’s zu finden.

Agile Transformation Ziele & Metrics | scagile Blog

Inhalt dieses Artikels

Warum Ziele in der agilen Transformation so wichtig sind

Agile Transformationen werden in der Regel nicht grundlos unternommen, obwohl es hier leider immer wieder Ausnahmen gibt. Die Gründe sind aber nicht immer eine „burning platform“, also der unmittelbar bevorstehende Ruin des Unternehmens, um es mal in seiner dramatischten Form auszudrücken 

Scheitern bedeutet die Spanne vom Nichterreichen primärer Ziele bis hin zum Verschlimmern der Situation. 

Sehr oft ist es aber einfach nur, dass es insgesamt nicht wesentlich besser geworden ist.

In einem meiner agile Coaching Projekte erwartete man von mir eine fünfzehn-prozentige Verbesserung und meinte damit eine Kosteneinsparung. Ich entgegnete, dass man dafür keine agile Transformation beginnt, dafür würde es genügen, etwas Overhead abzubauen. Gleichermaßen wurde hier der Aufwand einer agilen Transformation unterschätzt sowie der Kontext einer solchen Transformation missverstanden.  

Und damit sind wir schon beim ersten „agile transformation fail“:

Keine klaren und angemessene Ziele 

Aber im Ernst, es gibt zwei Ziele, die für eine agile Transformation formuliert werden sollten.  

Das eine Ziel bezieht sich auf das Business Outcome (NICHT output), während das zweite Ziel sich auf die Transformation selbst beziehen sollte.  Denn man kann nicht sagen, dass mit der Erreichung des ersten Zieles, automatisch auch das zweite erreicht ist (und umgekehrt). Denn im zweiten Ziel geht es insbesondere um die Nachhaltigkeit eines vollzogenen Kulturwandels, der ein gutes Business Outcome auch für die längere Zukunft sichern soll. 

Denn unglücklicherweise wird Scrum immer dann als Methodik gewählt, wenn – aus welchen Gründen auch immer (z.B. zu hohe Komplexität der Anforderungen, time-2-market Anforderungen) – eine hinreichende Spezifikation des zu erstellenden Gegenstandes nicht vorliegt, aber die Zeit drängt.

In vielen Organisationen, die in eine agile Transformation gegangen sind, wurden die Ziele oft nicht sehr klar definiert, bzw. bezogen sich sehr oft lediglich auf den Output 

Die Zielvorstellungwir möchten unsere Lieferfähigkeit verbessernist zwar ein netter Ansatz, aber noch weit davon entfernt, eine klare Zielsetzung zu definieren 

Auch die output-bezogenen Zielewir möchten unsere Produkte schneller liefern und günstiger produzierenklingen zwar sehr naheliegend, sind aber auch noch ein gutes Stück entfernt von einer klaren Zieldefinition einer agilen Transformation 

Sie drücken eher aus, dass der Impact einer agilen Transformation für die gesamte Kultur einer Organisation erheblich unterschätzt wird.

Dies hat dann zur Folge, dass die agile Transformation deutlich zu kurz greift und sich in der Umorganisation von Arbeitsprozessen erschöpft, sie also endet, wo sie eigentlich beginnen sollte. 

Ziele geben eine klare Orientierung, damit ein meinetwegen wetterbedingter vorübergehend besserer Output nicht schon mit dem Erreichen von Transformationszielen verwechselt wird.  

Es ist wesentlich besser, ein ambitioniertes Ziel zu haben und es nicht (ganz) zu erreichen, als auf klare Ziele zu verzichten und sich dann auch den geringsten Fortschritt schönzureden 

Klare Ziele werden leider oft immer mit klassischem Projektmanagement verwechselt und es wird so getan, dass agil überhaupt keine klaren und verbindlichen Aussagen treffen kann oder soll. Schon das Einführen von „Agile Transformation Zielen“ und konsequenter Weise damit das Nachhalten der Ziele mit der Definition einer „Agile Transformation Metric“ oder zumindest dem Definieren von KPIs für die agile Transformation wird oft beargwöhnt und als transformationsschädlich empfunden.

Das ist falsch und rührt vermutlich immer noch daher, dass eine agile Transformation als eine Art basisdemokratischer bottom-up Evolutionsprozess gesehen wird. Daher werden agile Transformationen heute top-down strategisch geplant und geführt. 

Agil bedeutet proaktiv adaptiv

und damit ist einerseits die Reichweite der Aussagen begrenzt (adaptiv) und es wird die Möglichkeit eingeschlossen, die Aussagen regelmäßig zu überprüfen (proaktiv) und begründet (!) an die Realität anzupassen.

Begründetbedeutet, dass dies nicht beliebig geschieht, sondern schon sehr genau die Umgebung beobachtet wird und Ursachen analysiert werden. Ja, das Potential, sich dabei selbst in die Tasche zu lügen lässt sich nicht leugnen. Daher ist es sogar um so wichtiger, Ziele zu haben und möglichst mit klaren und quantifizierbaren KPIs zu belegen 

Solche Agile Transformation Ziele nicht zu haben, kommt dem Verlust an Orientierung und Kontext gleich 

Organisationen fällt es dann schwer auszumachen, wo und wie sie sich verbessern können bzw. ob sie überhaupt auf einem guten Weg sind.

Die Definition von „Agile Transformation Ziele“ ist also eine Grundvoraussetzung, um in der Organisation Klarheit darüber zu gewinnen, worauf die nicht unerheblichen Mühen und Kosten einer agilen Transformation hinauslaufen sollen. Und selbstverständlich gehören zu den Transformations-Zielen dann auch das Aufsetzen von „agile transformation metrics“, um den Grad der Zielerreichung auch nachhalten zu können.  

So, nun zu den beiden Zielen selbst. 

Business Outcome Ziele

Business Outcome im Gegensatz zu output sind eher strategische Ziele, welche auf eine Unternehmenskultur abzielen.

Oder sie zielen direkt auf die Generierung von Business-Value ab, was nicht so unterschiedlich ist, den eine agile Unternehmenskultur soll ja genau „Business Agility“ und „Customer Centricity“ in den Fokus stellen.

Ja richtig gelesen, Business Outcome ist ein Ergebnis einer bestimmten Unternehmenskultur und eben nicht ein irgendwie zu erreichendes Ziel, mit welchen Mitteln auch immer. Denn ein konstanter und nachhaltiger Flow von Value lässt sich nur erreichen, wenn die gesamte Unternehmenskultur darauf abgestimmt ist. Das lässt sich nicht in einzelne Abteilungen oder auf vereinzelte agile Teams delegieren. Ein Blick unten auf mögliche Ziele für Business Outcome und deren KPIs illustriert das und lässt erahnen, wie komplex die Erhöhung von Business Outcome werden kann.  

Beispiele für Business Outcome Ziele: 

  • Wie messen wir Kundenzufriedenheit? KPIs hierfür wären zum Beispiel:
    1. Customer Satisfaction Score 
    2. Customer Effort Score  
    3. Net Promoter Score 
  • Wie organisieren wir permanentes Kundenfeedback? 
  • Wie lassen wir alle Unternehmensteile an all dem teilhaben, etc.? 
  • Wie verkürzen wir Feedback-Schleifen zwischen Endkunden und Implementierungsteams? 
  • Wir möchten genau die Feature implementieren oder verbessern, die von Kunden am Meisten gewünscht oder verwendet werden. KPIs dafür wären zum Beispiel: 
    1. Applicability: Feature X wird von mehr als Y% der User verwendet 
    2. Utilization: Verwendung von Features pro Tag/Woche/Monat 
  • Wie etablieren wir eine BizDevOps(Sec)-Kultur? 
  • Wir organisieren wir agile Demand Management? 
  • Verwenden wir Priorisierungsmethoden, wie zum Beispiel WSJF (weighted shortest job first) auf allen Programmebenen? 
  • KPI’s, die Time-to-Market unterstützen wären zum Beispiel: 
    1. Deployment Umfang und Frequenz 
    2. Trend von technical Dept 
    3. Cumulative Flow Diagram (CFD) 
    4. Lead Time – Zeit von der Definition bis zur Lieferung eines Features 

Es ist in der Tat gar nicht so leicht, für solche strategischen Business Outcome Ziele geeignete KPIs zu definieren. Und selbstverständlich müssen die Ziele immer mal wieder angepasst oder neu definiert werden, z.B. jedes Business Jahr einen Schwerpunkt legen.  

Aber stellen Sie sich vor, wenn solche Ziele im Rahmen einer agilen Transformation gar nicht erst definiert werden. Im SAFe – Jargon könnte man dann sagen:  

„Ohne solche Ziele werden die ART’s von heute, die Silos von morgen“

Bzw. die agile Organisation degradiert sich selbst zu einer reinen output-getriebenen Feature-Factory. 

Priorisieren mit der WSJF Methode [+ Excel Template]

Mit der WSJF Methode werden PI Plannings zum Kinderspiel und effektiver als je zuvor. Hier geht's zum kostenlosen Step-by-Step Guide und WSJF Excel Template

Ziele für die Agile Transformation selbst

Ziele für die agile Transformation selbst sollen sicherstellen, dass das ganze Unterfangen nachhaltig ist.

Agile Transformationen brauchen Zeit, oft dauern sie Jahre. Über die Zeit ist die Gefahr groß, den Fokus zu verlieren. Auch hier bieten klare Ziele entlang einer definierten Roadmap die notwendige Orientierungshilfe.  

Wenn sich das Business-Outcome nicht so recht einstellen möchte, dann hilft oft ein Blick auf die Ziele der agilen Transformation selbst, zu erkennen, was möglicherweise schief läuft. 

Ziele für eine agile Transformation zu definieren ist recht einfach, sie in KPIs auszudrücken und dann zu messen, ist dagegen sehr komplex. 

Vermutlich ist das einer der Gründe, warum viele Organisationen davon absehen. Nichtsdestotrotz lohnt sich die Mühe bzw. ohne solche Ziele driften agile Transformation – schon wegen ihrer Dauer – oft nach einigen Monaten in eine gewisse Beliebigkeit und bleiben auf einer formalen Ebenenämlich der Einrichtung von Rollen, Events und Artefaktenhängen 

Beispiele für Ziele der agilen Transformation: 

Dafür haben wir 7 Faktoren beschrieben (Vision, Domainwissen, Cross-Funktionalität, Hard Skills, Soft Skills, Empowerment, Akzeptanz). Artikel folgt in Kürze.

KPI hierfür wären zum Beispiel

  • Auf Team-Ebene sollte die Sprint-Accuracy >90% betragen 
  • Auf (SAFe)ART-Ebene sollte die PI Objektive Accuracy > 80% betragen 

Ein heißes Thema 

  • Wie viele business-relevante Entscheidungen werden z.B. im ART (SAFe) selbst getroffen? 
  • Wie viele Hierarchie-Ebenen/Instanzen sind im Entscheidungs-/Approval Prozess involviert?

KPI hierfür wären zum Beispiel: 

  • Frequenz von Retrosepktiven bzw. Inspect- und Adaptsessions auf Team- bzw. auf (SAFe) ART-Ebene 
  • Wie viele der dort definierten Action-Items werden tatsächlich umgesetzt  
  • Nehmen Sie sich regelmäßig Zeit für Verbesserungen an der Infrastruktur, der Architektur oder des Produktes im Allgemeinen? 
  • Ration von Improvement Enabler zu Business Feature 
  • Haben Sie in jeder Iteration ein Innovation- und Planning Sprint? 

KPIs für dieses Ziel wären zum Beispiel: 

  • Häufigkeit von Scope Changes während einer Iteration 
  • Wie oft werden Iterations-Ziele während einer Iteration (z.B. Sprint) obsolet? 
  • Sprint Accuracy sollte >90% sein 
  • Mitarbeiter-Fluktuation sollte <5% sein 

Die Agile Transformation hat also ganz eigene Herausforderungen, neben dem, was sie eigentlich tun soll: Die Business Outcome Ziele zu unterstützen. Dennoch bleibt die agile Transformation das Werkzeug und ist nicht selbst der Zweck. Erst die Koppelung der Business-Ziele mit den Möglichkeiten des Werkzeugs Agile-Transformation, welches richtiger Handhabung bedarf bringt das Unternehmen ans Ziel. Da die Beherrschung dieses Werkzeugs bzw. des Handwerks alles andere als trivial ist, haben wir diesem Thema noch einen eigenen Artikel gewidmet.  

Fazit

Ziele sollen nicht den Druck erhöhen, sondern Kontext geben und Orientierung schaffen 

Insbesondere in agilen Transformationen, die als Kulturwandel recht lange dauern können, benötigen wir eine „continuous learning culture“ und der tut es gut, sich an klaren Zielen mit quantifizierbaren KPIs zu orientieren. Die Einführung von „agile Transformation Goals“ und dazu das Bereitstellen einer „agile Transformation Metric“ mit klaren KPIs für agile Transformation sind also kein Widerspruch zum agilen Mindset, sondern ein Mittel durch Klarheit, Bestimmtheit und Transparenz ein solches zu fördern. Das Messen des Erfolges einer agilen Transformation ist nicht weniger wichtig als das Messen des Erfolges der Unternehmung.  

Gibt es solche Ziele und Metriken nicht, droht eine agile Transformation recht schnell in Zufriedenheit auf niedrigem Niveau mit ein paar wenigen verbesserten Outputs zu versanden.

Die App für scaled agile Teams ist da!

Klicke, um Artikel mit den gleichen Tags zu zeigen:

Klaus Riedel
Als agile Coach begleitete Klaus Riedel mit seinem Team die digitale Transformation und die Einführung von Scrum und SAFe in großen Organisationen wie Deutsche Bank, Conrad Electronics, Volkswagen, PWC und anderen.

Alle seine gewonnenen praktischen Erfahrungen in mehr als 15 Jahren agile Transformation sind in die Artikel seines Blogs eingeflossen.

In der Scagile Academy bildet er Nachwuchs Agile Experts aus und seit 2016 unterrichtet er agiles Projektmanagement an der deutschen Fakultät der TU Sofia.

Mehr interessante Artikel für dich: