Zusammenarbeit über Grenzen hinweg
Die verteilte Softwareentwicklung an mehreren, gegebenenfalls internationalen Standorten, bietet einige Vorteile – hat aber auch ihre Tücken. Ein Experte mit langjähriger Erfahrung gibt Tipps.
Verfügbares Personal, attraktive Konditionen und mangelnde eigene Kapazitäten bewegen viele Schweizer Unternehmen dazu, Software nicht selbst zu entwickeln, sondern mit Teams zusammenzuarbeiten, die sich unter Umständen in anderen Ländern befinden – etwa in Fernost. Philipp Grüter, Product Owner und Consultant bei bbv, leitet solche Projekte, bei denen die verteilte Softwareentwicklung zum Einsatz kommt. Er gibt Tipps, wie KMU die Arbeit über verschiedene Standorte meisten können.
«Familie und Technologie sind für mich Luft und Wasser»
Müde Augen ade: So helfen kurze Codezeilen
«Die Digitalisierung scheitert, wenn sie dem Menschen die Autonomie nimmt»
«Der richtige KI-Hype steht erst noch bevor»
Kommunikation
So wie bei der lokalen Arbeit sind regelmässige Meetings auch bei der Nutzung unterschiedlicher Standorte sehr wichtig, damit alle Beteiligten immer wieder auf den neusten Stand des Projekts kommen können. Eine agile Arbeitsweise wird auch dann angewendet, wenn die Teams sich nicht Face-to-Face treffen können. Kurze tägliche Meetings bewähren sich ebenso wie regelmässige Review- und Retrospektive-Meetings.
«Mit unseren Teams in Vietnam machen wir täglich um 8 Uhr morgens ein Skype-Meeting, in Vietnam ist es dann kurz nach Mittag.»
Philipp Grüter, Product Owner und Consultant bei bbv
Zu Beginn des Projekts empfehle ich zusätzlich ein persönliches Zusammenkommen, damit sich Kundenvertreter, Entwickler und andere Projektbeteiligte kennenlernen können. Danach sind die Meetings meist virtuell.
Sind Teams aus unterschiedlichen Zeitzonen beteiligt, gilt es die täglichen Meetings auf eine für alle akzeptable Zeit anzusetzen. Mit unseren Teams in Vietnam machen wir täglich um 8 Uhr morgens ein Skype-Meeting, in Vietnam ist es dann kurz nach Mittag.
Kulturunterschiede
Kulturelle Unterschiede gibt es nicht nur, wenn man mit Teams aus Übersee zusammenarbeitet, sondern auch innerhalb Europas. Wenn etwa die direkte deutsche Art zu sprechen mit der zurückhaltenden Schweizer Redeweise zusammentreffen, können schon einmal Missverständnisse und Verstimmungen auftreten. Bei der Zusammenarbeit mit Vietnam gab es immer wieder sprachliche Hürden und davon abhängige Missverständnisse. Es gab aber auch ganz andere kulturelle Schwierigkeiten, etwa bezüglich des Designs einer Website oder der Art von Feedbacks auf eine geleistete Arbeit. Die Europäer mussten lernen, Kritik nicht zu hart zu formulieren, die Vietnamesen mussten lernen, mit verschiedenen Launen der Europäer umzugehen.
«Die wichtigste Voraussetzung für verteilte Softwareentwicklung ist der gegenseitige Respekt. Die Beteiligten aus zwei Welten müssen sich in der Mitte treffen, alle müssen sich auf die andere Kultur einlassen, ohne aber ihre eigene Kultur zu verleugnen.»
Philipp Grüter, Product Owner und Consultant bei bbv
Damit die Mitarbeitenden zweier Standorte trotz sehr unterschiedlicher Empfindlichkeiten und Ansichten gut zusammenarbeiten können, muss das Bewusstsein für kulturelle Unterschiede auf beiden Seiten vorhanden sein. Der gegenseitige Respekt ist die wichtigste Voraussetzung dazu. Die Beteiligten aus zwei Welten müssen sich in der Mitte treffen, alle müssen sich auf die andere Kultur einlassen, ohne aber ihre eigene Kultur zu verleugnen. Was an einem Ort direkt und transparent ist, kann am anderen Ort unhöflich und rüpelhaft sein. Um Missverständnisse und Konflikte möglichst gering zu halten, rate ich zu folgenden Massnahmen:
- Gemeinsame Feedback-Regeln definieren (z. B. die Feedbackformel WWW(W): Wahrnehmung, Wirkung, Wunsch, (W-Fragen) verwenden).
- Keine Wertung: Kritik nie auf eine Person richten, sondern sachlich abgeben, auf die Umstände bezogen, um die es gerade geht.
- Gelegenheiten geben, um persönliche Themen und Anliegen anzusprechen. Dies kann etwa in Retrospektive-Meetings geschehen oder bei einem Troubleshooter angebracht werden, der bei Problemen für Schlichtung sorgt.
- Gegenseitige Würdigung und persönliches Lob aussprechen.
Rollen und Verantwortlichkeiten
Es ist wichtig, zu Beginn eines Projekts zu klären, wer welche Rolle hat, wer die Verantwortung trägt und wer welche Aufgaben übernimmt. An verschiedenen Orten kann ein unterschiedliches Hierarchieverständnis vorherrschen, die Wichtigkeit von Titeln und Abschlüssen kann divergieren oder das Alter und die Erfahrung von Mitarbeitenden sehr unterschiedlich gewertet werden.
Weitere grundlegende Fragen, die zu Beginn geklärt werden müssen:
- Wer darf (und muss) entscheiden?
- Wer hat die Befugnis, beim Kunden Abmachungen zu treffen?
- Wer ist verantwortlich für welche Teilprojekte?
- Wer steht für Rückfragen und fehlende Informationen zur Verfügung?
Um die Zusammenarbeit mit dem Auftraggeber verbindlich zu gestalten soll ein schriftliches Regelwerk aufgesetzt werden, in dem festgehalten wird wer die Entscheidungsgewalt hat. Damit soll verhindert werden, dass beispielsweise Mitarbeitende ohne Befugnis einen Auftrag ausführen ohne dass die offiziellen Kanäle für die Kommunikation genutzt werden.
Spezielle Rolle: Troubleshooter und Brückenbauer
Als Ansprechperson, die auch mal unangenehme Themen ansprechen darf, hat der Troubleshooter eine wichtige Aufgabe, die viel Fingerspitzengefühl erfordert. Dies kann der Scrum Master oder der PO-Coach sein, der/die zwischen den einzelnen Personen und Teams als Projektkulturwächter waltet. Wer zwischen den Kulturen mit viel Fingerspitzengefühl diplomatisch, bestimmt und lösungsorientiert kommuniziert, leistet für andere Projektmitarbeitende als Brückenbauer wertvolle Dienste.
Tools
Bei der verteilten Entwicklung sehe ich drei Bereiche, für die entsprechende Werkzeuge wichtig sind: für die Kommunikation, das Ticketing und für die Dokumentation.
1. Kommunikation: Für Teams, die über Kontinente hinweg verteilt sind, eignet sich E-Mail meist nicht zur schnellen und permanenten Kommunikation. Deshalb kommen Videokonferenz- und Instant-Messaging-Programme zum Einsatz. Weil diese Tools nicht zu 100 Prozent verlässlich sind, sollte man sich mit dem Kunden auf 2 bis 3 Tools einigen, so dass man bei Störungen schnell ausweichen kann (und das Video-Konferenz-Bingo nicht zu schnell fertig ist).
2. Ticketing: Um sämtliche Aufträge, Fehler und Tasks zu erfassen und zu definieren, dient das Ticketing-Tool als zentrale Stelle, in dem alle Aufgaben verbindlich angelegt werden. Im Ticketing sind alle Anliegen von Auftraggebern und Entwicklern erfasst und nach Wichtigkeit priorisiert, worauf sie von den zuständigen Mitarbeitenden abgearbeitet werden. Idealerweise sollten alle projektrelevanten Aufgaben wie Anforderungen, Programmieraufgaben, Testergebnisse und Fehlermeldung in einem Tool verwaltet werden.
3. Dokumentation: Nicht alle wichtigen Daten und Dokumente können im Ticketing abgelegt werden. Ein eigenes Dokumentationssystem dient als Plattform, auf der alle Mitarbeitenden an wichtige Informationen gelangen und Dokumente ausgetauscht werden können. Eine solche Plattform kann beispielsweise ein Wiki oder eine gemeinsame Dokumentanablage sein. Darin enthalten sind etwa das Projekt-Logbuch, die technischen Dokumentationen, Konfigurations- und Testinformationen, Prozessbeschreibungen, Links und ein Ferienplaner sowie auch Sitzungsprotokolle der Refinement Meetings, der Sprint-Planungen und der Retrospektiven.
Der Experte
Philipp Grüter
Philipp Grüter war als Product Owner, Projektleiter und Consultant bei bbv tätig. In diesen Funktionen setzte er den Fokus auf das «Making» in «Making Visions Work» und sorgte dafür, dass sich seine Mandanten gut betreut fühlten und die für sie beste Lösung erhielten.
