Agile Metrics - Prowareness Gmbh Coaching und Arbeiten mit Agile-Teams ausgew£¤hlt...

download Agile Metrics - Prowareness Gmbh Coaching und Arbeiten mit Agile-Teams ausgew£¤hlt haben. Wir halten

of 13

  • date post

    15-Jun-2020
  • Category

    Documents

  • view

    0
  • download

    0

Embed Size (px)

Transcript of Agile Metrics - Prowareness Gmbh Coaching und Arbeiten mit Agile-Teams ausgew£¤hlt...

  • Agile Metrics Lassen wir die Zahlen sprechen

  • Inhalt

    Die wichtigste Frage, die bei der Scrum-Einführung zu beantworten ist 3

    Wie zufrieden sind unser Scrum-Team und die Stakeholder? 6

    Verbessern wir laufend unsere Teamreife? 7

    Sind unsere Entwicklungsbemühungen abgestimmt mit dem Geschäftsbetrieb? 9

    Erhöhen wir die Menge der abgelieferten Arbeit? 10

    Entspricht die Qualität der Norm? 12

    Zusammenfassung 13

    Anhänge 14

  • Einführung

    Ob wir uns dessen bewusst sind oder nicht, wir alle messen täglich etwas. Wenn wir am Morgen ins Auto steigen, schauen wir auf den Tacho, um nicht zu schnell zu fahren; wir steigen ab und zu auf eine Waage, um unser Gewicht zu kontrollieren; Lehrer und Mitschüler haben unsere Fähigkeiten von früh an beurteilt; die Liste ließe sich beliebig fortsetzen. Warum messen wir also etwas? Wir messen, damit wir etwas unternehmen können für den Fall, dass das Gemessene nicht mit dem Erwarteten oder Gewünschten übereinstimmt. Das bringt uns zum Hauptthema dieses Artikels: Messergebnisse bzw. Kennzahlen sollten immer in Maßnahmen umgesetzt werden können. Es sollte klar sein, was die gemessenen Daten bedeuten und es sollte klar sein, welche Maßnahmen man aufgrund der Daten ergreift. Es gibt Hunderte von Maß- und Kennzahlen für Softwareentwicklung und Scrum und nicht alle sind sinnvoll.

    Kennzahlen sollten ein Kernelement eines jeden (Software-)Entwicklungsprozesses sein. Dankenswerterweise macht Scrum mit seinen

    iterativen Grundzügen das Sammeln dieser Kennzahlen und die entsprechende Reaktion darauf extrem einfach. In diesem Artikel möchten wir dem Leser Kennzahlen an die Hand geben, die wir aufgrund unserer langjährigen Erfahrung im Coaching und Arbeiten mit Agile-Teams ausgewählt haben. Wir halten diese Auswahl nicht für abschließend. Die Kennzahlen, die ein Agile-Team verwenden sollte, hängt vom jeweiligen Kontext ab. Hier möchten wir dem Leser einen Einblick für den Anfang geben.

    Die wichtigste Frage, die bei der Scrum- Einführung zu beantworten ist

    Wir brauchen ein strukturiertes Vorgehen, um aus der Liste aller von uns über die Jahre erstellten Kennzahlen eine Minimalgruppe zusammenzustellen. Es gibt verschiedene Modelle wie man die Auswahl von Kennzahlen trifft, um Softwareeigenschaften zu bewerten. Ein häufig genutzter Ansatz ist das „Goal QuestionMetric (GQM)“. Er entstammt der Forschung bei der Fehlerauswertung im NASA Goddard Space Flight Center im Jahr 19841. Er wurde angepasst und dient als Qualitätsverbesserungsmethode in der Softwareentwicklung.

    Kurz gesagt bricht der GQM-Ansatz die qualitativen Kennzahlen von oben nach unten herunter; ein Unternehmen muß bestimmte Ziele erreichen, die Kennzahlen sollten zeigen, ob man diese Ziele erreicht hat oder nicht und sie sollten in der Lage sein, das Unternehmen anzuleiten wie man diese Ziele erreichen kann2.

    Ein Ziel wird in ein bestimmtes Format ab geschichtet, sodass es einen Zweck, ein Thema, das Objekt bzw. der Prozess des Fokus und den Blickwinkel, wozu oder zu wem das Ziel in Beziehung steht, enthält. Bestimmte Fragen werden ausgewählt, die den Kontext des Ziels setzen. Wenn diese Fragen beantwortet wurden, sollten wir wissen, ob das Ziel erreicht worden ist. Die Kennzahlen geben die Antwort auf diese Fragen.

    Nehmen wir als anschauliches Beispiel das Ziel einer Banking App für ein mobiles Endgerät: Verbessere die wahrgenommene Antwortbereitschaft der mobilen Banking App vom Standpunkt des Nutzers aus.

    Figure 1, A breakdown of a GQM goal.

  • Eine Frage, die wir mit diesem Ziel verbinden könnten, wäre: „Was ist die Beziehung zwischen der Hochfahrzeit und der wahrgenommenen Antwortbereitschaft?“. Die Kennzahl, die wir hier verwenden würden, wäre die Hochfahrzeit jeder Iteration des bisherigen Produkts und die Antwortbereitschaft wie sie von den Nutzern der App beurteilt wird. Eine andere Frage, die man mit dem Ziel verbinden könnte, wäre: „Wie schnell lassen sich die Apps des Wettbewerbs hochfahren?“. Möglicherweise ist das das Kriterium nach dem die Nutzer die App beurteilen.

    Wir müssen also ein Ziel für die Benützung von Scrum-Kennzahlen stecken. Warum wollen wir unseren Scrum-Prozess messen? Warum lesen Sie diesen Artikel? Wir denken, dass dieses Ziel ungefähr so beschrieben werden kann: Um die Ergebnisse der Scrum-Implementierung aus Sicht des Business zu verbessern. Natürlich ist eine Scrum-Implementierung vielschichtig und wir müssen sicherstellen, dass unsere Auswahl an Kennzahlen alle Aspekte der Scrum- Implementierung abdeckt. Die Fragen, die wir mit unserem Ziel verbinden, müssen ebenfalls dieser Vielschichtigkeit Rechnung tragen.

    Wir haben diese Aspekte, die Hauptbereiche einer Scrum-Implementierung, in die folgenden Fragen übersetzt: Zufriedenheit der Stakeholder (Wie zufrieden sind unsere Kunden? Wie zufrieden ist das Team?), die Reife des Teams (Verbessern wir

    uns laufend?), der Abgleich mit dem Business (Liegt der Fokus auf der Wertsteigerung des Business?), und die Menge und Qualität der übergebenen Arbeit.

    Diese fünf Hauptbereiche sind gegenseitig verknüpft: es ergibt keinen Sinn, auf eine Steigerung der Produktivität zu setzen (Quantität), wenn es einen Verlust an Qualität bedeutet. Ebenso, wenn man hochwertige Arbeit übergibt (Abgleich mit Business), sie aber nicht mit Wissenstransfer verbindet (Reife), dann ist es vielleicht auf kurze Sicht nützlich, wird einen aber auf längere Sicht schaden. Und Zufriedenheit ist natürlich generell eine Eigenschaft, die immer erreicht werden soll. Wir haben eine Liste an Fragen definiert, die unser Ziel mit dem GQM-Modell zusammenbringt:

    • Wie zufrieden sind das Scrum-Team und die Stakeholder? • Verbessern wir uns laufend? • Ist unsere Entwicklungsarbeit gleichgerichtet mit dem Business? • Steigern wir die Menge an Arbeit, die wir übergeben? • Paßt die Qualität der Arbeit zu der Norm?

    Die folgenden Absätze beschreiben die Kennzahlen, die wir vorschlagen, um obige Fragen zu beantworten. Es gibt selbstverständlich weitaus mehr Kennzahlen als diejenigen, die wir im folgenden vorstellen werden. Das Ziel ist, die

    Figure 2, this paper’s goal and questions visualized.

  • Anzahl überschaubar, aber abschließend zu halten im Hinblick auf die Hauptbereiche von Scrum. Es muß außerdem eine ursächliche Beziehung zwischen einer Kennzahl und der Leistung eines Teams oder eines Unternehmens bestehen. Die Auswertung der Antworten bei der Messung helfen eine Liste an Verbesserungen zu erstellen. Diese Verbesserungen wiederum sollten zu besseren Ergebnissen führen.

    Wie zufrieden sind unser Scrum-Team und die Stakeholder?

    Wir messen Zufriedenheit aus zwei Perspektiven, der Angebots- und Nachfrageseite. Das Scrum- Team ist in diesem Fall die Angebotsseite. Wir

    verwenden die Kennzahl „Teammitglieder- Zufriedenheit“ für die Angebotsseite und „Net Promoter Score“ (NPS) für das Business, die Nachfrageseite in diesem Fall. (Siehe Anhang A mit einer Zusammenfassung dieser Kennzahlen.)

    „Teammitglieder-Zufriedenheit“ ist für uns eine wichtige Kennzahl, weil Dinge die während der Entwicklung gut oder schief laufen sich fast immer auf die Zufriedenheit der damit Befassten auswirken. „Teammitglieder-Zufriedenheit“ wird üblicherweise am Ende eines Sprints erhoben. Fünf Post-it werden an einer Wand befestigt. Jedes Teammitglied wird gebeten, einen Sticker neben ein numeriertes Post-it zu heften, das der gegenwärtigen Zufriedenheit entspricht, wobei 1 = sehr unzufrieden und 5 = sehr zufrieden bedeutet. Jedes Teammitglied wird außerdem gebeten, vorzutragen, was zur Steigerung der Zufriedenheit beim nächsten Sprint getan werden müßte. Dieser

    Aspekt macht die Zufriedenheitskennzahl besonders tatkräftig und trotzdem leichtgängig. Üblicherweise braucht man nicht besonders viel Zeit, um die latenten Schwierigkeiten bzw. funktionierende Dinge in den Blickpunkt zu rücken.

    Abbildung 3 zeigt Messwerte der Zufriedenheitskennzahl, die von einem Scrum- Coach im Verlauf von 15 Sprints gesammelt wurden. Beachten Sie die Tiefpunkte bei Sprint 1 und 12 und die kleineren Dellen bei Sprint 5 und 9. Ohne weitere Informationen kann man diese Messwerte nicht aufklären. Bei Sprint 1 lag es daran, dass Scrum gerade losging, was beim Team Anlaß zu große Befürchtungen und Stress auslöste. Der Tiefpunkt bei Sprint 12 lag daran, dass etliche Teammitglieder krank gemeldet waren und das Team daher nicht in der Lage war, den Sprint erfolgreich abzuschließen. Die Sprints 5 und 9 markieren die Fertigstellung eines Release. Sobald der Release näher rückt, fangen die Teammitglieder an, Stress zu empfinden. Die Auswertung dieser Daten erfordert dieses Hintergrundwissen, ansonsten kann man die Zahlen der Abbildung nicht verstehen.

    NPS ist eine Kennzahl, die von vielen Unternehmen in unterschiedlichen Bereichen angewendet wird. Während „Teammitglieder-Zufriedenheit“ sich auf das Scrum-Team bezieht, fokussiert NPS auf den

    Kunden. Es wird verwendet, um auszumachen wie wahrscheinlich der Kunde ein Produkt weiterempfehlen würde. Dies wird als Hauptindikator für Kundenzufriedenheit gesehen. Die Kunden bzw. Stakeholder benoten die Teamleistung auf

    Figure 3, a Happiness metric spanning 15 sprints.

    Figure 4, The Net Promotor Score of a team

  • einer Skala von 1 bis 10. Bewertungen von 8 und höher werden gewöhnli