Nudge am 25.08.2012

Scrum: Sprints in On-Off-Phasen

in Projektmanagement | Tags: Erkenntnis, Feedback, Projektmanagement, Scrum, Sprint, Team

Es ist ein zentrales Merkmal der Scrum-Philosophie, dass das Produkt in kleinen, überschaubaren Iterationen – den Sprints – verbessert wird. So kann der parallel stattfindende ErkenntnisProzess immer wieder zur Neuausrichtung der Entwicklung genutzt werden. So geht weniger Zeit für endlose Spezifikation oder die Implementation unnötiger Features verloren. Doch wie können die Erkenntnisse des jetzigen Sprint konkret im nächsten Sprint genutzt werden, wenn diese nahtlos aneinander gereiht sind? Dieser Übergang hat mich schon immer gedanklich beschäftigt. Daher hier ein Review meiner Erfahrung damit.

Wenn man Praxis-Tipps oder Berichte in Fachzeitschriften zu Scrum liest, bekommt man den Eindruck, dass viele Teams 2 Wochen für eine Iteration (einen Scrum-Sprint) als angemessen betrachten. Hier und dort liest man auch, Sprints sollten nicht am Freitag oder Montag starten und enden. Und man erfährt auch, dass ein Schätz-Meeting – hier werden die neuen Features “gemessen” – an einem anderen Tag durchgeführt werden sollten, zum Beispiel einem Freitag. Für die Retrospektive nehmen manche Teams auch wieder einen gesonderten Tag, zum Beispiel einen Donnerstag (2 Tage nach Sprint-Ende). Das sind schon einmal sehr wertvolle Tipps, die einem die Praxis erleichtern können.

Zu Beginn einer Scrum-Reise könnte man sich also mal mit seinem Team um einen großen Kalender herum versammeln und jeden zweiten Dienstag rot und den Donnerstag darauf grün markieren. Am roten Tag werden die Sprints gestartet und jeweils 2 Wochen darauf das fertige Inkrement (“potentially shippable”) geliefert. Diese “Lieferung” bedeutet für das Team im Prinzip, ein Review-Meeting zusammen mit dem Kunden, dem Product Owner, durchzuführen. Hier wird kräftig Feedback gesammelt. Außerdem muss ja an diesem Tag der nächste Sprint beginnen. Das bedeutet, dass noch zwei weitere Meetings anstehen. Diese nennen sich “Sprint Planning I” und “Sprint Planning II“. Das Team hat also 3 Meetings an diesem Tag – Puh! Hat man da noch Kraft, im letzten Meeting über Architektur und Details der anstehenden Implementation zu diskutieren?

Doch nicht nur wegen der Masse an Meetings scheint mir dieser enge Rhythmus ungünstig. Auch der Erkenntnisprozess leidet meiner Erfahrung nach. Hier zwei Beispiele.

1. Der Product Owner nimmt an diesem Tag den Kontakt mit dem Produkt neu auf. Er durchforscht es und stellt fest, was nun besser funktioniert und welche Fehler zum Beispiel behoben sind. Er dankt dem Team für das coole Ergebnis und ist zufrieden. Aber er kann natürlich instant kein vollständig qualifiziertes Feedback geben, dazu muss er sich mit ein paar anderen Nutzern abstimmen und auch die Stakeholder informieren. Die neuen Funktionen will er sich später auch mal im Detail anschauen, wenn er allein ist und Testdaten von Nutzern dazu erhalten hat. Er hat zwischenzeitlich die aktuelle Version von der Konkurrenz gesehen, die haben jetzt was ähnliches und er muss vergleichen, wo das eigene Produkt besser oder schlechter ist. Doch wann wird er es tun? Das Team weiß es nicht. Wenn er schnell ist, hat er am Freitag zum nächsten Schätz-Meeting ein paar neue Vorschläge parat. Doch der aktuelle Sprint ist dann schon verplant.

2. Die Retrospektive findet zwei Tage später statt. Ein Mitarbeiter sagt an diesem Tag: “Im letzten Sprint waren die Aufgaben zwischen Frontend und Backend so ungleich verteilt, dass ich fast immer Leerlauf hatte, weil keine Funktion bereit fürs Styling war!”. Diese Erkenntnis sollte am besten sofort (im nächsten Sprint) zur Verbesserung genutzt werden, sonst hat er 2 weitere Wochen Leerlauf! Doch leider ist der neue Sprint schon gestartet. (Hinweis: Dieses Beispiel ist fiktiv. Natürlich sollte ein Team-Mitglied auch andere Aufgaben als nur Styling übernehmen können!)

Diese Beispiele zeigen meines Erachtens, dass die Erkenntnis-Dauer länger als das Review-Meeting selbst sein kann. Und damit geht ein weiterer Zyklus für die Adaptation an geänderte Rahmenbedingungen verloren und man marschiert im schlimmsten Fall mit dem Projekt-Team ganze vier Wochen in eine falsche Richtung – statt der angestrebten zwei Wochen.

Doch wie kann dieses Dilemma gelöst werden? Zunächst hatte ich ein Projekt mal mit zwei Tagen “off“-Zeit probiert. Das bedeutete, dass der neue Sprint zwei Tage nach dem letzten Review wieder neu geplant wird. In dieser Zeit sollte der Product Owner (PO) das Feedback einsammeln. Die herausgearbeiteten Bugs und Change Requests (CR’s) wollten wir gleich noch mit schätzen, damit das Backlog (Liste der offenen Aufgaben vor der Sprint-Planung) zum Kick-Off wieder aktuell ist und wir sicher stellen können, dass keine Erkenntnisse aus dem letzten Sprint fehlen. Es bedeutete leider auch, dass jeder Sprint potentiell an einem anderen Wochentag starten würde und sich die Sprints unrhythmisch zur gesamten Wochenplanung verhalten. Die oben genannten Praxis-Tipps greifen bei diesem Vorgehen nicht.

Außerdem erwies sich in der Zusammenarbeit mit Industriekunden die Zeit von zwei Tagen als zu kurz, um das Feedback einzusammeln und zu bewerten. Im nächsten Projekt probierte ich vier Tage aus, mit demselben Ergebnis. Auch diese 4 Tage waren zu kurz. Der Product Owner meinte zwar zum Projektbeginn, das sei mehr als ausreichend und wir könnten die Deadline also vorziehen, aber am Ende sah die Realität wider anders aus. Es war ent-täuschend (mein Lieblingswort!). Die Täuschung, man könne das Feedback so schnell einsammeln, war einer Erkenntnis gewichen. Und das ist ja immer toll!

Mein aktuelle “personal best practice” ist, Sprints von nur 1 Woche Länge zu planen (On-Phase). Danach folgt 1 Woche Feedback-Zeit (Off-Phase). Diese Woche hat sich als ausreichend für die Erkenntnisgewinnung erwiesen. Sprints beginnen am Mittwoch und enden am folgenden Mittwoch. Der nächste Sprint beginnt dann wieder am Mittwoch darauf. Das ist einfach am Kalender planbar. Damit hat man mit zwei Entwicklern ca. 8-10 PT Umfang in einem Sprint zur Verplanung frei. Unsere Projekte sind relativ klein und als Agentur auf viele Kunden verteilt, die Feedback-Schleifen aber eher lang. Daher plane ich in der Off-Phase für das Team kleinere andere Aufgaben (Schätzungen, CR’s, Bugfixes) aus anderen Projekten oder interne Entwicklungen ein und gebe dem PO Zeit, das qualifizierte Feedback zusammenzustellen, was für den nächsten Sprint notwendig ist.

Was für mich aus dieser Best Practice auch entsteht, ist eine saubere Projekt-Kalkulation: Ich weiß, wieviel Projektmanagement pro Sprint notwendig ist: zwei mal Planning-Meeting für den SCM und die zwei Entwickler, 1 Review Meeting (SCM, Team, PO) und in der Erkenntnisphase 1 Schätzmeeting. Dazu die Kommunikation mit dem Kunden, die relativ überschaubar ist. Habe ich also ein Projekt mit ca. 80 Entwickler-Tagen incl. QA, Doku und Release vor Augen, dann bedeutet es in der Regel, dieses in 10 Sprints und einer Laufzeit von 20 Kalenderwochen durchzuführen. Hinzu kommen noch die Feiertage, Urlaube und Puffer für Krankheiten und sonstige Störungen. Diese Rechnung kann ich einem Kunden schon instant am Telefon durchkalkulieren, wenn er weiß, wieviel er ungefähr beauftragen möchte. Was mich in die komfortable Situation bringt, keiner übermotivierten Deadline zuzustimmen.

Mein Vorgehen könnte wie 50% Overhead oder Zeitverlust klingen, wenn man in einer Situation mit nur einem größeren Kunden oder Projekt steckt. Hier lohnt es sich gegebenenfalls, einen 3-Wochen-Rhythmus auszuprobieren: 2 Wochen Sprint, 1 Woche Erkenntnis. Dann wäre der längstmöglische Marsch in die falsche Richtung 3 statt 4 Wochen lang. Ich gehe aber davon aus, dass eine etwas längere Erkenntnis-Phase das Feedback viel wertvoller für das Team und das Projekt macht, so dass im nächsten Sprint Planning I die Qualität der Backlog Items und deren Priorisierung wesentlich höher sein wird als ohne Off-Phase. Wer das Problem der langen Feedbacksammlung nicht hat, ist aus der Nummer sowieso fein raus.

In Krisensituationen kann ich die Teamgröße auf 3-4 Entwickler aufstocken oder die Off-Phase verkürzen, falls terminliche Schwierigkeiten entstehen. Größere Teams halte ich (in unseren Projektsphären) aber für zu ineffizient. Ich plane gern mit zwei Entwicklern, weil diese nur 1 Weg der Kommunikation haben. Mit 3 Leuten gibt es 3 Kommunikationswege, da ist der Overhead gleich ein ganz anderer.

So, das waren meine Erfahrungen mit Übergängen von Scrum-Sprints. Mich würde interessieren, ob ihr ähnliche oder ganz andere Erfahrungen gemacht habt und mit welchem Hintergrund? Oder habt ihr das Framework gleich anders interpretiert, und wenn ja, funktioniert dies?


Das mark ich mir: Alltagz Mr Wong Yigg Del.icio.us Yahoo MyWeb Blinklist Google folkd
 

2 responses to “Scrum: Sprints in On-Off-Phasen”

  1. Nudge says:

    Hallo Klaus,

    interessant. Ich habe da komplett andere Erfahrungen gemacht. Wahrscheinlich, weil ich mit kleineren Teams in kürzeren Projekten gearbeitet habe. Oder in “unsichereren” Projekten, wenn nicht ganz klar ist, was der übernächste Schritt sein wird. Mir graut es eigentlich auch vor der Vorstellung, ein Sprint Planning für die nächsten 4 Wochen durchführen zu müssen – ich will keine 4h in einem stickigen Meeting-Raum sitzen, wo alle nach 1h komplett geistig abwesend sind. Und ich wage zu bezweifeln, dass es in dieser Welt einen Product Owner solch geistiger Größe gibt, der 4 Wochen komplett für ein ganzes Team vorausplanen kann. Das merke ich bei fast jedem Entwicklungsticket, wenn Fragen aufkommen. Auf einmal wackelt das gesamte Konzept an allen Ecken und Enden. Was auch gut ist. Denn es soll ja sinnvolle, benutzbare Software entstehen. Nicht die, die im “Lastenheft” steht.
    Die 4 Wochen Sprint-Zeit sind übrigens nicht Standard, sondern die Maximal-Zeit, denn man hat festgestellt, dass eine Anforderung i.d.R. nach 4-6 Wochen hinfällig ist. Und die Meeting-Zeiten sind explizit relativ beschrieben, zB “1h pro Sprint-Woche”. Also “Dogmas” bitte ablegen, das Motto heißt “Inspect and Adapt”.

  2. Ich kenne das Scrum Dogma, wo man pro Sprint 30 Tage bzw. 4 Wochen verwenden soll. Tatsächlich haben sich die Leute dabei was gedacht. Ich habe mehrere Projekte mit 2 Wochen Sprints gehabt, die alle durch die Bank einen administrativen Overhead hatten. Das fängt vorne beim Fachlichen Input an, der nicht schnell genug ist, dann hat man vielleicht 4 Tage Zeit zum entwickeln und hinten sitzen die Tester, die es ausbaden müssen. Kurz und einfach sind 2 Wochen Sprints zu kurz. Noch schlimmer ist, wenn man für IT Dienstleister arbeitet, die einen großen Wert auf Dokumentation legen, was für SCRUM nicht taugt. Also wenn jemand einen hohe Personalfluktuation wünscht mit ausgebrannten Mitarbeitern und einen hohen Krankenstand, kann ich Erfahrungsgemäß den 2 Wochen Zyklus empfehlen. IT Dienstleister können sich damit eine goldene Nase verdienen, da die meiste Arbeit für Administration drauf geht. Effektiv sieht aber anders aus.

Leave a Reply

Your email address will not be published. Required fields are marked *