Mein Remote-Sprint (Teil 1)

Von meinen gut fünf Jahren als Anwendungsentwickler in einem Scrum-Team habe ich nun knapp die Hälfte als Remote-Mitarbeiter verbracht. Im Folgenden werde ich die alltäglichen Hürden und ihre Lösungen sowie Best-Practices anhand eines idealisierten Sprints erläutern. Dieser erste Teil befasst sich mit dem Sprint-Planning, dem Standup und Pair-Programming.

Tag 1: Planning

Ich sitze in meinem Arbeitszimmer ca. 250 Kilometer von meinen Kollegen im Wiesbadener Büro entfernt und bin beim Sprint-Planning mittendrin statt nur dabei. Unsere PO sitzt voller Stolz vor uns und zeigt uns die neuen Aufgaben für diesen Sprint. Den priorisierten Backlog (in einem Jira-Board) hatte sie vorab schon mit mir geteilt. Alle weiteren Informationen finden sich auf einer Wiki-Seite. Dort werden noch mal die Kennzahlen des letzten Sprints (geschaffte Story Points, offene Tickets etc.) sowie wichtige Informationen zum kommenden Sprint dokumentiert.

Auf meinen beiden Bildschirmen habe ich zum einen das gesamte Team und zum anderen die Wiki-Seite zum Sprint vor mir. Im Edit-Modus sehe ich - dank Collaborative Editing - direkt, wie gerade die Anwesenheiten eingetragen werden. Werden andere Informationen auf dem Beamer gezeigt, teilen die Kollegen einfach den Bildschirm mit mir. Ich habe gemerkt, dass es wichtig ist, per Video einen Überblick über den Raum zu bekommen. Ohne diese Ebene fühlt man sich etwas verloren und kann nicht gut mitdiskutieren.

Tag 2: Let the Sprint begin

Ein "Guten Morgen" voller Tatendrang im Chat eröffnet den ersten Entwicklungstag des neuen Sprints; nun kann es endlich losgehen. Ein Blick auf das Jira-Board zeigt mir alle verfügbaren Aufgaben mit den wichtigsten Informationen und Untertickets, die zur Fertigstellung notwendig sind. Dank des virtuellen Boards sehe ich zudem, wer gerade an welcher Aufgabe arbeitet, und kann mich gegebenenfalls mit dem entsprechenden Kollegen kurzschließen.

Das Ticket bietet mir alle wichtigen Daten zur Aufgabe: Wurde schon ein Branch erstellt? Wurden Code-Änderungen gemacht? Ist der Build noch grün? Gibt es einen Screen oder sogar einen Klickdummy? Alles an einer Stelle.

Tag 3: Remote Standup

Ein wichtiges Artefakt in Scrum ist das Daily Standup. Hier bespricht das Team alle Erfolge, aber vor allem alle Hürden der letzten 24 Stunden. In unserem Teambereich haben wir dafür einen großen Monitor mit Apple Mac Mini, Genius WideCam-Kamera und Jabra Speak-Mikrofon installiert. So werde ich via Google Hangout oder HipChat eingeblendet und kann dank des Fischauges der Webcam das komplette Team sehen. Sowohl meine Kollegen vor Ort als auch ich haben unser Jira-Board geöffnet.

Nach dem Standup bleibe ich manchmal noch ein wenig im Channel und kann ein wenig Team-Atmosphäre genießen. Mittlerweile nutzen auch meine Kollegen vor Ort die Möglichkeit des virtuellen Standups, um beispielsweise mal einen Tag Homeoffice zu machen.

Tag 4: Virtual Pairing

Im Team haben wir uns vorgenommen, zu zweit zu programmieren, wenn es möglich und sinnvoll ist. Das sogenannte Pair Programming verbessert die Code-Qualität und fördert den Wissensaustausch. Eine häufig verwendete Analogie ist die des Fahrers und Navigators: Der Fahrer sitzt an der Tastatur und der Navigator diktiert mehr oder weniger. Das lässt sich dank Videochat und geteiltem Bildschirm auch super verteilt abbilden. Ein netter Nebeneffekt ist auch hier die Möglichkeit, wieder etwas vom Team mitzubekommen, da wir meistens im Teamraum pairen und Umgebungsgeräusche hörbar sind.

Für Remote-Pairing gibt es unzählige Lösungen (bspw. Remote Pair Programming), wobei sich Videochat und Bildschirm-Teilen für uns als absolut ausreichend erwiesen hat.

Tag 5: Wie war das noch mal?

Trotz der vielen Informationen im Ticket sind oft nicht alle Dinge klar oder es treten Fragen bei der Umsetzung auf. Je nachdem, wie kompliziert die Frage ist, lässt sie sich einfach im Chat klären oder über einen kurzen Videoanruf. Der Chat ist zudem der Indikator, wer gerade im Büro bzw. in einem Meeting sitzt. Er dient einer flüchtigen Kommunikation für kurze Absprachen und Informationen, ist aber auch der Ort für etwas Unterhaltung zwischendurch. Größere Dokumentationen landen im Microblog (mit Notification im Chat) oder auf einer Confluence-Seite. So ist gewährleistet, dass jede Info die gewünschte Halbwertszeit hat und im Zweifel schnell zu finden ist.

Takeaway

Bergfest - die Hälfte ist geschafft! Ein Remote-Team bedeutet einen gewissen technischen Aufwand, aber vor allem wird deutlich, wie wichtig Kommunikation und Dokumentation sind.

Es klingt beim ersten Nachdenken vielleicht nach (unnötiger) Mehrarbeit, auf den zweiten Blick zeigen sich aber die Vorteile auch für die Kollegen im Teambüro. Home-Office ist für alle ohne große Absprachen möglich. Ein Kollege kann nach seinem Urlaub relativ leicht auch während des Sprints direkt wieder mitarbeiten.

Im nächsten Teil gehe ich unter anderem auf das Schätz-Meeting, das Review und die Retrospektive ein - stay tuned!

View this post in English

Weiterführende Infos

Funktioniert verteiltes Arbeiten? Nun, es kommt darauf an!
Vom Kick-off zum Finish – Tools für verteilte und agile Teams
Das verteilte Präsenzteam – ein Widerspruch?
Der neue Meeting-Raum von Google: Hardware für bessere verteilte Meetings


Mehr über die Creative-Commons-Lizenz erfahren

Entdecke die Zukunft der agilen Transformation in der Automobilbranche beim Tools4AgileTeams at Scale "Automotive Day"!
ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar