Der Weg ist das Ziel: Metriken als Wegweiser statt als Erfolgsmeldung einer agilen Transition

Wir wollen in diesem Blogpost unsere Erfahrungen mit Metriken zur Bewertung einer agilen Transition teilen. Speziell geht es uns um die Motivation, Stabilität und Aussagekraft solcher Metriken in einer Transition. Deshalb betrachten wir Metriken wie z. B. Velocity oder Durchlaufzeit nur exemplarisch und erläutern, wo die Fallstricke beim Einsatz dieser Metriken liegen.

Mit Transition meinen wir größere Veränderungsprozesse, die Auswirkungen auf den Entwicklungsprozess und dessen Organisation haben, wie z. B. Änderungen der Architektur und Erhöhung technischer Exzellenz als auch Änderungen im Anforderungsmanagement, Vorgehensmodell oder Teamschnitt.

Die Ausgangssituation der Transition beschreiben wir nur grob, da sie je Kunde spezifisch ist und es für unser Thema nur auf eine grundsätzliche Betrachtung ankommt.

Wir betrachten Metriken, die den Entwicklungsprozess detailliert von innen betrachten. Diese sind gut geeignet, um Teams ihr Verbesserungspotenzial aufzuzeigen. Die Basis dieser Metriken unterliegt aber in der Regel genau den Veränderungen, die zur gewünschten Verbesserung des Entwicklungsprozesses führen.

Situation

Wir helfen oft Kunden, die eine Kombination von Problemen haben – Unklarheiten in der Anforderungsaufnahme, mangelnde Qualität, Probleme mit der Planbarkeit bzw. mit der Liefertreue, unberechenbare und sehr langsame Liefergeschwindigkeit. Gemeinsam mit dem Kunden erarbeiten wir eine Zielrichtung. Wir machen uns ein übergreifendes Bild vom Ist-Zustand des betroffenen Bereichs. Partizipativ identifizieren wir in einem kontinuierlichen Verbesserungsprozess mögliche Lösungsansätze und helfen dem Kunden, diese Schritt für Schritt umzusetzen.

Gegen Ende unseres Engagements kommt nicht selten das Management auf uns zu und verlangt nach Metriken. Es braucht die Zahlen, um den Erfolg der Maßnahme gegenüber Dritten zu belegen bzw. zu rechtfertigen. Um einen Ausgangspunkt für einen Vergleich am Ende zu erhalten, müssen Metriken von Anfang an erhoben werden. Die Festlegung auf Metriken schon am Anfang einer Veränderung ist jedoch eine große Herausforderung.

Orientierungsnotwendigkeit

Zu Beginn weiß der Kunde oft nicht, was genau verbessert werden soll, die Ziele sind ihm noch unklar. Und auch wir müssen uns erst ein Bild über den Bereich des Unternehmens machen, um den es in unserem Auftrag geht. Der Kunde berichtet uns zwar von Problemen, die er aus seiner Sicht wahrnimmt – für ein klares Bild müssen wir die Situation aber aus unterschiedlichen Blickwinkeln beleuchten. Anhand des Bildes müssen wir verstehen, was genau geändert werden muss und warum. Erst wenn wir mit dem Kunden ein Ziel definieren, können wir Metriken für die Veränderung ableiten.

Leidensdruck

Der Kunde hat zu Beginn einen starken Leidensdruck und drängt aufgrund seiner Situation massiv zu Lösungen. Die Verbesserung ist wichtiger als ihre Dokumentation. Das Aufstellen und Erheben von Metriken tritt dadurch in den Hintergrund. Wenn wir die Ausgangssituation aber nicht durch Metriken belegen, können wir später, wenn der Leidensdruck dem Druck, Erfolg zu melden, weicht, keinen Vergleich mehr ziehen. Eine objektive Bewertung der Veränderung ist dann nicht mehr möglich.

Wenn das Ziel feststeht und wir sinnvolle Metriken aufstellen wollen, stoßen wir in der Praxis gerade in der Anfangsphase von Veränderungen auf einige Herausforderungen.

Herausforderungen beim Finden und Gestalten von Metriken

Die Basis einer Messung muss stabil bleiben

Damit man später nicht Äpfel mit Birnen vergleicht, muss die Basis einer Messung über die Zeit stabil bleiben.

Nehmen wir zum Beispiel an, dass wir mit unseren Veränderungen den gesamten Entwicklungsprozess verbessern wollen. Hierzu schauen wir uns exemplarisch die Durchlaufzeit (Lead Time) von Anforderungen an.

Die Anforderungen, die wir vorfinden, sind meistens auf technische Komponenten zugeschnitten. In dieser Form zeigen sie den direkten Kundennutzen nicht mehr auf. Die Summe dieser technischen Anforderungen ergibt eine viel zu umfangreiche Kundenanforderung. Sie entspricht oft schon einem kleinen Kundenprojekt. Auf dieser Ebene zu messen bringt in der Regel nichts für den zeitlichen Rahmen, in dem das Management einen Erfolg melden muss.

Im Gegensatz zur technischen Anforderung beschreibt eine fachliche Anforderung eine einzelne Funktionalität und damit direkt einen Kundennutzen. Die Durchlaufzeit dieser Anforderung zeigt also Wert pro Zeit auf. Der Wechsel von technischer zu fachlicher Erfassung von Anforderungen verändert die Basis unserer Metrik. Die Vergleichbarkeit der beiden Messungen geht hierbei verloren.

Die Fähigkeit, fachliche Anforderungen möglichst klein zu schneiden, entwickelt sich erst im Laufe des Verbesserungsprozesses. Auch ist die Menge der Anforderungen relevant, die aufgrund der Umstellung zu fachlichen Formulierungen umgeschrieben bzw. neu erfasst werden müssen. Hier sehen wir also eine Verbesserung der Durchlaufzeit über die Zeit. Der Zeitpunkt, wann dieser Effekt sichtbar wird, kann für die Erfolgsmeldung zu spät sein.

Wenn POs technische Anforderungen fachlich neu formulieren und schneiden, dann muss der Kunde auch seine Organisation entsprechend anpassen. Das Unternehmen muss die Organisation also auf Feature-Teams statt auf Komponenten-Teams aufbauen. Bleibt die Umsetzung in Komponenten-Teams, werden Synchronisations- und Übergabezeiträume schnell zum bestimmenden Faktor der Entwicklungsgeschwindigkeit. Leider ändert der Umbau der Organisation auch die Basis der Metrik und die Messungen sind nicht mehr vergleichbar.

Metriken müssen möglichst objektiv sein

Für eine gute Aussagekraft müssen wir die Metrik so wählen, dass das Unternehmen möglichst objektiv und nicht manipulierbar messen kann.

Wenn wir zum Beispiel die Entwicklungsgeschwindigkeit messen wollen, dann wird hierzu gerne die Team Velocity verwendet. Diese Metrik ist nur gut genug, wenn sie teamintern verwendet wird, und zwar im Zusammenhang mit anderen Metriken. Diese müssen z. B. sicherstellen, dass die Geschwindigkeit nicht auf Kosten der Softwarequalität oder durch viele Überstunden entsteht. Währenddessen muss mit jeder Anforderung Wert an den Kunden geliefert werden.

Wenn die Velocity über geschätzte Story-Punkte des Teams entsteht, dann ist für die Interpretation der Metrik die Lernkurve des Teams zu beachten. Alternativ zum Schätzen mithilfe von Story-Punkten können auch Anforderungen gezählt werden bzw. die Durchlaufzeit im Team pro Anforderung (Cycle Time) gemessen werden.

Die Stabilität des Teams beeinflusst ebenfalls die Geschwindigkeit und ist ein Faktor, auf den das Team meistens keinen direkten Einfluss hat. Bei Veränderungen eines Teams braucht es z. B. Zeit, um die volle Leistungsfähigkeit zu erreichen. Das Team muss sich erst finden und durchläuft daher Tuckmans Phasenmodell : Forming, Storming, Norming, Performing.

Von außen gesehen ist die Velocity in Story-Punkten nur sehr bedingt aussagekräftig. Bei einem stetig hohen Verbesserungsdruck kann das Team auch hier die höhere Geschwindigkeit ohne Verbesserung des Prozesses erreichen. Die Mitarbeiter können z. B. Überstunden machen, ihr Schätzverhalten ändern oder auf Kosten der Qualität schneller liefern, um der Erwartung gerecht zu werden. Alternativ könnte der Geschäftswert der Anforderungen außerhalb des Teams bestimmt werden. Dies würde eher zu einer objektiven Metrik führen, auch wenn natürlich auch dieser Wert manipuliert werden kann.

Metriken müssen leicht erfassbar sein

Für eine stabile Messung über die Zeit müssen Metriken leicht genug erfassbar sein, damit die Messung auch unter viel Druck lückenlos und sicher gelingen kann. Unserer Erfahrung nach können selbst scheinbar einfache Metriken in der Implementierung alles andere als trivial sein.

Wir können z. B. beschließen, die Wiederherstellungszeit für einen Dienst (time to restore service ) zu messen, um die Stabilität der Software zu beurteilen. Hier geht es um die Zeit, die benötigt wird, um eine Störung beim Kunden zu beheben (von Meldung der Störung bis zur Behebung). Die Schwierigkeit liegt hier in der Erfassung der Messungen. Oft ist es bei unseren Kunden so, dass Mitarbeiter Störungen auf sehr unterschiedlichen Wegen an das Team kommunizieren – auch gerne mal am Backlog vorbei. Somit müssen sich alle Beteiligten so disziplinieren, dass eine gemeinsame Erfassung gelingt. Und auch die Frage nach der Behebung der Störung kann herausfordernd sein, wenn z. B. die eigentliche Installation und Aktivierung von Änderungen ausschließlich durch den Endkunden erfolgt.
Generell kann man sagen, dass die Messung umso sicherer zum Scheitern verurteilt ist, je umständlicher die Erfassung von Messdaten ist.

Metriken müssen motivierend und neutral sein

Metriken müssen für die betroffenen Personengruppen motivierend sein. Es ist schwierig, wenn anhand der Metrik jemand konkret bewertet und indirekt angegriffen wird. Es darf kein rückwärts gerichteter Rechtfertigungsdruck entstehen, sondern es braucht den Blick nach vorne als Motivation zur Verbesserung. Um motivierend zu sein und zu bleiben, müssen Metriken neutral und aussagekräftig sein. Gerade auch Niederlagen unterstützen bei richtig geformten Metriken den Erkenntnisgewinn, da Teams in der Softwareentwicklung im Bereich des Komplexen unterwegs sind. Hier müssen sie empirisch und experimentell vorgehen, um sinnvoll zu navigieren. Eine Metrik muss unterstützen und nicht nur bewerten.

Zur Teamentwicklung müssen die Metriken in erster Linie Verhaltensweisen und nicht Ergebnisse belohnen. Gesteckte Ziele sollen herausfordern, aber trotzdem erreichbar sein. Und bei dem, was das Unternehmen misst, müssen die Nutzer der Metrik den Zusammenhang zwischen ihrer Handlung und dem Effekt möglichst direkt erkennen. In einem solchen Kontext steigt das intrinsische Interesse daran, die Messungen als Indikatoren zur Verbesserung der eigenen Arbeit heranzuziehen. Wenn ein Team aus besseren Zahlen einen direkten Zusammenhang zu seiner konkreten Situation erkennen kann, indem es diese Verbesserungen in seiner Arbeit spürt, dann steigen Motivation und Engagement.

Bezogen auf den Motivationsaspekt können wir auch hier gut auf das Beispiel der Team Velocity zurückgreifen. Wenn das Management seine Teams unter hohem Druck alleine auf Basis ihrer Velocity bewertet und miteinander vergleicht, dann ist für Betroffene die Versuchung groß, Zahlen einfach dahin zu bringen, wo alle sie haben wollen. Ein Fortschritt im Team wird dann nicht erreicht. Hier ist die Frustration aller Betroffenen garantiert.

Erfolgsdruck einer Veränderung

Bei Metriken zum Messen des Erfolgs einer Veränderung ist die Motivation des Managements ein wichtiger Aspekt. Wenn ein Manager den Erfolg melden MUSS, dann werden Metriken zu Druckmitteln. Die betroffenen Mitarbeiter können die Zahlen entweder manipulieren oder sich frustriert zurückziehen. Der Sinn, eine Metrik als motivierenden Indikator zu verstehen, geht so verloren.

Unter diesen Umständen geht es dem Management hauptsächlich um die nackten Zahlen, die allerdings im Auge des Betrachters zu einer starken Vereinfachung der realen komplexen Situation führen. Ohne eine adäquate Interpretation sind diese Zahlen nichts mehr wert und können sogar eine gesunde Entwicklung des Unternehmens behindern.

Wenn hinzukommt, dass Veränderungserfolg in einem im Voraus bestimmten und vom Sachverhalt losgelösten Zeitintervall gemeldet werden muss, dann wächst der Rechtfertigungsdruck extrem. Im hierarchischen Gefälle CEO – CTO – (Scrum Master –) Team wächst der Druck nach unten. (Der Scrum Master ist zwar offiziell nicht Teil der Hierarchie, wird aber gerne als Teamleiter missbraucht, um gewünschte Metriken durchzusetzen und anschließend zu rechtfertigen.) Der extreme Druck nach unten ist kontraproduktiv und wirkt dem von uns angestrebten Servant Leadership entgegen.

Kennzahlen und erreichte Ziele können ein großer Motivationsverstärker sein. Richtig eingesetzt sorgen kleine Wettbewerbe, Siege und Niederlagen für persönliches und unternehmerisches Wachstum. Für ein hohes Engagement aller Teilnehmer, sich während der Veränderung von Metriken leiten zu lassen, müssen die betroffenen Mitarbeiter beim Ausarbeiten und Aufstellen der Metriken direkt mitgestalten. Da Metriken die reale Situation stark vereinfacht abbilden, müssen die Beteiligten verstehen, was hinter ihren Metriken steckt und dass es in erster Linie um die angestrebte Verbesserung geht und nicht um eine Kontrolle von außen. Die Mitarbeiter können so an viele Aspekte der Messung gleichzeitig denken, weil jeder diese aus seinem eigenen Blickwinkel beurteilt und formt.

Fazit

Aus dem Kontext einer Veränderung heraus sind Metriken wichtige Wegweiser für alle Betroffenen. Das Aufstellen und Messen von geeigneten und aussagekräftigen Metriken ist in vielen Fällen sehr herausfordernd. In jeder Phase der Veränderung können sie sinnvolle Hinweise geben. Als Erfolgsmeldung sind sie allerdings mit Vorsicht zu betrachten, da die Basis, auf der wir die Metriken erheben können, nicht grundsätzlich über die Zeit stabil bleibt. Der Vergleich und damit die Bewertung der Transition ist also nicht leicht darzustellen.
Wir haben hier bewusst Metriken betrachtet, die zur Verbesserung des Prozesses verwendet werden können, da sie konkrete Rückschlüsse auf operative Handlungsfelder zulassen.

Für die Bewertung und strategische Steuerung auf Unternehmensebene eignen sich eher Metriken, die das Ergebnis der Produktion oder die Kundensicht betrachten. Sie nehmen also eher eine Außensicht ein und versprechen eine deutlich bessere Stabilität. Der direkte Bezug zur Operative und damit zur konkreten Steuerung der Verbesserungen ist allerdings schwierig. Und signifikante Auswirkungen der Veränderungen auf diese Metriken werden erst mit einer großen Zeitverzögerung sichtbar.

Sehr wichtig und am Ende auch ausschlaggebend ist vor allem die Motivation, die hinter diesen Metriken steckt, da vor allem ihre Interpretation zählt. Die entkoppelte Bewertung von dritten und besonders von hierarchisch höher gestellten Personen ist kontraproduktiv. Metriken entfalten dann eine gute Wirkung, wenn Betroffene sie selbst zur Verbesserung aufstellen und benutzen.

Ein Team von Coaches unterstützt bei der Umstellung

Eine agile Tranisition ist für jedes Unternehmen eine große Herausforderung. Um diesen Wandel bestmöglich zu unterstützen, arbeiten wir am besten mit einem Team von Coaches mit unterschiedlichen Schwerpunkten. Beim Aufbau agiler Rahmenbedingungen und selbstorganisierter Teams helfen Agile Coaches. Sie können ihr Wirken mit Product Coaches und Technical Coaches abstimmen und dadurch eine ganzheitliche Wirkung über die Bereiche hinweg erzielen.

• Agile Coaches begleiten den Aufbau agiler Rahmenbedingungen und selbstorganisierter Teams.
• Product Coaches unterstützen bei der Ausrichtung des Produkts und dem Umgang mit Anforderungen.
• Technical Coaches helfen den Teams bei der praktischen Umsetzung agiler Softwareentwicklung und Architekturfragen.

Zusammen behält das Coach-Team den Überblick und unterstützt das Management, ihre Strategie im Veränderungsprozess zu verfolgen. Mit dieser breitgefächerten Unterstützung und Beratung helfen wir unseren Kunden bei der Skalierung in allen Bereichen ihres Unternehmens.