Von meinen gut fünf Jahren als Anwendungs-Entwickler in einem Scrum-Team habe ich nun knapp die Hälfte als Remote-Mitarbeiter verbracht: Während der Rest meines Teams in Wiesbaden im Büro zugegen ist, arbeite ich 250 Kilometer entfernt in meinem Home-Office im Schwabenland. Wie verteiltes Arbeiten bei uns funktioniert, ist Thema dieses zweiteiligen Beitrags. Im ersten Teil des Blog-Artikels ging es unter anderem um das Sprint-Planning, das Stand-Up und Pair-Programming. Nun widme ich mich dem Backlog-Refinement, den Code-Reviews und unseren Retrospektiven.
Tag 6: Backlog-Refinement
Nach dem Wochenende wartet ein prall gefülltes Backlog auf ein Refinement, das dazu dient, die User-Stories zu prüfen und auszudefinieren. Wir besprechen offene Punkte, Unklarheiten und Fragen mit dem Ziel, jeweils eine handhabbare Story zu haben, die wir im nächsten Sprint in Angriff nehmen können.
Um das zu erreichen, ist es wichtig, die Story zu beschätzen. Dafür gibt es vielerlei Vorgehensweisen und Schätzgrößen. Bei uns schätzen wir die Komplexität und nutzen dafür das Konzept der Story-Points. Für die Zuordnung gehen wir meist nach dem Prinzip der Magic Estimation vor. Dieses betrachtet die Komplexität im Verhältnis zu anderen User-Stories. Es ist einfacher zu sagen, Story A ist komplexer als Story B, als Story A einen absoluten Wert zuzuordnen.
Lange Rede kurzer Sinn: Wir haben in der Regel fünf bis zehn User-Stories, die im ersten Schritt im Verhältnis zueinander angeordnet werden. Dazu hängen die Entwickler die ausgedruckten Stories reihum an die Wand. Parallel synchronisiert ein Kollege in Confluence die Anordnung der Stories im Live-Edit-Modus. In Jira verwenden wir statt des standardmäßigen Jira-Issue-Makros unsere App Jira Issue Manager, da hier die Ticketbeschreibung auch im Edit-Modus lesbar ist.
Ich sehe somit alle Stories; das Hin- und Herschieben meiner Story, bis der richtige Platz gefunden ist, übernimmt ein Kollege für mich. Nachdem alle Stories hängen, passen wir die Reihenfolge noch einmal Schritt für Schritt an. Sind schließlich alle einverstanden, gruppieren wir die User-Stories und versehen jede Gruppe mit einer Story-Point-Zahl.
Tag 7: There's a Bug in my Plugin
Im Produktgeschäft kommt es häufig zu Bugmeldungen, die die unterschiedlichsten Ursachen haben können. Häufig gilt es im ersten Schritt, zunächst Infrastruktur- und Versionsfragen zu klären.
Lässt sich der Bug nicht nachstellen, muss eine Fehlbenutzung ausgeschlossen werden. Je nach Problembeschreibung ist es in diesem Zusammenhang sinnvoll, wenn ein Mitarbeiter mit technischem Hintergrund (Entwickler) mit dem Kunden spricht. Da wir in der Regel keinen direkten Zugriff aufs Kundensystem haben, greifen wir zumeist auf Desktop-Sharing-Sessions zurück. Dafür ist es glücklicherweise egal, wo ich mich gerade befinde.
Läuft es schließlich auf einen echten Bug hinaus, erstelle ich einen Vorgang in Jira und lasse ihn von unserer PO einpriorisieren. Während dieses ganzen Prozesses bekommt der Kunde gar nichts davon mit, dass ich mich nicht im Teambüro aufhalte; für ihn ergeben sich aus der Remote-Situation keinerlei Nachteile.
Tag 8: Code-Review
Um eine Story wirklich abzuschließen, ist neben der reinen Umsetzung auch die Qualitätssicherung notwendig. Dazu gehören der fachliche Test (Testen der Akzeptanzkriterien), UI- und UX-QS, Kompatibilitätsprüfungen und ein Code-Review.
Wir haben uns darauf geeinigt, dass mindestens ein Kollege aus dem eigenen und einer aus einem anderen Team den Code gesehen haben soll. Dazu wird in Atlassian Bitbucket ein sogenannter Pull-Request eröffnet, in dem alle Änderungen sichtbar sind. Dort können die Reviewer in jeder Zeile Kommentare und Aufgaben hinterlassen, die der Ersteller dann beheben kann. Sind alle Aufgaben erledigt, können die Reviewer den Pull-Request genehmigen. Wenn dann auch noch der Build-Server (Bamboo) "alles Grün" meldet, kann der neue Code gemergt werden und die Story ist fertig.
Ich bin gerne Code-Reviewer und sehe dies auch als gute Möglichkeit, mit den Entwicklern anderer Teams in Kontakt zu kommen. Ohne die Anwesenheit im Büro kann es leicht passieren, dass man nur dem eigenen Team präsent ist. Ich versuche daher, an möglichst vielen übergreifenden Projekten und Meetings teilzunehmen.
Eines dieser Meetings ist unser Entwickler-Weekly. Dort treffen sich interessierte Entwickler aus allen Teams und berichten von Herausforderungen, Lösungen und Tools. Wie bei anderen Meetings kann ich mich leicht dazuschalten und bin dann live dabei.
Tag 9: AgileOrg-Review mit LiveStream
Einmal im Monat gibt es bei uns das Review der AgileOrg, unseres kontinuierlichen unternehmensweiten Verbesserungs- und Veränderungsprozesses. Hier präsentieren die einzelnen Arbeitsgruppen den Kollegen ihre Ergebnisse. Außerdem werden neue Mitarbeiter vorgestellt, Infos zur allgemeinen Lage des Unternehmens geteilt usw.
Es lohnt sich also für jeden Mitarbeiter, direkt dabei zu sein, um keine wichtigen Informationen zu verpassen. Seit neuestem wird die Veranstaltung direkt in einem Stream via YouTube Live übertragen und steht zudem im Nachhinein als Aufzeichnung parat. Davon profitieren auch Kollegen, die aus anderen Gründen nicht vor Ort sein können. Die Qualität ist mit richtiger Kamera und gutem Mikrofon deutlich besser als mit herkömmlichen Video-Chat-Diensten. Wer Fragen hat, kann sie dem Moderator parallel via Hipchat-Channel stellen.
An der AgileOrg kann ich natürlich auch als Remote-Mitarbeiter teilnehmen. Dass ich überhaupt von zu Hause aus arbeite, wurde damals in einer AgileOrg-Story geplant und umgesetzt (siehe dazu Funktioniert verteiltes Arbeiten? Nun, es kommt darauf an!).
Tag 10: Review und Retro
Am Ende jedes Sprints sieht der Scrum-Prozess das Review vor. Es soll direktes und vor allem schnelles Feedback vom Kunden erzeugen. Da wir uns im Produktgeschäft bewegen, arbeiten wir selten nur für einen Kunden und haben kein klassisches Review, wie man es aus anderen Scrum-Teams kennt. Ersatzweise gibt es ein internes Review (den sogenannten Jour Fixe), in dem alle fünf Entwicklungsteams ihre Errungenschaften präsentieren und von internen Stakeholdern Feedback erhalten. Falls ich hier etwas zeigen möchte, stellt ein Teammitglied seinen Rechner für die Präsentation zur Verfügung und überträgt meinen Bildschirm.
Die Retrospektive ist der teaminterne Abschluss des Sprints und dient der kontinuierlichen Verbesserung sowie der Klärung von Problemen auf allen Ebenen. Da es hier häufig auch um Befindlichkeiten geht, ist die Retro nach meiner Erfahrung das schwierigste Remote-Meeting in Scrum. Sehr viele Metainformationen - gerade in Konfliktsituationen - sind schwer per Video zu erkennen. Darum versuche ich, meine Besuche im Büro immer mit dem Retro-Termin zu synchronisieren.
Für den Scrum Master ist eine Remote-Retro auch besonders anstrengend, weil er Moderator und gleichzeitig mein verlängerter Arm ist. Bei der Themensammlung (beispielsweise die 4 L's) hat es sich bewährt, meine Punkte per Hipchat mit dem Scrum Master zu teilen. Dieser schreibt alles auf Zettel und klebt sie an, während ich meine Beiträge kurz erläutere.
Wenn andere Methoden zum Einsatz kommen (z.B. mit tollen Postern), bekomme ich diese vorab per E-Mail oder Hipchat zugesandt. Diskussionen via Video-Chat sind anders und es dauert eine ganze Weile, bis sich das ganze Team daran gewöhnt hat.
Takeaway
Wie schon im ersten Teil gesehen, sind für die Integration eines Remote-Mitarbeiters in ein agiles Team eine gute Planung und vor allem ein Bewusstsein für ein virtuelles Gegenüber notwendig. Alle teaminternen, aber auch die unternehmensweiten Meetings müssen remote-fähig sein und Teilhabe ermöglichen.
Ist die Infrastruktur erst einmal vorhanden und ist es eine Selbstverständlichkeit, Teilnehmer außerhalb des Büros zu haben, profitieren letztendlich alle Mitarbeiter. Den Live-Stream des AgileOrg-Reviews schauen sich im Schnitt mehr Leute an als es überhaupt Remote-Kollegen gibt, und noch einmal so viele greifen auf das Angebot der Aufnahme zurück.
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
