Tipps für ScrumMaster: Wie man auf retrospektive Ergebnisse reagiert

In meinem letzten Blog habe ich darüber gesprochen, wann User Stories geschätzt werden sollten, damit ein Product Owner die Release-Planung auf der Grundlage von Velocity und relativen Schätzungen durchführen kann. Diesmal werde ich ein anderes Thema ansprechen, mit dem viele Scrum-Teams zu kämpfen haben: wie man Verbesserungen auf der Grundlage der in Retrospektiven besprochenen Punkte umsetzt. Vielen Scrum-Teams fällt es schwer, sich kontinuierlich zu verbessern. In Retrospektiven werden Probleme und mögliche Verbesserungen diskutiert. Dann passiert nichts. In späteren Retrospektiven werden dieselben Probleme besprochen, ohne dass sich etwas ändert. Retrospektiven wie diese sind Zeitverschwendung. Noch schlimmer ist, dass das Verpassen der Gelegenheit zur kontinuierlichen Verbesserung an sich schon eine große Verschwendung ist. Die Geschwindigkeit solcher Teams und die Qualität ihrer Arbeitsergebnisse werden mit ziemlicher Sicherheit besser werden, wenn sie Wege finden, auf Verbesserungen zu reagieren, die in Retrospektiven identifiziert werden. Dies sind meine Ratschläge, die ich als nützlich empfunden habe, um Verbesserungen aus Retrospektiven umzusetzen: 1. Arbeiten Sie mit dem Product Owner zusammen, um dem Product Backlog Verbesserungspunkte hinzuzufügen. In einem Scrum-Projekt muss der Product Owner alle Stakeholder ausbalancieren, die die Kapazitäten des Teams nutzen möchten, um ihre Ziele zu erreichen. Stakeholder können Endbenutzer, eine Betriebsabteilung, eine Marketingabteilung usw. sein, aber auch das Team selbst ist ein Stakeholder. Die Arbeit, die ein Team identifiziert, um sich selbst zu verbessern, kann vom Product Owner im Product Backlog genauso priorisiert werden wie alle anderen geplanten Arbeiten des Teams. Das Team sollte in der Lage sein, die Vorteile für die anderen Stakeholder zu erläutern, sonst ist es vielleicht doch keine so gute Idee. Ich habe Teams gesehen, die in Retrospektiven erhebliche Mengen an Arbeit identifizieren, die sich wirklich lohnen würde, diese aber neben der 'normalen' Arbeit aus dem Product Backlog erledigen wollen. Wenn das Team eine festgelegte Geschwindigkeit hat, von der der Product Owner erwartet, dass sie beibehalten wird, wird das Team einfach keine Zeit finden, die 'zusätzliche' Arbeit zu erledigen. Dies ist typischerweise bei Dingen wie großen Refactorings, Verbesserungen des kontinuierlichen Integrations-Builds und der Einführung von automatisierten Funktionstests der Fall. Wenn solche Arbeiten zum Product Backlog hinzugefügt werden, werden sie zusammen mit den anderen geplanten Arbeiten, die der Product Owner vom Team erledigt haben möchte, geschätzt und priorisiert. Sobald sie dann in einem Sprint aufgegriffen wird, wird sich das Team darauf konzentrieren und sie fertigstellen. 2. Pflegen Sie Arbeitsvereinbarungen und aktualisieren Sie sie als Ergebnis von Retrospektiven. Es ist eine gute Idee, die Dinge, auf die sich das Team geeinigt hat, explizit zu benennen. In seinem Blog Team norming and chartering beschreibt Martin van Vliet, wie Sie solche Vereinbarungen treffen können. Die daraus resultierenden Vereinbarungen sollten an prominenter Stelle ausgehängt werden (an der Wand oder in einem Wiki) und für alle sichtbar sein. Diese Vereinbarungen bilden die Grundlage für eine effektive Teamarbeit und können im Falle von Unstimmigkeiten herangezogen werden. Dies ist ein wichtiger Schritt in der Entwicklung von 'nur einer Gruppe von Leuten' zu einem Team. Wenn Sie Arbeitsvereinbarungen beibehalten, können Sie sich gegenseitig zur Rechenschaft ziehen und Sie können sie überprüfen und anpassen, um Verbesserungen vorzunehmen. Ein typisches Thema von Arbeitsvereinbarungen ist der Umgang mit Fehlern, die während eines Sprints gefunden werden. Zum Beispiel: Werden sie in ein Bug-Tracking-System eingegeben oder nur auf das Scrum Board gestellt? Wie viele Kontextinformationen werden den Fehlerberichten hinzugefügt? Haben Bugs immer Vorrang vor anderen Aufgaben im Sprint Backlog? Ein weiteres häufiges Thema von Arbeitsvereinbarungen ist die Frage, welche technischen Praktiken das Team befolgen wird und in welchem Umfang: Werden die Teammitglieder immer Pair Programming betreiben oder nur dann, wenn sie es wünschen? Werden sie immer testgetriebene Entwicklung betreiben? Das Ergebnis einer Retrospektive kann darin bestehen, eine oder mehrere Arbeitsvereinbarungen zu ändern. 3. Behalten Sie eine Definition of Done bei und reflektieren Sie diese in Retrospektiven. Viele Teams sind sich über ihre Definition of Done nicht im Klaren. In einer Definition of Done legt ein Team die allgemeinen Abnahmekriterien für Features fest, die in einem Sprint geliefert werden. Zum Beispiel: Soll jedes Feature dokumentiert werden? In welchen Abständen sollen Anfragen bearbeitet werden? Sollen die Funktionen formell vom Unternehmen abgenommen werden? Es gibt Kompromisse bei der Frage, wie ehrgeizig ein Team bei seiner Definition von "erledigt" sein kann. Eine Retrospektive ist ein guter Zeitpunkt, um darüber nachzudenken. Ein Beispiel: Ein Teil der Definition of Done eines Teams, das ich betreut habe, war, dass alle Funktionen auf mehreren Versionen verschiedener Webbrowser getestet werden sollten. Als die Anzahl der Browser festgelegt wurde, für die getestet werden sollte, hatte der Product Owner keine Ahnung, wie viel Arbeit dies mit sich bringen würde. In einer Retrospektive wurde festgestellt, dass die Tests für all diese Browser der größte Engpass für die Fertigstellung der Funktionen waren. Der Product Owner entschied daraufhin, dass die Tests nur für eine kleinere Anzahl von Browsern durchgeführt werden sollten, basierend auf den Nutzungsstatistiken. Die Definition von "fertig" wurde entsprechend geändert und die Geschwindigkeit des Teams nahm deutlich zu. 4. Führen Sie Berichte über die Ergebnisse der Retrospektiven und überprüfen Sie, ob die erwarteten Verbesserungen eingetreten sind. Mein letzter Rat ist, die Ergebnisse der Retrospektiven zu überprüfen und anzupassen. Sie können nie sicher sein, ob eine Änderung tatsächlich die gewünschte Wirkung hat, wenn Sie sie nicht nach der Änderung überprüfen. Um dies tun zu können, sollten Sie die in den Retrospektiven getroffenen Entscheidungen festhalten, zum Beispiel in einem Wiki. Schauen Sie dann regelmäßig darauf zurück, um die Ergebnisse der Änderungen in Bezug auf die Geschwindigkeit und Qualität der Arbeit zu besprechen. Für einige Teams ist es ein fester Tagesordnungspunkt jeder Retrospektive, die Ergebnisse der Entscheidungen aus der vorangegangenen Retrospektive zu reflektieren. Ich hoffe, dass diese Ratschläge einigen ScrumMastern dabei helfen, Retrospektiven zu ermöglichen, die zu einer höheren Arbeitsgeschwindigkeit und einer höheren Qualität der Arbeitsergebnisse ihrer Teams führen.