134 Überprüfen

Ü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.


Fü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:


Empirie

Sprints

Transparenz

Agilität

Messen

StoryPoints

Schätzungen

Velocity

Teams

UserStories

Retrospektiven

Scrum Master

Agile Master

Agile Coach

Facilitatorin

BurnDown Chart

Dailies

Testergebnissen

Commitment

Planning

Refinements

Rollen

Weitere Rollen

Cynefin



Connecte dich gerne hier mit uns:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post 134 Überprüfen appeared first on Znipcast - für gute
Zusammenarbeit | Agile, Scrum, KanBan, Psychologie,
Teamentwicklung und NLP | Podcast der Znip Academy.