Jeder hat wohl schon die ein- oder andere Retrospektive erlebt. Als Scrum Master ist es eure Aufgabe, den Prozess ständig zu verbessern und die Produktivität sowie die Zufriedenheit zu erhöhen. Klingt soweit einfach. Jeder wird auch in seiner Retrospektive aktuelle Impediments finden - aber was ist mit den "vergrabenen" Problemen, an die sich die Kollegen schon gewöhnt haben? Gerade in großen, stark tayloristisch geprägten Unternehmen oder bei "Scrum"-Implementationen, die nur ein Deckmantel für das Beibehalten der alten Wasserfallvorgehensweisen sind, machen diese oft den weitaus größten Teil der Impediments aus. Gerade Implementationen von Scrum, die keine ausreichende Management-Unterstützung haben, leiden mit großer Wahrscheinlichkeit darunter.
Wenn ihr den Verdacht habt, dass die Produktivität eurer Teams schlechter ist, als es nach der Meinung der Teams der Fall ist, versucht doch mal eine Retrospektive, die auch die versteckten Aufwände ans Licht bringt. Zunächst solltet ihr mit einer Analyse der vergangenen Retrospektiven ein paar Impediment-Kategorien ermitteln (z.B. Impediments durch das eigene Team, durch fremde Teams, durch die Infrastruktur, usw.). Diese sollen ruhig grob sein, damit die Teams genügend Spielräume behalten und nicht zu sehr in ein Korsett gezwängt werden. In der Retrospektive selbst sollte die Aufmerksamkeit des Teams dann darauf gelenkt werden, dass es versteckte Impediments gibt, an die man sich bereits gewöhnt hat. Ein konkretes Beispiel hilft hier meist bei der Kommunikation. Dann sollen die Teams selbst (Sub-)Kategorien entwickeln und mit Zahlen (Personentage oder Stunden) hinterlegen - nach Bauchgefühl, aber im Konsens. Nachdem das Team damit fertig ist (ca. 30 Minuten) sollte es eine kurze Pause machen und dann die aufgeführten Kategorien daraufhin prüfen, ob Aufwände doppelt aufgeführt sind - wir wollen die Zeiten ja nicht mehrfach erfassen.
Diese absoluten Aufwände sind noch nicht vergleichbar. Daher sollte man sie ins Verhältnis mit der verfügbaren Zeit (Kapazität) setzen. Heraus kommt eine Prozentzahl, die besagt, welchen Anteil der Zeit das Team wirklich produktiv arbeiten kann bzw. welche Kosten das Unternehmen durch unvollkommene Prozesse und Tools verursacht.
Natürlich sagt die Velocity im Endeffekt das Gleiche aus. Allerdings hat sie nicht die Signalwirkung wie zeitliche Schätzungen. Will man ein Management ohne ausreichendes Scrum-Wissen von der Notwendigkeit zu handeln überzeugen, helfen harte Zahlen meist mehr als eine relativ weiche Velocity. Das krasseste Beispiel, das ich bislang hatte, war ein Team mit 79% versteckten Impediments. Kein Wunder, dass die Zufriedenheit äußerst gering war...
SO ermittelte Prozentquoten entsprechen in etwa dem "Fokus Faktor", den Henrik Knieberg in seinem Buch "Scrum and XP from the trenches" beschreibt. Ich favorisiere grundsätzlich die normale Velocity, weil sie schneller und leichter zu ermitteln ist, aber manchmal braucht das Management andere Zahlen.
Achja: In gut funktionierenden Scrum-Teams mit hoher Produktivität ist die oben beschriebene Form der Retrospektive meistens nicht sonderlich ergiebig, da diese Teams ganz genau wissen, woran es hakt und diese Missstände nicht hinnehmen. Da kennt und liebt normalerweise auch das Management Scrum.
Monday, September 5. 2011
deutscher Scrum Guide 2011
Letzten Freitag sind wir endlich die Übersetzung des Scrum Guide abgeschlossen. Die fleißigsten Helfer waren dabei Andreas Schliep, Ulf Schneider, Wolfgang Wiedenroth und ich.
Was hat das im Blog verloren? Nunja: Wir hatten eine recht aufwändige Definition of Done, daher hat es etwas länger gedauert. Im Einzelnen bedeutet das
Erst damit haben wir den Zustand "Done Done" erreicht. In dem Zusammenhang kann ich euch übrigens diesen Artikel empfehlen. Wir sind der Meinung, dass die Qualität des deutschen Beitrags den anderer Länder übertrifft. Muss er auch - unsere Nation ist sehr kritisch
Ich wünsche euch viel Spaß beim deutschen Schmökern und freue mich auf viele konstruktive Rückmeldungen zur Übersetzung.
Was hat das im Blog verloren? Nunja: Wir hatten eine recht aufwändige Definition of Done, daher hat es etwas länger gedauert. Im Einzelnen bedeutet das
- Alle Scrum-Begriffe wurden intensiv diskutiert und dann einheitlich übersetzt
- Das Dokument wurde nach Fertigstellung nochmals daraufhin reviewt, ob alle Scrum-Begriffe durchgängig überall korrekt übersetzt waren
- Das Dokument wurde abschließend einmal inhaltlich und einmal auf Rechtschreibfehler kontrolliert
- Jeder übersetzte Satz wurde von mindestens 4 Augen überprüft
- Die finale Version wurde von einem Haufen erfahrener Scrum-Anwender nochmals überprüft
Erst damit haben wir den Zustand "Done Done" erreicht. In dem Zusammenhang kann ich euch übrigens diesen Artikel empfehlen. Wir sind der Meinung, dass die Qualität des deutschen Beitrags den anderer Länder übertrifft. Muss er auch - unsere Nation ist sehr kritisch
Ich wünsche euch viel Spaß beim deutschen Schmökern und freue mich auf viele konstruktive Rückmeldungen zur Übersetzung.
(Page 1 of 1, totaling 2 entries)