Sprints – je kürzer, desto besser?

June 17, 2010 at 8:15 pm 2 comments


Vor kurzem war ich bei einer interessanten Diskussion um Sprintlängen dabei. Dabei wurde eine generelle Tendenz hin zu kürzeren Sprints festgestellt. Ich kenne neben wöchentlichen Sprints durch Ilja Preuss auch Fälle mit halbwöchigen Sprints und sogar zweitägigen Sprints. In allen diesen Fällen war das Team in der Lage, in der kurzen Sprintdauer ein Done-Done Produktinkrement zu liefern. Außerdem ist es gelungen, die Dauer der Sprintwechsel-Meetings (Planning, Review, Retrospektive) linear mit der Sprintdauer zu reduzieren.

Wir sind in der Diskussion dann darauf gekommen, dass bzgl. der Sprints kürzer nicht unbedingt besser bedeuten muss. Bei sehr kurzen Sprints können folgende Probleme auftreten.

  1. Es kann passieren, dass sich kein motivierendes Sprintziel mehr formulieren lässt.
  2. Der Zeitrahmen im Sprint kann so eng werden, dass im Sprint nicht mehr konzeptionell gearbeitet werden kann. Das kann zu einer sehr strikten (tayloristischen) Arbeitsteilung zwischen Product Owner und Team führen.
  3. Diese beiden Punkte zusammen können zu routinisierter langweiliger Arbeit führen. Und wenn das eintritt, wird es für das Team sehr schwer, innovative Verbesserungsvorschläge in Retrospektiven zu generieren.
  4. Bei Fehlern hat das Team keine Zeit mehr, um den Sprint trotzdem noch zu schaffen. Das kann zu Defensivverhalten führen und dazu, dass nicht mehr experimentiert wird.

Tatsächlich habe ich solche Fälle auch gesehen, z.B. bei einem Team, das in einem lang laufenden Projekt mit einwöchigen Sprints gearbeitet hat. Das Team hatte eine sehr verlässliche Geschwindigkeit und hat fast alle seine Commitments gehalten. In dem Projekt hätten wir aber einen deutlichen Produktivitätsschub gebraucht. Tatsächlich haben aber die in den Retrospektiven generierten Maßnahmen aber vor allem dazu geführt, dass die Geschwindigkeit noch stabiler wurde. Damals konnte ich mir keinen Reim darauf machen und war sehr verwirrt. Aus heutiger Sicht halte ich es für wahrscheinlich, dass die kurze Sprintlänge mit verantwortlich war. Heute würde ich dem Team empfehlen, mal längere Sprints auszuprobieren.

Wie gesagt: Das muss nicht so passieren. Ich habe auch sehr erfolgreiche und kreative Teams mit einwöchigen Sprints gesehen und Ilja hat mir glaubhaft versichert, dass auch die zweitägigen Sprints sehr erfolgreich waren.

P.S.: Das ändert alles nichts daran, dass die Teams in der Lage sein sollten, bei Bedarf sehr kurze Sprints umsetzen zu können – also in sehr kurzer Zeit ein Done-Done Produktinkrement zu erstellen.

Entry filed under: it-agile-blog-planet. Tags: , .

Code-Katas in CodersDojo.com Lösungs- vs. Problemorientierung

2 Comments Add your own

  • 1. Jens Schauder  |  June 17, 2010 at 9:04 pm

    Ich halte 2 Tage Sprints noch aus einem weiteren Grund für problematisch. Retrospections dienen dazu Feedback auf einer Zeitskala zu liefern, während Daily Scrums das gleiche auf einer anderen Zeitskala tut.

    Mit so kurzen Sprint erscheint es mir schwierig Verbesserungen im Großen zu erreichen.

  • 2. stefanroock  |  June 18, 2010 at 6:32 am

    Ich weiß nicht, wie die Retrospektiven bei den zweitägigen Sprints durchgeführt wurden. Aber man könnte die ja trotzdem einfach zweiwöchentlich machen.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: