Scrum for One

30.04.2023

Viele Teams besonders in der Softwareentwicklung arbeiten agil zusammen, oft im sogenannten Scrum Framework. Aber was ist, wenn ich alleine arbeite? Für meine Masterarbeit wollte ich es mal ausprobieren und kreiere mein eigenes Scrum for One.

Was genau ist eigentlich Scrum?

Scrum ist eine agile Vorgehensweise, bei der iterativ entwickelt wird, d.h. in jeder Iteration entsteht idealerweise ein neues (lieferbares) Produkt. Den Zeitraum einer Iteration wird in Scrum Sprint genannt und kann von einer Woche bis zu mehreren Wochen reichen und individell je nach Team angepasst werden.

Die Basis für die Aufgaben bildet das sogenannte Product Backlog, in dem beschriebene Anforderungen an das Endprodukt stehen. Am Anfang eines Sprints werden dann vom Team Aufgaben ausgewählt, die in diesem Sprint zu erledigen sind, die das Sprint Backlog bilden und ein übergreifendes Sprintziel gesetzt.

Während der Arbeitsphase gibt es jeden Tag ein kurzes Meeting, Daily Scrum, bei dem sich das Team gegenseitig erzählt, was bei ihnen gerade ansteht. Oft werden folgende drei Fragen verwendet:

Dadurch kann sich das Team gut gegenseitig unterstützen und Expertise besser genutzt werden.

Am Ende der Arbeitsphase gibt es eine Sprint Review, bei der auch Stakeholder und Interessenten außerhalb des Teams hinzugeholt werden und das neu entstandene Produkt besprochen wird. Funktionalitäten, die nicht erledigt wurden, kommen wieder ins Product Backlog.

Zum Abschluss gibt es im Team noch eine Retrospektive, meiner Meinung nach eines der unterschätzen Meetings in Scrum. Dort wird reflektiert, was in diesem Sprint gut oder schlecht gelaufen ist und wie man die Zusammenarbeit in Zukunft verbessern möchte.

Und wie mache ich das jetzt alleine?

So viel erstmal zum Scrum Framework. Dort gibt es meistens viele Beteiligte von Product Owner, Scrum Master und Teams von drei bis neun Personen bis zu Stakeholdern. Wie macht man das jetzt alleine? Man macht es ein bisschen wie der Butler aus “Dinner for One” und versetzt sich immer wieder in eine neue Rolle: Als Product Owner bestimmt man, welche Dinge Priorität haben und in den Sprint kommen, als Scrum Master moderiert man seine eigenen kleinen Meetings und man ist natürlich auch sein eigenes Ein-Personen-Team.

In meinem Fall habe ich für meine Masterarbeit habe ich wöchentliche Treffen mit meinem Betreuer, daher habe ich meine Sprints auf eine Woche gesetzt. Das Treffen bildet für mich schon meine Sprint Review mit meinem “Stakeholder” und beeinflusst meine Priorisierung für den nächsten Sprint.

Nach meiner Sprint Review werde ich also zum Product Owner, plane meinen nächsten Sprint und setzte mir ein Sprintziel. In meiner Masterarbeit habe ich an sich zwei Produkte, einmal die Masterarbeit an sich und die Implementierung des Interfaces, welches ich dafür anfertige. Je nachdem mit welchem Produkt ich mich beschäftige, habe ich also auch unterschiedliche Product Backlogs, von denen ich mir Aufgaben nehme. Gleichzeitig füge ich in der Rolle als Product Owner auch laufend Aufgaben hinzu. In Notion, meiner Notiz-App, habe ich ein sogenanntes Scrum-Log, in dem ich mir zu allen Meetings Notizen mache und vorformulierte Fragen beantworte.

Jeden Tag beantworte ich auch die drei Fragen aus dem Daily Scrum und am Ende der Woche gibt es eine Retrospektive, für mich mit folgenden Fragen:

Diese Fragen aus der Scrum Master-Perspektive helfen mir dabei, aus der Tunnel-Sicht von Problemen als Entwickler oder Autor herauszukommen.

Was bring Scrum for One?

Auch wenn das erstmal viel klingt, ist das alles kein großer Zeitaufwand. Ich ziehe allerdings mehrere positive Effekte daraus:

  1. Ich sehe meinen Fortschritt mehr.

    2. Vor allem durch meine Daily Scrums sehe ich mehr, was ich eigentlich in einem Tag geschafft habe, auch wenn ich mich unproduktiv gefühlt habe. Im Product Backlog behalte ich zusätzlich eine “Erledigt”-Spalte, durch die auch ungreifbare Dinge in der Implementierung sichtbarer werden.

  1. Ich behalte die Übersicht.

    2. Wenn ich will, kann ich mich auch mal im Detail verlieren und will “nur kurz” mal den Anzeigefehler im Code finden. Durch mein Sprint Ziel weiß ich aber, dass das gerade nicht wichtig ist. Durch mein Sprint Backlog definiere ich also auch ein Nicht-Jetzt-Backlog (oder auch eine Not-To-Do Liste).

  1. Ich bin ehrlicher mit meiner Energie und meinen Zielen.

    2. Habt ihr auch schon mal eine riesige To-Do-Liste geschrieben und euch dann schlecht fühlt, wenn ihr am Ende eines Tages kaum etwas davon erledigt habt? Durch die Retrospektive lerne ich, wie meine Energie sich verändert und durchs Planen, wie viel ich realistisch in einer Woche schaffen kann. Z.B. gibt es in meiner Masterarbeit eher weniger Aufgaben, die mir nur wenig Konzentration abverlangen. Daher muss ich bewusster Pausen setzen als z.B. vorher im Vorlesungsalltag.

Es hilft also schon manchmal den Butler zu spielen, auch wenn man dabei hoffentlich weniger stolpert als in “Dinner for One”. Wenn ihr also nächstes Mal vor einem Projekt steht, könnt ihr ja selbst ausprobieren, ob “Scrum for One” auch etwas für euch ist oder welche Elemente ihr in euren Arbeitalltag einbauen könnt.