In diesem Beitrag erzählt unser Kollege Thiago Garcia Da Silva über die Erfahrungen unseres Tech-Teams, die es bei der Umstellung auf die Arbeit im Homeoffice gesammelt hat. Er stellt kurz ihre Prozesse und die Tools vor, die seit dem dabei zum Einsatz kommen.
Seit dem Beginn der Pandemie im Jahr 2020 arbeitet das gesamte Team von metr im Homeoffice und hier möchte ich speziell auf die Erfahrungen des technischen Teams eingehen. Wir waren vorher ein sehr büro-basiertes Team, daher war der Wechsel zum Homeoffice nicht ganz einfach, aber wir haben die Gelegenheit genutzt und versucht, das Beste daraus zu machen. Seit dem ersten Tag haben wir unsere Arbeit im Homeoffice nie als eine vorübergehende Sache geplant, auch wenn wir nicht wussten, ob wir ins Büro zurückkehren würden.
Ein gutes Beispiel dafür, warum wir ein sehr büro-basiertes Team waren, war unser Sprint-Board: eine riesige Tafel mit lauter Klebezetteln, auf die wir sehr stolz waren. Uns gefiel es, echte Dinge zu bewegen. Zu unserem Glück haben wir eine Woche, bevor wir wussten, dass wir ab sofort remote arbeiten mussten, alles zu GitHub verlagert, und das war der Beginn unserer aktuellen Arbeitsweise.
Neue Arbeitsweise
Die Umstellung auf GitHub war nicht nur eine gute Entscheidung, sondern der Beginn einer kompletten Überarbeitung unserer bisherigen Arbeitsweise. Wir nutzten alles, was dort verfügbar war, und machten GitHub zum zentralen Ort für unsere Kommunikation, sowohl asynchron als auch synchron. Wir beschlossen, dass unsere Kommunikation auch dort stattfinden sollte, da sie sich hauptsächlich um den Code dreht, der nun auch dort verortet war. Das Tool “Slack” wurde für direkte Nachrichten und Ankündigungen beibehalten. Wir haben dort nur selten einen Thread, um zum Beispiel ein Problem oder etwas, das mit Code im Allgemeinen zu tun hat, zu diskutieren.
Wir haben unser altes physisches Sprint-Board gegen die Projektboard-Funktion von GitHub ausgetauscht. Und wir nutzen es, um den Überblick über das Scrum/Kanban-Board zu behalten: wer macht was, welche Aufgaben werden erledigt, was ist bereits abgeschlossen. Es funktioniert gut, man organisiert die Aufgaben in den Spalten, wie in jedem anderen Board. Es ist auch möglich, einige nützliche Automatisierungen vorzunehmen, wie z. B. das Verschieben von Spalten, wenn ein Ticket geschlossen wird. Wir haben dort einige Boards, um verschiedene Stufen unseres Prozesses zu verfolgen. Wir haben zum Beispiel eines, um Tickets zu erfassen, die verfeinert werden müssen oder Ideen für die Zukunft sind und ein weiteres nur für den aktuellen Sprint. Wir haben auch Boards für andere Teams. Ein Beispiel ist das Operations-Team, das die Arbeit an den m-gates vor Ort gemeinsam mit uns verfolgen und organisieren muss.
In diesem Beitrag erzählt unser Kollege Thiago Garcia Da Silva über die Erfahrungen unseres Tech-Teams, die es bei der Umstellung auf die Arbeit im Homeoffice gesammelt hat. Er stellt kurz ihre Prozesse und die Tools vor, die seit dem dabei zum Einsatz kommen.
Seit dem Beginn der Pandemie im Jahr 2020 arbeitet das gesamte Team von metr im Homeoffice und hier möchte ich speziell auf die Erfahrungen des technischen Teams eingehen. Wir waren vorher ein sehr büro-basiertes Team, daher war der Wechsel zum Homeoffice nicht ganz einfach, aber wir haben die Gelegenheit genutzt und versucht, das Beste daraus zu machen. Seit dem ersten Tag haben wir unsere Arbeit im Homeoffice nie als eine vorübergehende Sache geplant, auch wenn wir nicht wussten, ob wir ins Büro zurückkehren würden.
Ein gutes Beispiel dafür, warum wir ein sehr büro-basiertes Team waren, war unser Sprint-Board: eine riesige Tafel mit lauter Klebezetteln, auf die wir sehr stolz waren. Uns gefiel es, echte Dinge zu bewegen. Zu unserem Glück haben wir eine Woche, bevor wir wussten, dass wir ab sofort remote arbeiten mussten, alles zu GitHub verlagert, und das war der Beginn unserer aktuellen Arbeitsweise.
Neue Arbeitsweise
Die Umstellung auf GitHub war nicht nur eine gute Entscheidung, sondern der Beginn einer kompletten Überarbeitung unserer bisherigen Arbeitsweise. Wir nutzten alles, was dort verfügbar war, und machten GitHub zum zentralen Ort für unsere Kommunikation, sowohl asynchron als auch synchron. Wir beschlossen, dass unsere Kommunikation auch dort stattfinden sollte, da sie sich hauptsächlich um den Code dreht, der nun auch dort verortet war. Das Tool “Slack” wurde für direkte Nachrichten und Ankündigungen beibehalten. Wir haben dort nur selten einen Thread, um zum Beispiel ein Problem oder etwas, das mit Code im Allgemeinen zu tun hat, zu diskutieren.
Wir haben unser altes physisches Sprint-Board gegen die Projektboard-Funktion von GitHub ausgetauscht. Und wir nutzen es, um den Überblick über das Scrum/Kanban-Board zu behalten: wer macht was, welche Aufgaben werden erledigt, was ist bereits abgeschlossen. Es funktioniert gut, man organisiert die Aufgaben in den Spalten, wie in jedem anderen Board. Es ist auch möglich, einige nützliche Automatisierungen vorzunehmen, wie z. B. das Verschieben von Spalten, wenn ein Ticket geschlossen wird. Wir haben dort einige Boards, um verschiedene Stufen unseres Prozesses zu verfolgen. Wir haben zum Beispiel eines, um Tickets zu erfassen, die verfeinert werden müssen oder Ideen für die Zukunft sind und ein weiteres nur für den aktuellen Sprint. Wir haben auch Boards für andere Teams. Ein Beispiel ist das Operations-Team, das die Arbeit an den m-gates vor Ort gemeinsam mit uns verfolgen und organisieren muss.
