Viele Artikel über Scrum und auch der Scrum-Guide gehen zumindest implizit von Scrum-Teams aus, bei denen sich die Entwickler:innen in Vollzeit dem Projekt widmen. Was aber, wenn dies nicht oder nur eingeschränkt möglich ist? Die Zusammenarbeit über Ländergrenzen und Zeitzonen hinweg hat schon in einigen Teams zu mancher Adaption von Scrum geführt. Doch zu Scrum in Teilzeit-Teams gibt es nur wenige Informationen und Erfahrungsberichte. Deshalb möchten wir hier unsere Erfahrungen teilen und somit anderen den Zugang zu Scrum in Teilzeit-Teams vereinfachen.
Einige der in einem solchen Szenario entstehenden Probleme scheinen offensichtlich. So gibt der Scrum-Guide Ereignisse vor, die nur funktionieren, wenn das Team gleichzeitig anwesend ist. Das Daily Scrum soll zum Beispiel laut Scrum-Guide an jedem Tag zur gleichen Uhrzeit am gleichen Ort abgehalten werden, um Komplexität zu verringern. Gibt es in einem zeitlich verteilt arbeitenden Team keine regelmäßigen Überschneidungen in der Anwesenheit, muss folglich der Scrum-Prozess angepasst werden.
Andere Besonderheiten, etwa funktionierende Regeln für eine gute Kommunikation, kommen meist erst mit der Zeit auf.
Wir sind Jan und Sebastian, zwei Scrum Master in zeitlich verteilt arbeitenden Teams. In diesem Artikel möchten wir auf die Besonderheiten von Teilzeit-Scrum eingehen und unsere Learnings damit beschreiben.
Die Rahmenbedingungen
Unsere Teilzeit-Teams wurden im Rahmen der inovex Practice gebildet, einem Programm, in dem Studierende schon vor dem Berufseinstieg Praxiserfahrung mit agiler Software-Entwicklung nach dem Scrum-Guide sammeln können. Dementsprechend bestehen unsere Teams aus Scrum-Neulingen mit geringer Praxiserfahrung. Das gilt sowohl für das Entwicklungsteam als auch die Scrum Master. Die Ausnahme sind unsere Product Owner, die erfahrene inovex-Mitarbeiter:innen sind.
Unsere einzelnen Teammitglieder arbeiten unterschiedlich viel, die Arbeitszeit schwankt zwischen 5 und 20 Stunden pro Woche, in den Semesterferien bis zu 40 Stunden. Zusätzlich kann die Arbeitszeit von Woche zu Woche stark variieren und ist von Semesterferien, Prüfungsphasen und Urlaub abhängig. Lediglich die Laufzeit unserer Projekte ist von vornherein auf sechs Monate festgelegt.
Auf Los geht’s los!
Beide Projekte begannen mit einem Kick-off-Termin, bei dem sich gleich zu Anfang eine typische Teilzeit-Schwierigkeit gezeigt hat: Es ist nicht leicht, einen gemeinsamen Termin zu finden. Es bietet sich an, wenn man einen passenden Zeitraum gefunden hat, gleich mehrere Ziele im Termin zu kombinieren.
Im Kick-off sollte das Team
- sich kennenlernen,
- die Grundlagen von Scrum verstehen,
- gemeinsam mit dem Product Owner ein geschätztes und priorisiertes Product-Backlog erstellen,
- sich auf die Rahmenbedingungen einigen, unter anderem auf die Definition of Done
- und den ersten Sprint planen und starten.
Es ist sehr hilfreich, die einzelnen Bausteine von Scrum zu erklären und dann direkt anzuwenden; so entsteht sofort ein tiefgreifendes und dauerhaftes Verständnis von Scrum. In unseren Projekten folgte daher zum Beispiel auf die theoretische Erklärung eines Backlog-Refinements dessen Durchführung, in der wir die Backlog-Items besprachen und schätzten. Auch bei den weiteren Bestandteilen des Kick-offs gingen wir so vor, wodurch die Teammitglieder beim jeweils individuellen Wissensstand über Scrum abgeholt werden konnten.
Die Scrum-Ereignisse
Neben der Schwierigkeit, gemeinsame Termine zu finden, können auch die im Scrum-Guide beschriebenen Ereignisse nicht einfach in ein Teilzeit-Team übernommen werden. Dabei sind unsere Teams hier unterschiedlich vorgegangen.
Daily Scrum
Sebastian: Bei uns hat sich ein asynchrones (Daily) Scrum über Slack bewährt. Dort haben wir einen Channel eingerichtet, in dem jedes Teammitglied diese drei Fragen vor Beginn des eigenen Arbeitstags beantwortet:
- Was habe ich am letzten Arbeitstag getan, das dem Entwicklungsteam dabei hilft, das Sprint-Ziel zu erreichen?
- Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen?
- Sehe ich irgendwelche Hindernisse, die mich oder das Entwicklungsteam vom Erreichen des Ziels abhalten?
Die Fragen sind so formuliert, dass sie auch bei wenigen Wochenstunden beantwortet werden können. Bei Problemen und Hindernissen verlinkte das Team mich als Scrum Master, damit ich schnell reagieren konnte und Hindernisse nicht zu lange bestanden.
Gegen Ende des Projekts passten wir unsere Slack-Dailys nochmal an. Zu Anfang des Arbeitstags postete jedes Teammitglied die individuellen Tagesziele in den Channel und am Ende des Tages das, was wirklich geschafft wurde. Diese knappe Form maximierte den Wissenstransfer und zeigte zuverlässig Probleme auf, zum Beispiel wenn eine vorgenommene Aufgabe nicht geschafft wurde. Diese konnte dann unter Umständen von einem anderen Teammitglied fertiggestellt werden.
Jan: Wir hatten unser erstes und einziges Daily zwei Tage nach dem Kick-off. Alle waren anwesend, alle haben am Tag zuvor gearbeitet und wollten an diesem Tag arbeiten. Wir standen im Kreis und arbeiteten auf Grundlagen der drei typischen Daily-Fragen. Innerhalb der nächsten Woche kamen wir aber schnell zu der Einsicht, dass dieser Termin so nicht weiter sinnvoll durchführbar ist. Wir haben dann den Vorschlag aus dem Team ausprobiert, die Dailys ganz auszusetzen und die Kommunikation über Slack zu gestalten, was bis zum Ende gut funktioniert hat. Viel Kommunikation verlegten wir dadurch auf die Freitage, den Tag, an dem das Team oft vollständig anwesend war.
Das Halfway-Meeting
Sebastian: Um eine direkte Kommunikation zu ermöglich, gab es ein weiteres besonderes Ereignis, das wir zusätzlich zum Standard-Scrum in unsere Sprints aufgenommen haben. Nach der Hälfte des Sprints trafen wir uns für ein halbstündiges Halfway-Meeting, das per Videokonferenz stattfand. Es hat sich etabliert, das Meeting mit dem Daily-Scrum-Format zu starten. Danach gab es dann die Gelegenheit, ausführlicher die erledigten Tasks, die aktuelle Arbeit und die Probleme zu besprechen. Themenvorschläge für das Halfway-Meeting sammelten wir schon im Voraus in einem Thread in unserem Team-Slack-Channel. Nach einigen Sprints, als unser Team eingespielter war, fand das Halfway-Meeting nur noch nach Bedarf statt, zum Teil brauchten wir es gar nicht mehr gebraucht.
Sprint-Review
Jan: Schon früh zu Beginn des Projekts hat sich in einer Retro gezeigt, dass es sinnvoll ist, ab einer Stunde vor Beginn des Reviews keine Änderungen am Code mehr vorzunehmen. Last-Minute-Changes und -Fixes, die meistens doch nicht das erwünschte Ergebnis bringen, können so vermieden werden. Für uns war ein klarer Zeitpunkt zum Stoppen der Entwicklung wichtig. Das Sprint-Review-Planning fand bei uns meist nachmittags statt, während der gesamte Vormittag noch zum Entwickeln genutzt wurde und teilweise einen signifikanten Anteil am Sprint ausmachte. Gegen Ende der Practice etablierte sich die Regel, die letzten 15 Minuten vor dem Review zur Vorbereitung zu nutzen und das Product Increment noch einmal zu testen. Von mir als Scrum Master wünschte sich das Team, falls nötig, eine kleine Erinnerung daran.
Sebastian: Einen Tag vor dem Sprintwechsel bereitete unser Team das Sprint-Review vor, wofür es ein weiteres Treffen gab. Die Erfahrung hat uns gezeigt, dass es für dieses Treffen ausreichte, wenn sich zwei Teammitglieder absprechen, welche neuen Features den Stakeholdern gezeigt werden können. Eine Anwesenheit des ganzen Teams war zur Vorbereitung nicht nötig, stattdessen setzten wir je nach Verfügbarkeit auf eine wechselnde Besetzung. Bei gefundenen Bugs wurden betroffene Entwickler:innen jedoch benachrichtigt.
Besondere Herausforderungen für den Scrum Master
Jan: Da unser Team auf Dailys verzichtete, fehlte mir als Scrum Master diese wichtige Informationsquelle zum Team-Fortschritt und zu aktuellen Impediments. Unser Lösungsansatz war, mir bei Bedarf per Slack eine Nachricht mit dem Impediment zu senden. In der Praxis kam es jedoch kaum dazu, auch das direkte Nachfragen brachte nur selten Impediments zum Vorschein. Ich führe das auf zwei Dinge zurück: Zum einen darauf, dass inovex allgemein sehr agil ausgerichtet ist und somit viele Probleme gar nicht entstehen. Zum anderen scheint es mir auch daran zu liegen, dass – bedingt durch den geringen persönlichen Kontakt – etwas mehr Hemmungen bestehen.
Gegen Ende unseres Projektes habe ich mich deswegen bewusst zu dem Entwicklungsteam gesetzt mit dem Ziel, etwas in das Team hineinhorchen zu können. Ich habe gelernt, wie hilfreich es ist, gelegentlich mit Teammitgliedern in einem Raum zu sein und Fragen direkt stellen zu können. Der direkte, persönliche Kontakt fördert das Miteinander und den Einblick in das Projekt stärker, als es über die digitalen Kanäle wie Slack möglich ist. Besonders in Teilzeit-Teams ist der direkte Kontakt mit dem Development Team eine wichtige Quelle an Informationen. Als Scrum Master sollte man sich aktiv um diesen Kontakt kümmern. Im Umkehrschluss verbessert es danach auch die schriftliche Kommunikation.
(Remote) Pair Programming
Sebastian: Da wir ein Remote-Team sind, gab es keine Möglichkeit, persönlich vor Ort in Kontakt zu treten. Unsere Lösung dafür brachte, neben Slack-Dailys und Halfway-Meetings, der Einsatz von häufigem Pair Programming. Das Pair Programming hat sich in unserem Team bewährt, weil dabei aufkommende Fragen und Hindernisse sofort geklärt werden können und zudem der Wissenstransfer zwischen den Teammitgliedern maximiert wird.
Zwei Vorgehensweisen haben wir für das remote Pair Programming für besonders sinnvoll befunden:
- Ein:e Entwickler:in schreibt den Code, während der/die andere über einen geteilten Bildschirm zuschaut und mit an der Lösung arbeitet.
- Zwei Entwickler:innen treffen sich in einem Video-Meeting und arbeiten zusammen an dem gleichen Problem. Die Videokonferenz fungiert dann als Ersatz für die räumliche Zusammenarbeit. Durch die offene Kommunikationsleitung kann Wissen besser kombiniert werden als es über einen Chat-Dienst wie Slack möglich ist.
Refinement und Sprint-Wechsel
Die weiteren Scrum-Meetings wurden in beiden Teams auf einen Termin gelegt und kurz gehalten. Die zeitliche Straffung hat sich als nötig erwiesen, da in einem zweiwöchigen Sprint eines Teilzeit-Teams anteilig weniger gearbeitet wird, wodurch die Meetings sonst einen großen Teil der Gesamtarbeitszeit einnehmen. Schwierig wird es, wenn jedes Teammitglied unterschiedlich viel arbeitet. Dann muss eine individuelle Einschätzung des Scrum Masters zusammen mit dem Team erfolgen, wie viel Arbeitszeit mit Meetings gefüllt werden soll und kann. Unsere exemplarische Agenda eines Sprint-Wechsels sah folgendermaßen aus:
- 30 Minuten: Sprint Review (mit Stakeholdern)
- 1 Stunde: Retrospektive
- 15 Minuten: Pause
- 15-30 Minuten: Product Backlog Refinement
- 30 Minuten: Sprint Planning 1
- 45 Minuten: Sprint Planning 2
Als Sprintlänge hat sich trotz Teilzeit 2 Wochen in beiden Teams bewährt.
Jan: Wir haben zwischenzeitlich auch mal mit anderen Längen experimentiert. So hatten wir einwöchige Sprints, was zu schnellerem Feedback führen sollte. Dadurch wurde aber verhältnismäßig viel Zeit mit Meetings verbracht, bei einigen 50% der Arbeitszeit, weswegen wir nach zwei Wochen wieder auf den Zwei-Wochen-Rhythmus gewechselt haben. Während der Klausurphase haben wir die Sprintlänge dagegen erhöht, da für einige Zeit gar nicht gearbeitet wurde.
Die Retrospektive
Die anschließende Retrospektive ist auf eine Stunde angesetzt. Da sich Teilzeit-Teams seltener sehen, ist es besonders wichtig, für eine entspannte Stimmung zu sorgen und die gemeinsame Zeit auch für Teambuilding zu nutzen. Für Remote Retrospektiven bietet sich das Tool Scrumlr.io an. Es ist einfach zu nutzen, allerdings unterstützt es nur Board basierte Formate wie “Start, Stop, Continue“ oder “Mad, Sad, Glad“. Dieser Blog Artikel vermittelt einen Überblick über die Möglichkeiten der WebApp. Generell hilft es, das Format der Retrospektive von Sprint zu Sprint zu variieren. So sorgt man für Abwechslung und Spannung.
Sebastian: Durch zeitliche Restriktionen ist es besonders wichtig, sich auf wenige Action-Items zu einigen, an denen im nächsten Sprint innerhalb des Teams gearbeitet wird. Sind es zu viele, steigt die Komplexität, und der Fokus und somit gehen auch potentielle Verbesserungen verloren.
Um den Organisationsaufwand klein zu halten, ergibt es Sinn, das Backlog-Refinement zwischen Retrospektive und Sprint-Planning durchzuführen. Nur in Bedarfsfällen haben wir ein seperates Treffen organisiert.
Sprint-Planning
Im Sprint-Planning 1 ist es für ein Teilzeit-Team besonders wichtig, Verfügbarkeiten der Entwickler:innen für den kommenden Sprint zu berücksichtigen. So kann hier – vor allem bei variablen Arbeitszeiten – nicht einfach nach der Velocity aus dem letzten Sprint gegangen werden. Es hat sich bewährt, die konkreten Verfügbarkeiten jedes Teammitglieds abzufragen und die Menge der Backlog Items diesen anzupassen. Hier ist Flexibilität des Product Owners wichtig, der das Backlog unter Berücksichtigung der Arbeitszeiten des Teams priorisiert. Die Schwierigkeit besteht darin, mit wechselnden Bedingungen umzugehen, weil jeder Sprint anders besetzt sein kann. Dadurch kann es zu Unsicherheit im Team kommen, weshalb es besonders wichtig ist, im Vorfeld über Verfügbarkeiten zu sprechen, damit es am Sprint-Ende keine Überraschungen gibt und alle Stories bearbeitet werden.
Auch im Sprint-Planning 2 ist es in Teilzeit-Teams besonders wichtig, vorausschauend zu agieren. Wer kann wann wichtige Merge-Requests annehmen und wer kann wann welche Tasks umsetzen? Durch gute Absprache an dieser Stelle wird ein reibungslosen Ablauf des Sprints vorbereitet.
Was hat sich bewährt?
Gerade in Teams, die selten zur selben Zeit und dann auch noch räumlich verteilt arbeiten, sind Online-Kommunikationsplattformen wichtig. So haben wir einen Slack-Channel für jedes unserer Teams, in dem alles Projektrelevante besprochen wird. Daneben haben wir Jira und GitLab im Einsatz, um weitere Kommunikation und eindeutige Aufgabenverteilung zu gewährleisten. Außerdem haben sich häufige Treffen zwischen einzelnen Teammitgliedern bewährt, die auf den aktuellen Bedarf abgestimmt sind. Diese Treffen können vom Development Team selbst angesetzt werden und müssen nicht offiziell vom Scrum Master organisiert werden. Um das Teamgefühl zu stärken, ist es wichtig, projektunabhängige Kommunikation zuzulassen und zu fördern. Denn gerade in verteilten Teilzeit-Teams kann das Zwischenmenschliche zu kurz kommen.
Scrum in Teilzeit: Ja oder Nein?
Eine wichtige Frage darf am Ende natürlich nicht unbeantwortet bleiben: Ist Scrum auch in Teilzeit sinnvoll? Unsere Antwort darauf ist ein klares Ja. Neben den von uns aufgezeigten Herausforderungen für Teilzeit-Teams bleiben viele Vorteile von Scrum bestehen. Anpassung der Prozesse ist ein inhärenter Bestandteil von Scrum, deswegen ist es nicht nur akzeptabel, sondern natürlich, die Besonderheiten eines Teilzeit-Teams zu berücksichtigen.
Unsere Lessons Learned:
- Es ist besonders wichtig, auf die Balance zwischen Scrum-Ereignissen und Arbeitszeit zu achten.
- Trotz der begrenzten Zeit lohnt es sich, die persönlichen Verbindungen im Team zu pflegen, das stärkt das Teamgefüge.
- Alle Vorteile von Scrum gelten auch in Teilzeit weiterhin.
Unserer Erfahrung nach ist Scrum also durchaus teilzeitfähig. Man braucht nur etwas Flexibilität und Experimentierfreude.
