Überprüfen

Aus der Empirie weißt Du schon, dass Transparenz, Überprüfen und Anpassen die Grundpfeiler der Agilität sind. Bzw. „Inspect before adapt“ könnte man auch sagen.

Überprüfen - Zahnkontrolle, offener Mund und Zahnarzt SpiegelFür alle, die noch ihre Scrum.org Zertifizierung machen ist genau dies wichtig. Also auch Empirie mit Transparency, Inspection und Adaption erklären zu können. Quasi als 3 Säulen des Fundaments. Diese Folge ist also quasi Prüfungsvorbereitung. 🙂

Diese Folge auf YouTube: https://youtu.be/S263D16SxKU

Grundlage

Wir legen heute also wieder ein paar Grundlagen. Gerade für Agilität und gleichzeitig auch andere Herangehensweisen. Beispielsweise kennst Du das sicherlich auch aus dem Projektmanagement. Den PDCA-Zyklus. Plan, Do, Check, Act. Auch dort ist die Überprüfung eingebaut.

Für Henry Schneider gehört auch noch das Messen zum Überprüfen, denn vieles können wir erst durch die Messung überprüfen.

Die Messung zieht sich bei Henry aber auch durch. Also wir brauchen die Messung für die Transparenz (Was messen wir, warum?), für das Überprüfen (Messergebnisse vergleichen) und für die Anpassung (Hat sich etwas verändert?)

Wie und was überprüfen wir?

Hier steht vor allem die Frage dahinter „Wozu mache ich Agilität?“. Ja es klingt so banal, doch wir entdecken wenig Agile Transitionen, die sich diese Frage im Vorfeld gestellt haben. Agilität einführen, nur damit man agil ist, ist kein guter Zweck. Irgendwas wollen wir erreichen und die Agilität könnte ein Mittel dazu sein.

Beispielsweise Fluktuation in den Griff bekommen. By the way ein Riesen Kostenpunkt für Unternehmen, den viele leider nicht auf dem Schirm haben. Wir können mit unseren Mitteln die Fluktuation von 25% auf 10% und weniger runterbringen. Genau dies können wir dann entsprechend überprüfen.

Hier Achtung, wenn nicht vorher klar ist was wir erreichen wollen und wie wir das überprüfen, dann wird es oft nur ungezieltes Topfschlagen. Auf der anderen Seite auch wichtig hier gut zu wählen, denn wir bekommen was wir hier Überprüfen. Beispielsweise, wenn wir viele StoryPoints haben wollen und diese regelmäßig überprüfen, dann bekommen wir auch viele StoryPoints. Das hat aber keinerlei Aussage zum Outcome des Teams. 😉

Investiere also gut und gerne Zeit in die Frage, was Du wozu überprüfen willst.

Das Richtige tun

Wir dürfen uns wirklich darauf konzentrieren das Richtige zu tun und Agile Frameworks einführen, weil wir wissen, was wir verbessern wollen. So stecken wir auch unsere Energie in die richtigen Dinge.

Janina Kappelhoff erwähnt gern das Buch „Scrum – The Art of Doing Twice the Work in Half the Time“ von Jeff Sutherland. Ein großer Punkt darin ist genau zu wissen worin wir unsere Energie investieren und vor allem Verschwendung zu vermeiden. Wir möchten also genau wissen wo rein wir unsere Energie stecken und diese nicht mehr in unsinnige Dinge packen.

Das gilt natürlich auch für die Überprüfungen und die Schätzungen selbst. Also warum macht ein Team da so viel Druck drauf?

Ein Beispiel: Ich will höhere Mitarbeiterzufriedenheit oder einen geringeren Krankheitsstand. Dies messe ich, indem ich Projektstunden überprüfe. Also werden mehr oder weniger Stunden auf Projekte gebucht. Was bekomme ich dadurch? Mehr Stunden in Projekten. Werden die Projekte dadurch besser oder gar schneller fertig? Ich bezweifle es. Das liegt auch daran, dass natürlich meine späteren Anpassungen in diese Richtung gehen und als erfolgreiche Interventionen gelten, wenn dadurch mehr Stunden auf Projekte gebucht werden.

Weniger ist mehr

Es hilft auch nicht tausende Sachen zu überprüfen und damit alle zu gängeln oder gar von ihrer Arbeit abzuhalten. Die Überprüfung muss automatisch erfolgen, leicht verständlich sein und nur wenige Kriterien haben. Wenn Du 1.000 Werte hast, auf welchen konzentrierst Du Dein Experiment? Dann wird auch an jedem Tag an etwas anderem rumgebastelt, weil hier der Wert verbessert werden soll.

Such Dir also wenige Punkte aus.

Druck rausnehmen

Nur das Überprüfen an sich macht noch keine schlechte Statistik. Beispielweise sind wir große Verfechter von Velocity. Wir messen diese gern. Wenn diese aber verwendet wird um Druck aufs Team auszulösen oder Teams miteinander zu vergleichen, dann wird es schlecht. Wenn wir nur auf die StoryPoints an der Stelle schauen und das Team damit konfrontieren, dann bekommen wir mit sehr hoher Wahrscheinlichkeit auch schludrig umgesetzt UserStories.

Um dies zu vermeiden kannst Du Dein Team regelmäßig fragen, ob ihnen klar ist was wir da tun.

Wem gehört’s?

Diese Überprüfungen gehören im Regelfall dem Team. Diese sollten auch selbst prüfen können. Natürlich gibt es Dinge, die die Organisation interessieren, wie der Fortschritt einer Agilen Transition, trotzdem sind es Zahlen des Teams. Diese Zahlen können auch sehr gut Eingangskriterien für Retrospektiven sein. Aber nicht im Sinne von „Warum seid ihr so schlecht?“ sondern „Dies ist bei der Überprüfung herausgekommen, was meint ihr dazu?“.

Als Scrum Master, Agile Master oder Agile Coach darf ich nun schauen, dass alle verstanden haben, warum wir die Überprüfung machen. Und zwar so, dass dies auch jeder durchführen könnte.

Dadurch muss es auch einen Mehrwert für das Team haben und nicht nur für die Facilitatorin gemacht werden.

BurnDown Chart

Ein weiteres Mittel zur Überprüfung ist das BurnDown Chart. Dies hilft dem Team Orientierung während eines Sprints zu finden. Häufig wird dies im Scrum bereits implizit verwendet.

Regelmäßigkeit

Das Überprüfen muss regelmäßig stattfinden. Es bringt also nichts mal eben so zu messen oder zu überprüfen. Ganz im Gegenteil, das darf sich auch erst einmal einschwingen.

Diese Regelmäßigkeit könnte man zum Beispiel über Dailies herstellen oder Iterationsweise. Gerade bei Testergebnissen ist es sinnvoll darauf jeden Tag zu schauen und so schon eine Überprüfung durchzuführen.

Aufpassen

Ich sehe sogar häufig, dass sich auch gestandene Agile Coaches an dieser Stelle die Psychologische Sicherheit zum Team verspielen. Indem sie einfach Charts vorzeigen und das Team damit konfrontieren, dass sie schlecht seien. Eine Anklage ohne dies vorher transparent zu machen, dass überhaupt gemessen wird.

Einfachheit

Die Überprüfung muss super einfach durchführbar sein. Am besten automatisiert und von jedem einsehbar. Henry akzeptiert in den Daten lieber eine gewisse Unschärfe, als zu viel Energie in super genaue Daten zu investieren. Es ist schließlich eine Hilfestellung und keine exakte Wissenschaft.

Überprüfung überprüfen

Hört sich witzig an und darf es auch gern sein. 🙂 Wir sind in der Agilen Welt und damit in einer komplexen Umwelt unterwegs. An diese passen wir uns an und dürfen natürlich auch unsere Überprüfung anpassen. Das heißt, dass beispielsweise eine einmal eingeführte und auch für gut befundene Messung, trotzdem wieder abgeschafft werden kann, wenn es darin aktuell keine Verbesserung mehr braucht. Oder nun doch heraus kam, dass dies doof ist.

Zeit lassen

Die Überprüfung ist nicht sofort aussagekräftig und braucht eine Zeit und auch einige Messpunkte, damit man daraus Dinge ableiten kann. Henry misst sehr gerne Durchlaufzeiten und optimiert daran. Die ersten Messungen haben aber wenig Aussagekraft, da es eine Weile dauert, bis auch die Messung eingeschwungen ist und einen vernünftigen Mittelwert liefert. Meist sind schließlich schon Tickets im System, die in unterschiedlichen Status und Größen durchlaufen.

Gute Durchlaufzeiten stärken die Zuverlässigkeit des Teams und vor allem auch das Commitment der Product Ownerin in Richtung Organisation. Sie weiß also, wenn eine Aufgabe zugesichert begonnen wird, dann ist diese auch nach X Tagen erledigt.

Wo im Scrum?

Wir haben ja schon begonnen, dass ein BurnDown Chart eine Überprüfung im Scrum zum Daily darstellen kann. Es gibt natürlich noch weitere Prüfpunkte im Scrum Guide. Ganz klar, ist ja Empirie und liegt dem zugrunde. Also eigentlich ist es überall drin.

Wir überprüfen auch im Review und im Daily schauen wir, ob die Planung zum Sprint noch passt. Genauso haben wir unsere Plannings und Refinements, wo wir unsere Planungen und Ziele miteinander abgleichen. Hier wird auch geprüft ob die User Stories vollständig und verständlich sind. In den Retrospektiven überprüfen wir unser Zusammenarbeitsmodell. Du merkst schon, es ist überall. 🙂

Rollen

Jetzt können wir uns natürlich noch die Rollen anschauen. Also, wer prüft denn eigentlich was? Grundsätzlich sollte das natürlich jeder können und auch verstehen, warum wir bestimmte Dinge überprüfen. Durch die unterschiedlichen Rollen und damit verbundenen Ergebnisverantwortlichkeiten haben diese Rollen auch unterschiedliche Prüfperspektiven und ergeben eine gute Gesamtkomposition.

Im Refinement verhandeln die Entwicklerinnen mit der ProductOwnerin ob eine Story gut genug ist für einen Sprint. Demnach legen sie auch unterschiedliche Prüfkriterien an.

Im Daily dagegen sind Scrum Masterin und Product Ownerin zweitrangig. Das passt auch gut zu euer Lieblingsfolge, weitere Rollen. Klar, wenn ich eine Rolle Testmanager habe, dann ist diese für die Auswertung der Testcases zuständig und die Rolle darf rollieren.

Und so dürfen wir auch regelmäßig die Perspektiven unserer Rollen miteinander abgleichen.

Termineinladungen

Henry hat die letzten Jahre viel mit Menschen zu tun, die neu in Agilität sind. Ich schreibe daher bereits in die Termineinladungen, was Input und Output sind. Dies können auch entsprechende Prüfkriterien sein. Dies macht es den Neulingen leichter zu verstehen, was die Erwartungshaltung ist und macht auch Diskussionen über Dinge, die vielleicht noch nicht ganz so rund laufen, leichter. Janina klärt das lieber ab, statt Checklisten zu machen. Warum erfährst Du in Menschen lesen.

Komplexität

Achtung, wir setzen Agilität im komplexen Bereich ein (Cynefin). Das bedeutet, dass wir Ursache und Wirkung nicht vorhersehen können. Wir können nur Vermutungen anstellen und rückwirkend entsprechende Zusammenhänge erahnen. Das bedeutet, dass unsere Überprüfung auch ganz anders laufen kann, als wir uns das vorher ausgedacht haben.

 

Get shit done,

Janina & Henry


Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.


Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉


Janinas Ultimativer OKR Guide


In der Podcastfolge erwähnte Folgen zur Vertiefung:


Connecte dich gerne hier mit uns:

LinkedIn

Instagram

YouTube

Facebook

Webseite

Facebook-Gruppe

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert