Agile Reifegrade und KPIs

Das Problem mit Maturity Models

Maturity models, Modelle zum Bestimmen von Reifegraden, können sinnvoll sein, um einen Prozess der (Selbst-)Reflektion anzustoßen:
wo stehen wir als Organisation eigentlich bei er Umsetzung von Agilität?

Oft jedoch werden diese Modelle für Metriken gehalten, weil der Reifegrad durch eine Zahl ausgedrückt wird. Diese Zahl ist aber tatsächlich nur eine subjektive Einschätzung auf einem hohen Abstraktionslevel – mit Fragen wie „Auf einer Skala von 1 bis 5, wie sehr ist unsere Personalabteilung ein Katalysator für Agile Transformation?“.

Unser Ansatz ist anders.

Zunächst einmal beziehen wir uns beim Begriff „Agil“ stets nur auf das Agile Manifest und seine 4 Wertepaare und 12 Prinzipien.

Zweitens fragen wir nach tatsächlich beobachtbaren und quantifizierbaren Sachverhalten (mit Bezug zum Agilen Manifest):

“Outcome (e.g. working & valuable software), delivered in short cycles”

  1. Was ist Eure Definition von „Auslieferung“/“Release“?
  2. Wann / wie oft habt Ihr in den vergangenen 3 Monaten Euer Projekt ausgeliefert?
  3. War es dabei in einem produktionsreifen Zustand??
  4. Was war debei die Gesamtzeitspanne, angefangen bei der Ideenfindung bis hin zur Auslieferung?
  5. Wann / wie oft habt Ihr in den letzten 3 Monaten das Gesamtsystem integriert?
  6. Wie viele einzelne Feedbacks von echten Anwendern habt Ihr in den vergangenen 3 Monaten erhalten?
  7. Wie viele davon sind in Euer Backlog eingeflossen?

„Welcome Change“

  1. Wann habt Ihr den letzten Change Request in Euer Project einfließen lassen?
    Wie viele waren es in den vergangenen 3 Monaten?
  2. Wie lange war die Gesamtumsetzungsdauer diese Changes, angefangen bei der Ideenfindung bis hin zur Auslieferung?

„Face-to-Face, Business & Development collaboration“

  1. Wann / wie oft in den vergangenen 4 Wochen hatten Entwickler und Fachexperten direkte Gespräche miteinander?
  2. Wann / wie oft haben Entwickler in den letzten 3 Monaten direkt mit Stakeholdern außerhalb ihres Teams zusammengearbeitet – Kunden/Endanwender, Fachexperten, BWLer etc.?

„Technical excellence“

  1. Wie bewertet Ihr den technischen Reifegrad in Eurem Projekt/Produkt – und auf welchen objektiven Daten / Metriken basiert diese Einschätzung?
  2. In Bezug auf die Changes in den den vergangenen 3 Monaten (siehe oben), wie viel Zeit wurde für die Implementierung verwendet?
  3. Von diesem Implementierungsaufwand wurde wie viel für die folgenden Tätigkeiten benötigt:
    1. bestehenden Source Code verstehen,
    2. bestehenden Source Code refaktorieren,
    3. um den bestehenden Code „herumarbeiten“?

„Sustainability“

  1. Wie viele Stunden habt Ihr in den vergangenen 3 Monaten wöchentlich gearbeitet?
  2. Wie viele Personen im Team können NICHT innerhalb von 4 Wochen durch einen Nachfolger ersetzt werden bzw. deren Wegfall durch Veränderungen im Team gleichwertig kompensiert werden?

„Self-organization“

  1. Wie viele Entscheidungen habt Ihr im Team in den vergangenen 3 Monaten getroffen?
  2. Wie viele davon wurden tatsächlich nur von einzelnen Personen getroffen, z.B. Scrum Master, Product Owner, Project Manager?
  3. Wie viele davon mussten zuvor von einer Person außerhalb des Teams freigegeben werden, z.B. Line Manager, Director of XYZ, CEO etc?
  4. Wie viele davon stehen in einem Spannungsverhältnis zu existierenden Richtlinien der Organisation oder sind nicht von ihnen abgedeckt?
  5. Wie viele davon sind konträr zur Meinung von Product Owner / Project Manager, Line Manager’s etc. oder anderen Stakeholdern außerhalb des Teams?

„Reflection“

  1. Wie oft habt Ihr im Team in den vergangenen 3 Monaten (Selbst-)Reflektion betrieben?
  2. Hatte das Team oder hatten Personen außerhalb des Teams in den vergangenen 3 Monaten mindestens 1x den Eindruck, dass das Projekt in einer schwierigen oder kritischen Situation war?
    Wenn ja, hat sich das Team dann zu einer außerordentlichen Reflection Session oder einem Stop-the-Line Meeting getroffen?
  3. Wie viele und welche Maßnahmen zur Verbesserung der Arbeit habt Ihr im Team in den vergangenen 3 Monaten ausprobiert?
  4. Wie viele Verbesserungsvorschläge wurden in den vergangenen 3 Monaten NICHT ausprobiert – und wurden stattdessen abgelehnt mit einer der folgenden Begründungen:
    1. Veto durch Product Owner, Scrum Master oder einen einzelnen Experten (z.B. der Architekt/Technical Lead)
    2. Veto durch einen Außenstehenden, z.B. Head of Department,
    3. Team befürchtete Widerstand von Außenstehenden und wollte die Konfrontation / die Arbeit vermeiden?
    4. Mangel an Zeit, Budget, Ressourcen

Image source: Tumisu from Pixabay