Wir von wibas stellen fest, dass vermehrt Unternehmen „agile“ im Sinne von verteilten Teams starten. Das bedeutet viele Teams, die sich an verschiedenen Standorten befinden und sich synchronisieren müssen. Die Digitalisierung bietet die Antwort für agile verteilte Teams.
Mit dem 6. Prinzip des Manifesto for Agile Software Development stehen verteilte Teams vor einem Widerspruch: „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“ Im Scrum Guide, welcher den Fokus auf 5 bis 11 Teammitglieder setzt, findet sich ebenfalls kein Hinweis auf den Umgang mit verteilten Teams.
Aus diesem Grund haben wir am 05. Juni wieder zum Thema „verteilte Teams“ eingeladen. Nachdem wir uns über verteilte Teams im Daily Scrum sowie verteilte Retrospektiven ausgetauscht haben, lag diesmal der Fokus auf Refinements. Der Scrum Guide lässt aufgrund des kurzen Abschnitts zu dem Thema sehr viel Interpretationsspielraum und wir haben durch unseren Erfahrungsaustausch festgestellt, dass sich dieser kontinuierliche Verfeinerungsprozess in der Praxis nicht so einfach pauschalisieren lässt.
Das Usergroup-Treffen fand in einer kleinen gemütlichen Runde statt. Daher haben wir uns gemeinsam dazu entschieden, die vielfältigen Themen in der Gruppe anhand eines Lean Coffees gemeinsam zu denken und uns dazu auszutauschen. Die Reihenfolge der Themen erfolgte durch eine magische Priorisierung.
Durch diese zwei Methodiken haben wir uns mit den folgenden Fragen beschäftigt:
- Was ist bei einem Refinement zu beachten ?
- Welche Meetings eignen sich für verteiltes Arbeiten und welche nicht?
- Welche Tools helfen bei verteilten Teams (verteilten Refinements) und worauf ist bei der Verwendung von digitalen Tools zu achten?
- Was ist bei einem Refinement zu beachten?
Ein Teil von Refinements kann sein, dass Anforderungen zwischen Product Owner und Entwicklungsteam spezifiziert und detailliert werden. Doch wie detaillieren wir ohne uns im Detail zu verlieren?
Fokus hat sich beim Themenaustausch als Kernaspekt herausgestellt. Ergänzend hierzu haben wir einen starken Product Owner im Team als förderlich identifiziert, welcher spontane Themen abfängt und entsprechend priorisiert. Transparenz über die aktuellen Arbeitspaketen sowie die nächst geplanten Themen ist ebenfalls ein wichtiger Aspekt. Doch wenn trotzdem Prioritäten von neuen spontanen Themen mit bestehenden Anforderungen konkurrieren, gilt eine Regelung des Konflikts auf der höheren Managementebene als unumgänglich.
Unsere wibas Learnings zum Thema verteiltes Refinements mit mehreren Teams sind bspw.:
- Teilnahme mit jeweils 1-2 Vertretern aus den Teams für die Sicherstellung der Verbreitung der Erkenntnisse aus dem Meeting in die Teams
- Galerieansicht beim digitalen Video-Tool verwenden, damit sich alle gleichzeitig sehen und Gestiken wahrnehmen können
- Moderator benennen, um den Ablauf fokussiert und timeboxed zu gestalten
- Eine feste und wiederholende Agenda, um Stabilisierung durch Kontinuität zu ermöglichen
- Aufzeichnung des Meetings, damit Personen, die nicht teilnehmen können, die Erkenntnisse nachverfolgen können
- Durchführung von zwei Refinements innerhalb eines Sprints, um Abhängigkeiten und Impediments rechtzeitig zu adressieren
- Jeder Teilnehmer wählt sich separat in das virtuelle Refinement ein, damit alle die gleichen Meetingbedingungen haben (alle sind virtuell eingewählt)
- Ein Vorbriefing, damit die Teams sich auf das Refinement vorbereiten können
- Welche Meetings eignen sich für verteiltes Arbeiten und welche nicht?
Wenn wir die verschiedenen Flughöhen betrachten, haben wir festgestellt, dass die strategische Ebene wie bspw. die Gestaltung einer Roadmap sich nicht zum verteilten Arbeiten eignet. Gründe sind hier bspw. die Unklarheit über Themen, und dass digitale Tools (siehe Frage 3) zu unflexibel sind, um Lösungen zu digitalisieren. Aus diesem Grund hat sich der physische und persönliche Austausch bewährt. Zum Nachverfolgen kann bspw. ein Foto des letzten Arbeitsstandes digital in einer Cloud abgespeichert werden.
Die Vorbereitung eines Sprints hingegen kann zwischen Product Owner und Entwicklungsteam oder zwischen Kunde und Product Owner durch Videokonferenzen und die Verwendung von Tools wie Jira auch verteilt erfolgreich stattfinden.
Eine Geschäftsmodell-Analyse bzw. die Überprüfung des Lifecycle eines Produktes eignet sich ebenfalls für verteiltes Arbeiten. Marktbeobachtungen und Analysen können verteilt erstellt werden, indem Fragen als Stories ins Product Backlog eingepflegt und für die Sprintarbeit in kleinere Tasks zergliedert werden. Diese können digital transparent werden z.B. durch Tools wie Jira oder Trello.
- Welche Tools helfen bei verteilten Teams (verteilten Refinements) und worauf ist bei der Verwendung von digitalen Tools zu achten?
Wir haben bei der Sammlung von Tools festgestellt, dass es eine ganze Reihe gibt und man schnell die Übersicht verliert. Deshalb sollte zuerst die Frage gestellt werden, welchem Zweck das Tool dienen soll. Wir haben die Tools z.B. in folgende Kategorien aufgeteilt:
- Wissensdokumentation
- Sprint Backlog
- Product Backlog
- Kommunikation
Auf dem Flipchart findet ihr eine Sammlung unserer identifizierten, Tools die sich beim verteilten Arbeiten bewährt haben. Jira eignet sich für die operative Ebene, um Anforderungen zu digitalisieren und priorisieren. GoToMeeting und Zoom sind Videochat-Tools, um digital Meetings durchzuführen. Bei Slack lässt sich z.B. eine Timebox für Ereignisse einstellen. Confluence kann verwendet werden, um Meeting minutes oder Beschlüsse festzuhalten.
Bei der Verwendung von digitalen Tools sollte man darauf achten, dass diese die Unternehmens-Data Security sowie Data Privacy Vorgaben erfüllen. Für komplikationsfreie Verwendung ist eine frühe Einbeziehung des Betriebsrates zu berücksichtigen. Eine Schulung zur Verwendung des Tools durch die Einbeziehung der tatsächlichen Anwender hat sich ebenfalls als vorteilhaft herausgestellt.
Fazit
Die Erkenntnis des Abends: Am effektivsten und effizientesten lässt es sich in der Kollokation arbeiten – doch verteiltes Arbeiten ist in gewissen Situationen unvermeidbar. Die Digitalisierung bietet uns Lösungen in Form von Tools, dies allein macht uns jedoch noch nicht zu einem High-Performance-Team.
Es ist unsere Haltung, aufmerksam und respektvoll miteinander auch über Videochat umzugehen sowie offen gegenüber neuen Wegen zu sein. Transparenz und Fokus in den digitalen Arbeitsergebnissen zu wahren, hilft uns Aufgaben gemeinsam zu verstehen und sie weiterzuentwickeln.
Aus einem verteilten Arbeiten entsteht ein gemeinsames Ergebnis.
That’s what our readers think
Hallo Wibas-Team,
leider konnte ich an dem Termin nicht teilnehmen, daher freue ich mich umso mehr, dass hier eine Zusammenfassung bereitgestellt wurde.
Zum Thema Tools noch ein paar Gedanken von mir.
Bei der Kommunikation von verteilten Teams ist das gesprochene Wort wichtig, schriftliche Kommunikation über die diversen Chatprogramme verbrauchen nur unnötig Zeit und man verfällt der Illusion, das dort, z.B. in den Slack Channels, alle informiert werden. Am Ende hat man dann aber doch unglaublich viel “Noise” erzeugt, die Klarheit, die man mit einem “Call” erzeugt, erreicht man meist nicht. Dies gilt schon bei mittelmäßig komplizierten Fragestellungen. Lieber 15min in einen “Call” investiert, statt 60min hin und her schreiben.
Confluence eignet sich nicht nur für die Minutes, sondern auch hervorragend, um das Systemkonzept zu erstellen.
Das hört sich jetzt ein bisschen Oldschool an, hilft aber ungemein das Big-Picture zu erstellen. Ggf. kann dies schon grob und wenig detailliert nach Epics und Stories gegliedert sein, sodass es dann ein leichtes ist, die Erkenntnisse für die Entwicklungsteams in Jira zu übertragen. Jira ist gut bei der Abarbeitung der Punkte, aber eigentlich ist es ein “elektronischer Papierhaufen”. Das Big-Picture findet man in diesem Haufen nur schwer. Confluence mit seinen Seiten und Unterseiten, der Möglichkeit Prozessdiagramme etc. hochzuladen erleichtert es hingegen genau dieses Big-Picture aufzubauen und mit allen zu teilen.
Die Systemdokumentation oder Benutzerhandbücher kann man hier auch gut erstellen und aus dem initialen Systemkonzept ableiten.
Viele Grüße
René