Data-driven Scrum Master*in

Wenn man sich eine*n Scrum Master*in vorstellt, scheinen Zahlen und Daten eher nebensächlich im Arbeitsalltag. Der Fokus liegt doch eher auf der Unterstützung des Teams, dem Enablement, dem Coaching, dem offenen Ohr und dem Vermitteln von agilen Werten und Arbeitsweisen. Man könnte also schlussfolgern, dass es eher um sogenannte softe Faktoren in diesem Beruf geht, aber stimmt das auch? 

Die Liberators haben die Funktionen und Rollen eines Scrum Masters / einer Scrum Masterin sehr gut in dieser Grafik abgebildet https://medium.com/the-liberators/my-journey-as-a-scrum-master-75d95cb4a54d : 

Alle Rollen haben ihren Nutzen und ihre Berechtigung in der Arbeit eines Scrum Masters / einer Scrum Masterin. Und sicherlich legt jeder / jede in Abhängigkeit des Teams und der Organisation den Fokus etwas anders. Wenn wir über Daten, Zahlen und das Tracking bestimmter Kennzahlen sprechen, fokussieren wir wohl am ehesten den Anteil des Managers innerhalb unserer Rolle.  

Doch auch die Erfahrung zeigt, dass sich viele Scrum Master*innen bewusst entscheiden, der Manager-Rolle weniger Gewicht zu geben als den anderen Rollen. 

Welche Daten sollten aus welchem Grund getrackt werden?

Um uns dem Thema mal vorsichtig zu nähern, sollten wir zuallererst wohl die Frage beantworten, welche Daten überhaupt getrackt und betrachtet werden sollen und zu welchem Zweck dies erfolgt. Die Antwort müssen wir hier eher vage formulieren, denn das hängt sicherlich von der jeweiligen Organisationsform ab. Mögliche Werte wären natürlich Zahlen, die zur Berechnung der Velocity eines Teams nutzen. Aber auch konkreter, wie sich Story Points und somit Schätzungen in einem Team verteilen und über die Zeit entwickeln. Anders gesagt: Wie sicher und aussagekräftig werden Teams in der Schätzung ihrer Tickets? Wie routiniert und gekonnt können sie mit Unsicherheiten umgehen und somit ihr Commitment gegenüber den Stakeholdern einhalten? 

An dieser Stelle kann die Diskussion leicht in eine Richtung abschwenken, in der wir mal wieder über das Verhältnis von Story Points und einer zeitlichen Dimension sprechen und dass diese durchaus kontrovers ist, wissen wir alle. Story Points sollen gerade nicht nur den zeitlichen Aufwand darstellen, sonst könnten wir auch einfach PTs oder Stunden für unsere Schätzung nehmen. Die Frage ist nur, ob es wirklich und ehrlich möglich ist, sich auch bei den Story Points ganz von dieser zeitlichen Komponente zu befreien? Wir glauben nein.  

Zahlen dienen dazu, Realitäten abzubilden

Es mag kontrollierend wirken, aber Zahlen können vor allem auch Realitäten klar abbilden, die dem Einzelnen und dem Team auch sehr helfen können. Es geht im agilen Arbeiten viel um das Thema der Eigenverantwortung – Individuen und Teams übernehmen eine Verantwortung für das was sie tun und schaffen. Genau hierbei können Zahlen auch unterstützen und konkretere Anhaltspunkte geben. Ein Team in Watte zu packen, um es vor auch eventuell unangenehmen Zahlen zu schützen (schlechte Performance…) widerspricht aus unserer Sicht den agilen Werten von Transparenz und Commitment. Was hierbei sicherlich wichtig ist, ist der Umgang mit diesen Realitäten. Es ist genau dieser Punkt, bei dem die Rolle der Scrum Master*in zum Einsatz kommt und dem Team hilft eine Arbeitskultur und Atmosphäre zu schaffen, in dem Fehler und Erfolge ehrlich betrachtet werden können, ohne in Fingerpointing zu verfallen.  

Überspitzt gesagt, kann es ein schmaler Grat sein zwischen dem gemeinsamen Analysieren der Velocity (also wie viele Story Points/Tickets das Team pro Sprint oder über mehrere Sprints hinweg geschafft hat) und dem Gedanken gläserne Mitarbeiter*innen zu schaffen, deren gesamte Arbeit durch Zahlen gemessen wird und allen offen zugänglich ist. Zweiteres Szenario ist sicherlich nicht sonderlich förderlich für die Teamdynamik und das Wir-Gefühl. Hier wäre mit dem jeweiligen Team zu schauen, welche Zahlen ihnen helfen, sich in ihrer Arbeit und Geschwindigkeit zu verbessern und welche eher hinderlich ist. Wichtig ist es auch hier die Frage zu stellen, wem die Zahlen nutzen sollen, dem Team, der Organisation oder vielleicht beiden?  

Ist der Product Owner nicht eigentlich für Zahlen und Daten zuständig?

Stellt man die Rollen von PO und Scrum Master gegenüber, kann sicherlich auch der Einwand kommen, dass Zahlen und Daten doch eher in den Bereich des POs fallen, da diese Rolle ja “ergebnisverantwortlich für die Maximierung des Wertes des Produkts” ist, wie der Scrum Guide sagt. Doch sich als Scrum Master*in hinter diese einfache Position zurückzuziehen, ist aus unserer Sicht recht kurz gegriffen und führt an vielen Stellen eher dazu, dass Probleme und kritische Themen eben nicht angesprochen werden.

Hier sollte auch der/die Scrum Master*in die Verantwortung wahrnehmen und sich die Zahlen zunutze machen und das ihrige zu tun, um den Wert des Produktes zu maximieren. Manchmal ist es schlicht notwendig dem PO zu zeigen, was die Zahlen aussagen und welche Ableitungen sich treffen lassen. Da hilft ein gegenseitiges Verständnis der Rollen und was anhand der Zahlen erreicht werden soll. Die Zahlen liefern immer einen Mehrwert je nachdem welche Fragen man an sie stellt.  

Zusammenfassend können wir sagen, dass es sicherlich sehr stark vom Geschäftsmodell der jeweiligen Organisation abhängt, ob und wie Zahlen und Daten eine Rolle innerhalb der Aufgaben einer Scrum Master*in spielen. Anders als vielleicht in der Produktentwicklung bilden sie bei uns im Dienstleistungssektor ein wichtiges und unerlässliches Werkzeug in der transparenten und vertrauensvollen Kundenkommunikation.