Interview
Offshoring ist für viele eine verlängerte Werkbank für IT-Projekte. Doch das muss nicht der Fall sein. Wir haben mit David Toborek von METRO.digital und Sven Dittmer von Daimler im Rahmen eines Webinars gesprochen und diskutiert, wie sie mit Distributed Delivery Software-Exzellenz im großen Maßstab realisiert haben.
Auch unsere beiden Kolleg*innen Daniel Löffelholz und Lucy Chambers haben uns Frage und Antwort gestanden. Sie erklären, wie Thoughtworks mit Kunden im Bereich von Distributed Delivery arbeitet und ihnen hilft, schnell, agil und kosteneffizient komplexe Softwareprodukte zu entwickeln.
Sven, als Senior Project Manager bei Mercedes Benz leitest du schon seit vielen Jahren erfolgreich Projekte im Automotive Bereich und hier auch immer in internationalen, verteilten Teams. Was ist der beste Aufgabenschnitt für Offshore Teams?
Sven Dittmer (Daimler): "Ich würde sagen, ein Team kann sowohl für ein relativ abgeschlossenes Produkt umfänglich zuständig sein oder man kann ihm einzelne Aufgabenpakete zuweisen. Wir haben erst einmal mit einem Thema angefangen, was relativ abgeschlossen war, als wir das erste indische Team etabliert haben. Aber sehr schnell kamen wir zu einem Punkt, an dem dieses völlig isolierte Arbeiten gar nicht mehr möglich war. Mit dem Wachstum des Produktes entstehen einfach viele Abhängigkeiten und mittlerweile arbeiten die Teams alle übergreifend, so dass sie sich auch mit anderen Teams abstimmen. Das funktioniert sehr gut. Bei einem neuen Projekt würde ich daher empfehlen, erst einmal mit einem abgeschlossenen Thema zu starten und von da aus zu wachsen."
Ein wesentlicher Erfolgsfaktor von Distributed Delivery ist, dass man nicht irgendwelche Konzepte vorgibt, sondern die Teams eine gleichberechtigte Rolle haben.
David, du bist Head of Product Marketing bei METRO.digital und warst für den Ausbau des Hubs in Berlin verantwortlich. Eine Frage an dich: Müssen Product Owner und das zugehörige Product Team am selben Standort sitzen?
David Toborek (METRO.digital): "Absolut nicht. Es dreht sich hier viel um das Thema "Facetime". Im Projekt habe ich auch manchmal morgens um sieben Uhr mit den Teams angefangen und dann erst einmal eine Stunde per Videochat gesprochen. Im Lehrbuch steht vielleicht, dass Product Owner und Product Team am gleichen Standort sitzen sollten. Aber es geht immer darum, was besprochen wird und nicht, wo wir sitzen, um es zu hören."
Was sind Risiken und limitierende Faktoren, die mit dem verteilten Setup verbunden sind?
David Toborek (METRO.digital): "Meiner Meinung nach sollte man vor allem Freiraum geben. Wir haben quasi alles komplett übergeben. Wir hatten natürlich Gespräche zu Themen wie "Namensdefinitionen" oder Roadmap, aber dann passte alles. So konnten wir eine klare "end to end" Verantwortlichkeit geben. Das hört sich auf dem Blatt Papier immer sehr schön an, aber wir haben das auch wirklich so gelebt."
Sven Dittmer (Daimler): "Das kann ich nur unterstreichen. Das größte Risiko besteht darin, wenn man sich vornimmt, agil, offshore, distributed und auf Augenhöhe zu arbeiten und es dann in der Praxis so nicht lebt. Aber wenn man konsequent bleibt, klappt es gut. Wichtig ist das Vertrauen, dass man auch jederzeit entsprechend nachjustieren kann, falls etwas falsch läuft."
Bei Distributed Delivery gilt: Ohne Freiraum kein Wachstum. Wir haben jeden Freiraum genutzt, um zu experimentieren und zu lernen.
Wie wurde mit Schwierigkeiten umgegangen, die ggf. aus den unterschiedlichen Hintergründen der Teammitglieder entstanden sind?
Sven Dittmer (Daimler): "Eventuelle Schwierigkeiten versuchen wir im täglichen Arbeiten zu erkennen und empathisch dafür zu sein. Dabei ist es ganz wesentlich, dass wir immer in einen offenen Austausch gehen. Sobald jemand das Gefühl hat, dass es Schwierigkeiten gibt, wird in den Teams miteinander gesprochen – im Idealfall natürlich die betroffenen Personen direkt miteinander oder aber auch in der größeren Gruppe. Ich denke, direkte ehrliche Kommunikation ist da am hilfreichsten. Aber ansonsten hatten wir keine Schwierigkeiten. Hier gibt es im Übrigen keinen Unterschied zwischen Offshore und Onshore, denn wenn ich mir unseren Berliner Standort ansehe, haben wir dort auch eine sehr gute, bunte Mischung an unterschiedlichen Persönlichkeiten aus der ganzen Welt."
Daniel, du bist als Lead Consultant seit fast 5 Jahren bei Thoughtworks. Du hast mit Daimler und auch METRO.digital im Distributed Setup gearbeitet. Eine Frage an dich: Nach welchen Kriterien wird der Standort ausgesucht?
Daniel Löffelholz (Thoughtworks): "Es gibt mehrere Aspekte nach denen entschieden wird, aber vor allem danach, wie viele Leute wo verfügbar sind. Dabei ist es auch wichtig, welche Fertigkeiten diese Leute mitbringen. Meistens wird daher nach Skillset und nach Verfügbarkeit entschieden."
Welche Rollen hat Thoughtworks in den Projekten bei Daimler und METRO.digital konkret abgedeckt?
Daniel Löffelholz (Thoughtworks): "Ich fange mal bei Daimler an, weil es da etwas einfacher zu erklären ist. Hier haben wir die komplette Entwicklung übernommen. Die Rolle des Product Owners und die Projektleitung gab es auf Kundenseite mit Sven Dittmer. Die Product Owner haben an der Priorisierung und der Diskussion der Requirements mitgearbeitet. Die komplette Entwicklungsleistung war aber ansonsten auf Thoughtworks’ Seite.
Bei METRO und METRO.digital war es ein bisschen anders. Wir haben dort als reines Thoughtworks-Team in unserem CRM Bereich angefangen. In anderen Domänen kamen dann später auch Entwickler*innen von METRO hinzu. Hier gab es quasi einen Ramp-up, so dass wir METRO Teammitglieder langsam in die Teams integrieren konnten. Auch am neuen Standort in Berlin war das eine Art "Einfädeln". Manche Teams sind bis heute so geblieben und bei manchen haben wir uns später herausgezogen und alles komplett an METRO übergeben. Hier galt vor allem: Freiraum geben, agil sein, auf die verschiedenen Anforderungen und auch auf die Personalentscheidungen von METRO flexibel reagieren. Das war letztlich ausschlaggebend. Im Endeffekt haben wir ganz viele Modelle gefahren, aber waren immer in der Entwicklung dabei und nicht nur Berater*innen."
Wie schafft man es, gemeinsame Standards und langfristige Strategien innerhalb der distributed Teams umzusetzen? Muss man auch gewisse Leitplanken einziehen?
Daniel Löffelholz (Thoughtworks): "Leitplanken sind natürlich sehr wichtig, um den Wissensaustausch zu gewährleisten. Die Frage ist immer, wo setzt man an. Man will einerseits den Entwicklerteams einen gewissen Freiraum geben, passend zum Problem die richtigen Tools auszuwählen. Aber natürlich muss das Ganze auch einen Business Value liefern und braucht ein bisschen Struktur. Gerade auch, wenn man länger zusammenarbeitet, wie das beispielsweise bei den METRO Projekten oder auch bei Daimler der Fall war, gibt es Überschneidungen zwischen den Teams. Da gibt es Abhängigkeiten und es muss natürlich eine gewisse Governance festgelegt sein. Wir empfehlen eine leichtgewichtige Governance, Mechanismen, Architekturprinzipien, Leitfäden zu entwickeln – einfach auch, um den Austausch zwischen den Entwicklungsteams zu fazilitieren. Vor allem die Tech Leads in den Teams sollten daher zusammen kollaborieren und sich am besten gemeinsame Ziele setzen."
Lucy, du bist Product Consultant bei Thoughtworks und unterstützt unsere Kunden auf ihrem Weg zum agilen Arbeiten. Mehr als acht Jahre arbeitest du selbst überwiegend remote – also distributed. Unsere Frage an dich: Welcher agile Framework wird für die Produktentwicklung genutzt?
Lucy Chambers (Thoughtworks): "Wir sind keine Puristen bei Thoughtworks. Bei Daimler zum Beispiel nutzen wir XP mit Spuren von Scrum, aber das muss nicht immer so sein. Im Endeffekt verwenden wir das Framework, was am besten zur entsprechenden Themenstellung passt oder verwenden die besten Aspekte von allen Frameworks."
Habt ihr mit einem eigenen Modell skaliert oder habt ihr eines der üblichen Skalierungsframeworks verwendet?
Lucy Chambers (Thoughtworks): "Wir orientieren uns an einem produktbasierten Framework namens EDGE. Das bedeutet, wir orientieren uns an den Ergebnissen und strukturieren uns entsprechend."
Daniel Löffelholz (Thoughtworks): "Ich kann dazu das Buch EDGE - Value-driven digital transformation von unseren Kollegen empfehlen. Das Buch basiert auf den Erfahrungen, die wir bei Thoughtworks weltweit gesammelt haben. Vor allem haben wir in den Projekten mit "Value Driven Prioritisation", "Lean Value Tree" skaliert und sehr outcome-orientiert gearbeitet. Hier sollte man ganz klare Ziele für die Teams setzen, eine starke Produktvision etablieren und sicherstellen, dass alle die Produktvision verinnerlichen. Dann kann man die Teams autonom laufen lassen und sollte ab und zu messen, ob man auf dem richtigen Weg ist. Das ist unser sehr leichtgewichtiger Ansatz, der im Vergleich etwas leichtgewichtiger ist als einige andere Frameworks, die es gibt und genau damit haben wir gute Erfahrungen gemacht."
Beim Thema "Distributed" haben einige Firmen berichtet, dass die Offshore Teams bei der Zusammenarbeit Schwierigkeiten hatten, sich direkt als Teil eines internationalen Teams auf Augenhöhe zu fühlen. Habt ihr das auch so erlebt?
Sven Dittmer (Daimler): "Nein, das haben wir nicht erlebt. Unsere Kolleg*innen in Gurgaon übernehmen genau die gleichen Aufgaben mit den gleichen Komplexitätsgraden wie Kolleg*innen hier vor Ort."
David Toborek (METRO.digital): "Wenn man das Projekt nur als Dienstleister-Management sieht und nicht als gleichberechtigtes Team auf Augenhöhe, dann hat man natürlich schnell ein anderes Mindset. Aber wenn man das Team in die Verantwortlichkeit und Definition der Richtung mit einbezieht, hat man auch einen gleichberechtigten, sehr guten Partner in den distributed Teams."
Das Thema Distributed Delivery war so erfolgreich, weil wir es nicht einfach nur als Dienstleistungs- und Dienstleistermanagement betrachtet haben.
Wie geht ihr mit der Zeitverschiebung um?
Daniel Löffelholz (Thoughtworks): "Die Zeitverschiebung von bis zu 4.5 Stunden ist natürlich eine Herausforderung. Daher ist zum einen die Autonomie der Teams in jedem Standort wichtig, so dass alle Teile des Teams auch unabhängig effizient arbeiten können. Die Teams in jedem Standort sind daher auch cross-funktional aufgesetzt, das heißt sie beinhalten neben den Entwickler*innen auch Business Analyst*innen und je nach Situation beispielsweise auch User Experience Designer*innen und Infrastrukturexpert*innen. Für die Abstimmung übergreifend zwischen den Teams bleibt dann genug gemeinsame Zeit. Auf der anderen Seite versuchen wir die Zeitverschiebung zu unserem Vorteil zu Nutzen. Zum Beispiel können wir in einer relativ großen Zeitspanne Support aus den Teams heraus anbieten, ohne mit On-call Schichten planen zu müssen."
Kann man je nach Land Unterschiede in der Arbeitsweise erkennen? Werden die Teams miteinander verglichen?
Daniel Löffelholz (Thoughtworks): "Thoughtworks hat eine globale Softwareenwicklungskultur etabliert, das heißt egal in welchem Land und in welchem Team wird man immer wieder dieselben fundamentalen Prinzipien und Praktiken wiederfinden. Natürlich haben unsere Projekte und Teams trotzdem genügend Freiraum, um sich auf die Projektgegebenheiten und -anforderungen anzupassen, aber einen grossen länderspezifischen Unterschied bezüglich der Arbeitsweise gibt es nicht."
Wenn ich die Chance hätte, würde ich schon ein oder zwei Jahre früher mit Distributed Delivery anfangen, um noch früher die Erfolge und Erfahrungen zu sammeln.
Was waren eure Gründe, euch für die Firma Thoughtworks gegenüber anderen großen IT Services Providern zu entscheiden?
David Toborek (METRO.digital): "Wir haben uns konkret für Thoughtworks entschieden, denn es ging uns nicht nur um Delivery. Wir haben im Projekt auch viel gelernt; zum Beispiel wie man User Research macht und wie man die Problemstellung konkret evaluiert. Wir haben nicht nur eine Entwickler-Leistung eingekauft, sondern auch den “educational benefit” durch Methoden und Best Practices.
Auch hier konnten wir Thoughtworks entsprechend viel Freiraum lassen, uns zu sagen, wie man die Problemstellungen entsprechend angeht. Wir haben eine Frage uns gemeinsam sehr oft gestellt: Wie machen wir es richtig. Und Thoughtworks hat entsprechend geholfen, die Antwort darauf zu finden. Da gab es auch mal Reibung, aber gerade das war wichtig, um die Problemstellung von allen Seiten zu betrachten. Es ging uns schließlich um digitale Transformation und nicht nur reine Softwareentwicklung."
Gesprächspartner*innen
Head of Product Marketing, METRO.digital
Senior Project Manager, Daimler AG
Lead Business Analyst, Thoughtworks
Lead Consultant, Thoughtworks