tag:blogger.com,1999:blog-5270715379840717905.post3940255502490453229..comments2023-06-01T08:37:36.310+01:00Comments on Klick um Klick: SprintGoals und ÜberstundenBernd Schifferhttp://www.blogger.com/profile/05678172815709840976noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-5270715379840717905.post-89449687458472110112010-01-15T15:21:40.455+01:002010-01-15T15:21:40.455+01:00Hey Jens, das finde ich eine sehr schöne Sicht auf...Hey Jens, das finde ich eine sehr schöne Sicht aufs SprintCommitment: "Sich bemühen, das Ziel zu erreichen."Bernd Schifferhttp://www.blogger.com/profile/05678172815709840976noreply@blogger.comtag:blogger.com,1999:blog-5270715379840717905.post-63703674476080236702008-12-13T21:54:00.000+01:002008-12-13T21:54:00.000+01:00"Sich bemühen, das Ziel zu erreichen." finde ich v..."Sich bemühen, das Ziel zu erreichen." finde ich von der Wortwahl zu schwach. Wenn im Arbeitszeugnis steht, man habe sich bemüht, bedeutet das nichts Gutes.<BR/><BR/>Ich würde eher sagen, dass das Team alles in seiner Macht stehende tun muss, um das Commitment zu halten, ohne dabei die durchhaltbare Geschwindigkeit (Sustainable Pace) zu opfern.Stefan Roockhttps://www.blogger.com/profile/00840921392422933600noreply@blogger.comtag:blogger.com,1999:blog-5270715379840717905.post-30987167857261050612008-12-09T15:03:00.000+01:002008-12-09T15:03:00.000+01:00Hey Jens, das finde ich eine sehr schöne Sicht auf...Hey Jens, das finde ich eine sehr schöne Sicht aufs SprintCommitment: "Sich bemühen, das Ziel zu erreichen."Bernd Schifferhttps://www.blogger.com/profile/05678172815709840976noreply@blogger.comtag:blogger.com,1999:blog-5270715379840717905.post-65440831302212889092008-12-09T08:53:00.000+01:002008-12-09T08:53:00.000+01:00Henning,ich gebe Bernd zu 150% Recht: Wenn man das...Henning,<BR/><BR/>ich gebe Bernd zu 150% Recht: Wenn man das Ganze mal statistisch sieht, ist bei Yesterday's Weather die Chance, das Ziel zu erreichen 50%, d.h. in der Hälfte der Fälle wird das Team die Latte reißen. Simon Roberts hat mir übrigens bestätigt, dass das Committment in Scrum sich darauf bezieht, sich <STRONG>zu bemühen</STRONG>, das Ziel zu erreichen, nicht darauf, es wirklich zu erreichen. Anders gesagt: Planung ist ein Blick in die Zukunft und der ist bestenfalls unscharf, meistens aber falsch.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5270715379840717905.post-74208778388252376462008-11-16T10:31:00.000+01:002008-11-16T10:31:00.000+01:00Ich denke, die meisten Scrum-Projekte sind weit da...Ich denke, die meisten Scrum-Projekte sind weit davon entfernt, am Sprintende _Shippable Code_ zu haben. Selbst wenn das Team die notwendige Qualität erreicht, schafft es der Product Owner meistens nicht, seine Wünsche so klein zu definieren, das nach jedem Sprint an die Benutzer geliefert werden kann.<BR/>Ich glaube, für Sprint-Goal und Commitment macht das einen relevanten Unterschied.<BR/>Wenn ich liefern will/muss, bedeutet das reißen des Commitments mitunter einen deutlichen Schaden für das Unternehmen. Und dann können Überstunden _für diesen einen Sprint_ ein adäquates Mittel sein, um das Commitment zu erreichen.<BR/><BR/>Meistens geht es in einem Sprint aber nicht um das Liefern an die Kunden. Dann bedeutet das Reißen des Commitments für einen Sprint keinen direkten Schaden für das Unternehmen. Wenn das Team das Commitment mit Hilfe von Überstunden hält, ist es für das Gesamtprojekt ein Taschenspielertrick. Im nächsten Sprint wird das Team entsprechend langsamer sein - wg. Abbummeln von Überstunden, Regeneration etc. Die Überstunden führen sogar zu stärkeren Schwankungen in den Velocity-Kurven und die Planbarkeit wird eingeschränkt.<BR/><BR/>Wenn Überstunden für das Team die Schmerzen verursachen, die zur Selbsterkenntnis und Verbesserung führen, dann los.<BR/><BR/>Der normale Weg dazu wäre aus meiner Sicht allerdings anders: Wenn das Commitment gerissen wird, _muss_ das Team in der Retrospektive darüber sprechen und Verbesserungsmaßnahmen ableiten. Und wenn das Team seine Commitments nicht erfüllt, obwohl es in den Retrospektiven ständig drüber spricht, dann deutet das auf ein viel größeres Problem hin.Stefan Roockhttps://www.blogger.com/profile/00840921392422933600noreply@blogger.comtag:blogger.com,1999:blog-5270715379840717905.post-55077678901581658472008-11-15T17:52:00.000+01:002008-11-15T17:52:00.000+01:00Ich glaube, dass wir uns einig sind, dass es in de...Ich glaube, dass wir uns einig sind, dass es in der initalen Phase eines Scrum-Projektes viel öfter zum Nichterreichen des SprintGoals kommen kann, als das im späteren Verlauf des Projektes der Fall sein wird.<BR/><BR/>Ich sehe das auch so wie Du, dass wenn im späteren Projektverlauf immer noch dauernd das SprintGoal verfehlt wird, dass dann ein Defekt vorliegt, den man behandeln sollte.<BR/><BR/>Das bedeutet aber aus meiner Sicht nicht, dass das Team nicht ab und an das SprintGoal verfehlen darf, sogar dann, wenn das Team schon sehr eingespielt und erfahren ist.<BR/><BR/>Ich arbeite mit dem Team als ScrumMaster darauf hin, dass es mit der Zeit schneller und besser wird. Das erreichen wir durch die Retrospektiven, in dem das Team sein Vorgehen entsprechend anpasst. Eine Anpassung kann den erwarteten Erfolg bescheren, und dann ist das Team schneller und besser und erfüllt oder übererfüllt das SprintGoal. Die Anpassung kann aber auch daneben gehen, das weiß man ja vorher noch nicht so genau, und dann reißt man halt die Latte und das SprintGoal wird nicht erreicht. Das passiert. Wenn ich also vom Team erwarte, dass es Risiken eingeht, damit es besser wird, dann darf ich es aus meiner Sicht nicht verhaften, wenn es mal daneben greift und ein SprintGoal nicht schafft. Risiken können eben auch Verluste bedeuten.<BR/><BR/>Ich bin mir nicht sicher, ob wir in diesem Punkt einer Meinung sind.<BR/><BR/>Commitments im Allgemeinen sind für mich viel umfassender, als dass man sie auf ein SprintGoal reduzieren könnte. Wenn Du hier aber vom Commitment sprichst, und damit das SprintGoal meinst, dann hat das sehr wohl für mich einen Wert. Das SprintGoal ist das angepeilte Ziel und dafür eine wunderbare Markierung. Es steckt den Rahmen aller, die sich in einem Scrum-Projekt bewegen. Das ist mir sehr viel wert. Es aber, wenn einmal festgelegt, als unverrückbar und auf jeden Fall zu halten anzusehen - Überstunden hin oder her -, wie ich das von Dir verstehe, entspricht nicht meiner Sicht von Flexibilität.<BR/><BR/>Ich vermute, dass wir in dem Punkt auch nicht einer Meinung sind. Sofern ich den Punkt richtig verstanden habe...?!Bernd Schifferhttps://www.blogger.com/profile/05678172815709840976noreply@blogger.comtag:blogger.com,1999:blog-5270715379840717905.post-7055230795094714672008-11-13T07:03:00.000+01:002008-11-13T07:03:00.000+01:00Bernd, ich bin kein Überstundenfan.Mein Punkt ist,...Bernd, ich bin kein Überstundenfan.<BR/>Mein Punkt ist, dass es eben im Einzelfall mal zum Reißen kommen darf, aber wenn es nach der initialen Einschwingphase immer noch dauernd dazu kommt, dann ist was falsch.<BR/><BR/>So wollen wir ja letztlich besser sein als klassiche plangetriebene Verfahren, die meist sehr spät Überraschungen erleben, weil die Pläne nicht eingehalten werden können. Wir wollen dem realistische kürzere Pläne mit häufiger Planüberprüfung und -anpassung entgegensetzen.<BR/>Wenn wir aber generell ablehnen, dass das Commitment irgendeinen wert hat, dan brauchen wir damit nicht loslegen.Henninghttps://www.blogger.com/profile/09950880635612420916noreply@blogger.comtag:blogger.com,1999:blog-5270715379840717905.post-57661527103956278452008-11-11T20:02:00.000+01:002008-11-11T20:02:00.000+01:00Bei jedem Team oszilliert die Geschwindigkeit am A...Bei jedem Team oszilliert die Geschwindigkeit am Anfang stärker und pendelt sich dann irgendwann ein. Sobald sie sich eingependelt hat, hat man eine Planbarkeit erreicht. Warum geht das Deiner Ansicht nach nur dann, wenn die meisten Sprints mit Übererfüllung enden?<BR/><BR/>Ich glaube nicht an einen Lerneffekt durch Überstunden. Aber das ist ein anderes Thema.<BR/><BR/>Aber unabhängig davon: Überstunden bedeuten niedrigere Qualität. Qualität ist eine Invariable in Scrum, Funktionsumfang ist die einzige Variable in Scrum. Wie passt das aus Deiner Sicht zusammen?<BR/><BR/>Weniger Qualität in diesem Sprint bedeutet weniger Features im nächsten Sprint. Das wollen die Stakeholder nicht. Wie passt das aus Deiner Sicht zusammen?<BR/><BR/>Überstunden beißen sich mit "Wetter von Gestern": Hast Du durch Überstunden in diesem Sprint soundsoviel Stories geschafft, dann bekommst Du nach "Wetter von Gestern" eben soviel Stories in den nächsten Sprint - was Du, nach dem "Wetter von Gestern"-Prinzip, wieder nicht schaffen wirst, es sei denn, Du machst wieder Überstunden. Wie kommst Du aus dieser Tretmühle wieder raus?<BR/><BR/>Mal angenommen, Überstunden brächten etwas. Überstunden kann man nicht in jedem Sprint machen, irgendwann kommt der BurnOut, aber Du weißt nicht, wann das ist. Vielleicht kommt der kurz vor Projektende, kurz vorm Release. Wie erreichst Du damit Planbarkeit?Bernd Schifferhttps://www.blogger.com/profile/05678172815709840976noreply@blogger.comtag:blogger.com,1999:blog-5270715379840717905.post-74792327541115400682008-11-09T22:25:00.000+01:002008-11-09T22:25:00.000+01:00Ich sehe das etwas anders, Bernd.Am Anfang mag es ...Ich sehe das etwas anders, Bernd.<BR/>Am Anfang mag es OK sein, dass das Team sein Commitment reißt und sich oft überschätzt, aber das muss sich nach ein paar Sprints einigermaßen regulieren und es sollten die meisten Sprints eher mit Übererfüllung enden. Nur so kann ich Planbarkeit erreichen.<BR/>Und bedeutet es mal Überstunden? Vielleicht ja, aber dann mit einem zusätzlichen Lerneffekt, dass man es nur mit Überstunden geschafft hat, und sich das Team für den nächsten Sprint auf weniger einlässt.Henninghttps://www.blogger.com/profile/09950880635612420916noreply@blogger.com