Agilität in Offshore-Projekten

Autor Dipl-Ing. Bonka Roustcheva

Passen Agilität und Offshore zusammen?

Immer mehr Projekte müssen schneller und billiger durchgeführt werden, wobei die Anforderungen sich ständig ändern. Geschwindigkeit und Flexibilität versucht man durch den Einsatz von Agilen Methoden, meistens Scrum, zu steigern. Durch Offshore-Entwicklung hofft man, eine möglichst große Kostensenkung zu erreichen.

Die Agilen Methoden wie XP und Scrum fordern aber, dass das Team an einem Standort, in einem Raum, bei der ständigen Anwesenheit und Mitarbeit eines Kunden arbeitet.

Auch bei verteilten Teams sind schon erste Abstriche zu machen - kein Kunde vor Ort, kein gemeinsamer Raum, keine Möglichkeit, schnell zusammen zu kommen. Das macht die ständige Kommunikation schwieriger. Einer der kritischsten Erfolgsfaktoren bei den agilen Methoden ist aber gerade die „face- to- face- an- einem- Board“ Kommunikation.

Viele Erfahrungsberichte erzählen von misslungenen, aber auch gut gelungenen Versuchen, agile Techniken in Offshore-Projekten einzuführen und anzuwenden.

Man muß Kompromisse finden und Abhilfen schaffen, um Organisation und Prozess an die jeweilige Projektsituation anzupassen, aber auch aussichtslose Anstrengungen vermeiden, indem man die deutlichen Grenzen der Machbarkeit (er)kennt.

Kompromisse und Lösungen

Wenn man bewusst Kompromisse eingeht, kann man auch Lösungen finden, die durchaus die Zielerreichung von Kosteneffizienz und Flexibilität bei gleichzeitiger Höchstgeschwindigkeit und guter Qualität erlauben.

Es sind organisatorische, psychologische und technische Veränderungen notwendig, um den Übergang vom klassischen zum agilen Offshoring zu schaffen.

Die wichtigste organisatorische Frage, die zu klären wäre, ist:

Wer übernimmt die "Projekt-Führung" und -Verantwortung?

Diese Frage hat auch eine psychologische Komponente, da es unter Umständen Abgabe der Verantwortung für (Teil-)Projekte bedeutet, aber auch mit Vorschuss an Vertrauen verbunden ist, besonders wenn es um den Beginn der Zusammenarbeit geht und man noch gar keine Erfahrung gemacht hat.

Als Lösung bieten sich zwei erfolgreich erprobte Modelle an:

1. Modell –

Die Projektleitung und -steuerung wird direkt vor Ort beim Kunden erledigt, und der Offshore-Partner wird nur als "verlängerte Werkbank" genutzt.

In diesem Modell agiert die Offshore- Komponente (Gruppe, Team oder nur einzelne Teammitglieder) wie ein ständig wieder beauftragter Sub-Auftragnehmer.

2. Modell –

Die (Teil-)Projektsteuerung wird in die Hände des Offshore-Unternehmens gegeben, wobei Projektteilnehmer vor Ort beim Kunden "nur" die Rolle eines "guten Kunden/Product Owner" spielen (ständig erreichbar; bereit zu kurzfristigen Entscheidungen; ständig prüfend; über den Interessen und Wünschen des Kunden informiert; entsprechend kompetent).

Eine Variante von Modell 2: die Kompetenz als Product Owner kann voll dem Offshore Anbieter abgetreten werden, da er z.B. eine Business-Expertenkompetenz auf dem Gebiet hat. Ob allerdings dann viele Kosten erspart werden können, ist Betrachtungs- und Vertragssache. (Beispiel: Entwicklung einer SW für den spezifischen Markt in dem Offshore-Land, die ziemlich vielen rechtlichen und gesetzlichen Anforderungen genügen soll.)

Nennenswert an dieser Stelle sind die unter Umständen notwendigen Anpassungen bzw. der Ausgleich der benutzten Kommunikations- und Entwicklungstools, deren Konfigurationen und Wartung, d.h. die damit verbundenen technischen Veränderungen. In Bezug auf Scrum sei hier die Notwendigkeit erwähnt, nicht ein physikalisches, sondern (auch) ein elektronisches Scrumboard zu benutzen und ein elektronisches Kommunikationsrepository zu benutzen, und sich nicht einfach per Email auszutauschen.

Best Praktices von Scrum und die damit verbundenen Herausforderungen in Offshore Projekten:

Wenn man versucht, die Grundsätze von Scrum (und die meisten agilen Methodologien) der Umsetzung in Offshore Projekten entgegen zu stellen, kann man die damit verbundenen Herausforderungen besser erkennen und formulieren:

Typisch für Scrum: „co-located“ und „self-organized“ Teams; transparente Prozesse und Fortschritte; kurze und regelmäßige Iterationen; Erfahrungsaustausch durch face-to-face Kommunikation.

1.Herausforderung: Geografischer Aspekt

Die geografische Entfernung bereitet Probleme mit der direkten Kommunikation und auch zufälligem oder spontanem Erfahrungsaustausch. Die permanente Transparenz von Prozess und Fortschritt ist durch die Holpflicht, das eingesetzte elektronische Tool zu überwachen, etwas bedroht. Beim gleichzeitigen Einsatz von physikalischen und elektronischen Scrumboards kann die Aktualität durch die Synchronisations-Verzögerung kritisch sein!

Typisch für Scrum: Schnelles Feedback; schnelle Reaktion auf Änderungen der Kundenanforderungen; synchrone Kommunikation und Anpassung des Arbeitsplans.

2.Herausforderung: Große Zeitunterschiede

Mit sehr großen Zeitunterschieden läuft man Gefahr, nur asynchrone Kommunikation zu haben und dadurch die Arbeit oder Problembeseitigung zu verlangsamen. Die zu spät eintreffende Information über Änderungen der Kundenanforderungen, kann zu Verschwendung von wertvoller Arbeitszeit über bereits obsolet gewordene Tasks führen.

Typisch für Scrum: die Teambildung; Vertrauen und Verlass auf die Teammitglieder; Möglichkeit, Spannungen sofort zu bemerken und wegzuräumen ist essenziell für Scrum.

3.Herausforderung: Kulturelle Unterschiede

Es kann gravierende Mentalitätsunterschiede geben, die dazu führen, dass Fehler nicht ausgesprochen oder zugegeben werden.

Es ist sehr ratsam, sich über die kulturellen Unterschiede zu informieren und diese bewusst bei der Kommunikation zu berücksichtigen. In diversen Kulturen ist Eigenverantwortung nicht immer selbstverständlich und die gemachten Zusagen sind nicht immer verbindlich! Das macht den Vertrauensaufbau schwierig und beeinträchtigt, neben möglichen Missverständnissen oder falschen Interpretationen, das Verhältnis im Team.

Typisch für Scrum: Jeder soll mit jedem kommunizieren können und den ständigen Erfahrungsaustausch pflegen. Das ist dann die Voraussetzung zur Reduzierung von Dokumentationsaufwänden. Diese Kommunikation hat zum Ziel, ein gleiches Verständnis zu erarbeiten und den gleichen Wissenstand zu erreichen.

4.Herausforderung: Sprachbarrieren

Die Sprachbarriere kann größer als erwartet sein, was potentiell zu Verständigungsproblemen führt.

Es ist kein Geheimnis, dass bei uns sehr viel Dokumentation in dem so genannten Deutsch-Englisch verfasst wird. Prallt das beispielsweise auf die Vietnamesisch-Englisch-Interpretation, sind Unklarheiten, Missverständnisse und Mehrdeutigkeiten vorprogrammiert. Verstärkt wird die Wirkung durch die kürzere (zeitzonenbedingte) Zeitspanne zur direkten Kommunikation und durch Mentalitätsunterscheide.

Typisch für Scrum:

In Scrum betrachtet man die Dokumentation nur als Diskussionsgrundlage, d.h. nicht sehr detailliert und ausführlich, auf das Wesentliche konzentriert. Dadurch erspart man sich auch den Aufwand, Änderungen korrekt und überall in schriftlicher Form zu aktualisieren und erreicht in der Diskussion ein besseres, gemeinsames Verständnis, z.B. über eine User Story!

5.Herausforderung: Nur das Notwendigste in der Dokumentation /Lean Documentation

In dieser Beziehung muss man bei Offshore Projekten die größten Abstriche machen! Es ist außerordentlich wichtig, ausführlicher zu dokumentieren. Die Dokumentation sollte auch Probleme mit dem begrenzten Erfahrungsaustausch  kompensieren und robust bezüglich Zwei-oder Mehrdeutigkeiten sein!

Das Wesentliche im Überblick:

Aus Erfahrung kann man behaupten, dass Agilität und Offshore Projektarbeit sehr wohl gut und erfolgreich funktionieren können!

Offshore-Teams sollte man nicht als "Black Box" annehmen, sondern gemeinsame Kick Off Meetings am Anfang des Projektes organisieren, so dass sich nicht nur alle Teammitglieder gut kennen lernen, sondern auch die gegenseitigen Erwartungen, Prozesse und Abläufe geklärt und auf dem gleichen Nenner gebracht werden können.

Zeitzonen können auch ein unüberwindbares Hindernis sein! Wenn Sie schon Offshore Projekte haben, muss zumindest ein kleines Zeitfenster von 2 Stunden zu gemeinsamen Ritualen vorhanden sein (Stand-ups; Reviews; Retrospektiven und insbesondere die Sprint Planung), und zwar via Videokonferenzen zu „normalen“ Arbeitszeiten an beiden (oder mehreren) Standorten (Locations)!

Sprache und Kommunikation muss man besser planen und die Unterschiede in Kultur, Mentalität, Beziehungen und Hierarchien berücksichtigen! Die Sprache muss vielleicht direkter sein, und es bedarf konkreter Anweisungen (es wird exakt ausgeführt, was gefordert wird). Nicht immer sind Zusagen und Termine verbindlich, und Eigenverantwortung ist nicht selbstverständlich! Aber man kann auch die Bereitschaft zur Übernahme von Verantwortung und selbständigem Denken fördern und davon profitieren!

Es ist sehr vorteilhaft, wenn der Scrum Master, oder sogar der Product Owner, auch die Landessprache des Teams spricht und die Kommunikation nicht in einer Einheitssprache (z.B. Englisch) erfolgt, die für die Teams keine native Sprache ist!

Für erfolgreiche Offshore Entwicklung braucht man einen sehr starken technischen Experten (technical lead), und einen sehr erfahrenen Scrum Master! Es werden überdurchschnittliche Fertigkeiten in beiden Rollen gefordert, wenn man Offshore Projekte erfolgreich abschließen möchte.

In Ländern mit rasanter wirtschaftlicher Entwicklung ist die Fluktuation meistens größer! Es ist ratsam, diesen Aspekt am Anfang des Projektes einzukalkulieren, denn er ist nicht immer kontrollierbar.

Man muss die gleichen Arbeits- und Kontrolltools einführen (Training notwendig!) und versuchen die Prozesse (Scrum-Ausprägungen) schnell anzugleichen. Es ist sehr vorteilhaft, eine dedizierte Kommunikationsstelle bzw. ein Tool zu haben, und die gesamte Kommunikation zum Projekt für alle greifbar abzuwickeln. Ein zentrales Scrum Management Tool sollte den tagesaktuellen Backlog, Fortschritt im Projekt und Impediments abbilden!

Ständige Kontrolle und Kommunikation ist unbedingt notwendig!

Machen Sie deshalb Ihre Sprints so kurz, wie möglich!

Natürlich gilt es, Fallen zu vermeiden! Viel wichtiger ist es aber, schnell im Stande zu sein aufzustehen und die Fehler zu korrigieren!

Seien Sie flexibel, aber vergessen Sie nicht alle Beteiligten zu involvieren und über Änderungen zu informieren! Führen Sie Anpassungen in der besprochenen Vorgehensweise ein, wenn es Probleme gibt. Continuos Improvement, oder schrittweise Verbesserungen abzuleiten und einzuführen, könnte sogar leichter sein, wenn man „open minded“ ist und die Erfahrungen des Offshore Partners berücksichtigt!

Über die Autorin:

Dieser Artikel ist im Zuge des Kooperations- Projektes von SPQR und Think-PI entstanden.

Die THINK π GROUP unterstützt Unternehmen bei der Gestaltung ihrer Prozesse und bei der Implementierung von Lean Management.

Dipl.-Ing. B.Roustcheva verfügt über mehrjährige Erfahrung auf dem Gebiet der kontinuierlichen Verbesserung und bietet durchgängige Prozessberatung an – vom Konzept bis zur Implementierung. Durch Workshops, Coaching und Interims Management lernen die Kunden Verschwendung zu erkennen, möglichst schlanke und flexible Prozesse zur Steigerung der Wettbewerbsfähigkeit zu gestalten und ihre Wertschöpfungskette zu verbessern.

PEOPLE - PROCESS – PERFORMANCE

Kontakt | Think-PI Group | www.think-pi.de | Impressum

SPQR Informatik GmbH: IT-Beratung, Data-Management, App-Entwicklung, Konzeption und Enterprise Development