Planning Pattern III – Code Pomodoro

23. April 2015Gerrit Beine

Im dritten Teil der Reihe zu Planning Pattern möchte ich auf eine Herausforderung der besonderen Art eingehen: In größeren Projekten werden Scrum Teams immer wieder mit einem Code konfrontiert, der von anderen Teams entwickelt wurde. Und auch wenn man sich teamübergreifend auf gemeinsame Standards geeinigt hat, in Communities of Practice zusammenarbeitet und regelmäßig in einem Scrum of Scrums synchronisiert – ein fremder Code ist und bleibt etwas anderes als der eigene Code. Das Code Pomodoro-Pattern ist eine Möglichkeit, mit dieser Herausforderung effektiv und effizient umzugehen. 

In der oben beschriebenen Situation haben etliche Teams, die ich begleitet habe, eine Art „Pre-Planning“ eingeführt: Vor dem eigentlichen Planning haben sich einzelne Leute aus dem Team mit dem Code der anderen Teams beschäftigt. Manchmal war das sogar nur ein Teammitglied.

Diese Herangehensweise erschien mir aus mehreren Gründen ungünstig:

  • Das Teammitglied, das sich im Vorfeld des Plannings mit dem Code beschäftig, muss im Planning verfügbar sein – dies kann durch unvorhersehbare Ereignisse schwierig werden. Es müssen sich also definitiv mehrere Leute mit dem Code beschäftigen.
  • Der Code ist eventuell erst am letzten Tag des vorherigen Sprints fertig. Da sind aber auch im eigenen Team Review und Retrospektive notwendig.
  • Es muss ausreichend lange vor dem Planning bekannt sein, was im nächsten Sprint entwickelt werden soll, um zu wissen, mit welchem Code man sich beschäftigen sollte. Und wenn es sich dann doch mal ändert, ist die Zeit verloren und man hat Wissen zum falschen Code aufgebaut.

Diese Überlegungen brachten mich auf die Idee, eine Methode, die ich schon längere Zeit in Workshops zum Thema Legacy Code anwende, im Sprint Planning auszuprobieren: Legacy Code Pomodoro.

Diese Methode ist eine Abwandlung der Micro-Timeboxing-Methode Pomodoro. Dort verwendet man Iterationen von 30 Minuten, in denen man sich 25 Minuten konzentriert mit einer Aufgabe beschäftigt und anschließend 5 Minuten Pause macht.

Pomodoro Zeitmesser

Mein Legacy Code Pomodoro schaut nun so aus, dass sich das Team in Gruppen von drei Personen aufteilt. Unter den Gruppen werden die User Storys, die Wissen über den fremden Code benötigen, aufgeteilt. Danach startet das Pomodoro für jede der Gruppen mit vier Phasen:

1. Zehn Minuten: Die Gruppe überlegt sich Fragen zum Code, die sich entweder aus der User Story ergeben (in der 1. Iteration) oder aus dem bereits bekannten Wissen (in folgenden Iterationen).

2. Zehn Minuten: Jedes Gruppenmitglied wählt eine Frage aus und sucht nach der Antwort.

3. Fünf Minuten: Die Gruppenmitglieder berichten sich gegenseitig von ihren Erkenntnissen.

4. Fünf Minuten: Pause

Dieses Code-Pomodoro wiederholt man drei bis vier Mal. Danach sollte eine größere Pause stattfinden, weil es sehr anstrengend ist. Optimal funktioniert die Methode zwischen dem Sprint Planning I, in dem der Product Owner die neuen User Storys für den nächsten Sprint vorstellt, und dem Sprint Planning II, in dem das Team Tasks schneidet.

Für den Scrum Master ist es wichtig, dass die Gruppen sich an die Timeboxen halten. Ist der Umgang damit zu leger, funktioniert die Methode nicht so gut. Ein gutes Werkzeug dazu ist die Pomodoro-App von Ugo Landini. Es funktioniert aber auch mit jeder normalen Eieruhr. Sie muss noch nicht einmal wie eine Tomate aussehen.

Den Teams, mit denen ich diese Methode ausprobiert habe, hat sie trotz der Anstrengung sehr geholfen. Die strenge Systematik und die knappe Timebox helfen dabei, sich auf das Wesentliche zu fokussieren.

Würden Sie die Pomodoro-Methode für Ihren Planning-Prozess einsetzen? Oder haben Sie sie vielleicht sogar schon genutzt? Ich freue mich auf Ihre Erfahrungen und Kommentare.

Gerrit Beine Gerrit Beine ist Managing Consultant bei adesso. Seit 1998 unterstützt er Unternehmen in den Bereichen Software Architektur und Agile Methoden. Mit diesen Schwerpunkten ist er regelmäßig als Sprecher auf Konferenzen und hält Vorlesungen an verschiedenen Hochschulen. Er ist außerdem Autor der Kolumne "Meditations on Agile" und reflektiert über das Thema Agilität.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentare

Christine Hennig 31. Oktober 2015

Hallo Herr Beine,

Ihre Anwendung der Pomodoro Methode auf fremden Code erinnerte mich sofort an eine Technik zum Lernen – die PQ5R Methode:
* Preview – sich einen Überblick verschaffen
* Question – Fragen, die ich habe, überlegen
* Read – lesen in normalem Tempo
* Reflect – Fragen beantworten, Gelesenes reflektieren / gibt es weitere Aspekte?
* Recite – darüber sprechen / Visualisierung erstellen / ggf. in der Gruppe
* Recap – Rekapitulieren
* Repeat – Wiederholen
Die letzten 2 Punkte dienen beim Lernen dazu, das Gelesene und Verstandene zu behalten.
Beim Code Pomodoro wird dies dann in der kommenden Iteration durch die Weiterarbeit am Code ersetzt.

Mich würden noch brennend die Gründe dafür interessieren, den Code von Iteration zu Iteration von einem anderen Team weiterbearbeiten zu lassen.

Viele Grüße
Christine Hennig

Kommentar hinzufügen:

Ihr Kommentar: