Offshore-Testing in agilen Projekten: Kommunikation in verteilten Teams

von Sandra Elster

Warum Offshore-Testen?

„Durch Offshore-Testing sparen wir Geld!“

„Offshore-Testing ist schnell!“

„Wir können unsere Teams nach Belieben skalieren!“

Offshore Testing

Das sind Gründe, die das Management dazu bewegen, ein Software-Entwicklungsprojekt zumindest in Teilen im Ausland realisieren zu wollen. Es wird erwartet, dass ein OffshoreTestteam schnell Kosten spart und somit das Gesamtbudget entlastet. Außerdem besteht der Glaube, dass durch ein Offshore-Team von Beginn an Geschwindigkeit erhöht und der Testplan problemlos eingehalten werden kann. Denn ein Offshore-Team ist doch in der Teamgröße beliebig anpassbar – je nach Bedarf, so die Überzeugung.

Indien ist ein oft gewählter Kandidat als Offshore-Standort, da Entwicklungs- und Testexpertise breitflächig vorhanden sind und die englische Sprache sich in deutschen Projekten zunehmend als Projektsprache etabliert. Auch der Zeitunterschied von 3,5 bzw. 4,5 Stunden ist kalkulierbar.
So wird das Testteam als eigenständige Einheit vom Entwicklungsteam getrenntaufgesetzt, und zwischen den Teams liegen Tausende von Kilometern und unterschiedliche Zeitzonen. Aber das macht nichts, denn durch E-Mails und Telefon kann man sich ja problemlos abstimmen, oder etwa nicht? Das Projekt beginnt …

… und nach kurzer Zeit zeigt sich, dass das Konzept nicht die gewünschten Ergebnisse liefert. Tatsächlich liegen die Kosten des OffshoreTeams sogar höher als die erwarteten Ausgaben für ein lokales Team, und die längere Einarbeitungszeit macht das Management nervös.
War es etwa die falsche Entscheidung, das Projekt in verteilten Teams zu organisieren? Diese Fragestellung werden wir im Folgenden näher beleuchten.

Warum scheint die Rechnung nicht aufzugehen?

Im agilen Entwicklungsumfeld muss sich ein Testteam, das getrennt von der Entwicklung sitzt, einer Reihe von Herausforderungen stellen.

Auf deutscher Seite erwarten wir, wie im agilen Projekt üblich, einen Tester, der auf die Entwickler zugeht und fehlende Informationen erfragt. Der agile Tester ist kommunikativ und proaktiv. Er definiert seinen eigenen Testplan und schnürt sich seine Arbeitspakete eigenständig. Er lässt sich auch durch wechselnde Anforderungen und Prioritäten nicht aus der Ruhe bringen und trägt gerne Verantwortung für seine Arbeit: die Qualitätssicherung der Software.

In der Zusammenarbeit mit dem OffshoreTeam stellt sich jedoch schnell heraus, dass es an einigen Stellen hakt. Die Arbeitsweise unterscheidet sich von unseren Vorstellungen. Wir vermissen den proaktiven Tester, der unbürokratisch das Wissen erfragt, welches er für das Testen benötigt. Wir haben das Gefühl, dass das Offshore-Team „vor sich hinwurschtelt“ und kein Verständnis vom Gesamtprojekt hat.

Und damit haben wir recht. Das OffshoreTeam hat tatsächlich keinen Überblick über das Projekt. Das Projektsetting erlaubt dem Testteam einen nur sehr eingeschränkten Blick auf das Testobjekt sowie auf die Projektstruktur im Allgemeinen. Der Tester sieht nur einen kleinen Ausschnitt des Gesamtgeschehens und versucht, die Qualität in diesem abgesteckten Bereich zu sichern. Es liegt auf der Hand, dass der Tester hierdurch oftmals im Dunkeln tappt, ohne zu wissen, welche Informationen ihm überhaupt fehlen. So weisen auch Baumgartner et al. auf die Notwendigkeit eines Gesamtverständnisses hin: „In einem agilen Team geht es nicht nur mehr darum, dass Tester sich nur mit der Bedienung der Oberfläche befassen, sondern vielmehr darum, dass sie wissen müssen, was dahintersteckt, und es auch in der Gesamtheit beurteilen können“ (BAU13, S. 85).

Es drängt sich die Frage auf, warum denn der Tester so wenig Fragen stellt oder so selten auf Probleme hinweist. Nun, zum einen spielt hier die Kenntnisreife von agilen Methoden eine Rolle. Die Nachfrage nach agiler Softwareentwicklung und Testing in Indien nimmt weiter zu. Viele indische Testing-Firmen werben mit Kenntnissen im agilen Bereich, ohne dass ihre Mitarbeiter diesbezüglich geschult sind. Agiles Testen wird dann als Mini-WasserfallVorgehen gelebt, bei dem Tester mithilfe der Dokumentation die vereinbarte Anzahl an Testfällen „herunterbeten“ – eben nur in kürzeren Iterationen als gewohnt.

Zum anderen nimmt der kulturelle Hintergrund Einfluss auf unsere Arbeitsweise. Dies bedeutet für das indische Team die Erwartung einer hierarchischen Zusammensetzung der Gruppe und eines Leaders, der das Team anweist und Verantwortung für die Ergebnisse übernimmt. Auf Anhieb klingt das so gar nicht nach agil, jedoch sollte man keine zu schnellen Schlüsse ziehen, wie sich noch zeigen wird.

Auch das Ansprechen von und Hinweisen auf etwaige Probleme findet seitens indischer Kollegen auf andere Art und Weise statt, wie sie die deutsche Seite erwarten würde. Auf deutscher Seite schätzen wir das direkte und unverblümte Wort, den Ausspruch der auf Tatsachen beruhenden Wahrheit. Mit dieser Einstellung haben nicht nur indische Partner ihre Schwierigkeiten, sondern eine ganze Reihe von (auch benachbarten) Kulturen. Tatsächlich ist der Deutsche für seine direkte und wenig einfühlsame Art bekannt und vielleicht sogar ein wenig gefürchtet. Was uns als völlig normale und sogar erstrebenswerte Arbeitsweise erscheint, nämlich Teammitgliedern stets mit direkter Offenheit zu begegnen, verschreckt den ein oder anderen Partner. Dem indischen Kollegen hingegen muss man schon genau zuhören, um zu merken, dass ihn ein Problem beschäftigt. Anstatt es auf den Punkt zu bringen, erwähnt er das Problem auf vorsichtige Art und Weise – und oft zu einem späten Zeitpunkt. In einem Nebensatz weist er auf mögliche Komplikationen hin, wenn er bereits das Gefühl hat, im dichten Problemnebel die Sicht verloren zu haben.

Betrachtet man zusammenfassend die angesprochenen Herausforderungen in der Arbeit mit einem Offshore-Testteam, stellt sich zwangsläufig die Frage, inwiefern die Schwierigkeiten auszuräumen sind und ob sich der Aufwand überhaupt lohnt:

  • Das Offshore-Test-Team hat eine nur eingeschränkte Sicht auf das Gesamtprojekt. Die örtliche Trennung führt zu Informationsverlusten.
  • Offshore-Partner werben mit dem Einsatz von agilen Testern. Tatsächlich haben diese jedoch häufig unzureichende Erfahrung in der agilen Methodik.
  • Die eigenverantwortliche Arbeitsweise im agilen Umfeld steht in vielen Offshore-Ländern in Kontrast zu einer hierarchischen Gesellschafts- und Arbeitsstruktur.
  • Kulturelle Unterschiede stellen eine Herausforderung in der Kommunikation dar. Probleme werden auf unterschiedliche Art und Weise mitgeteilt.

So haben sich in der Vergangenheit viele Projektverantwortliche nach ersten abschreckenden Ergebnissen von einer Offshore-Projektrealisierung abgewendet und sind zu altbewährten Projektsettings zurückgekehrt. Warum das Thema Offshore sich jedoch weiterhin aufdrängt und in kaum einer Projektausschreibung wegzudenken ist, liegt an einem offensichtlichen Faktor – dem Budget.

Offshore-Einsätze in der agilen Softwareentwicklung können sich lohnen, wenn man realistische Erwartungen hat und die Teammitglieder sowohl onsite als auch offshore entsprechend vorbereitet und schult. Im Folgenden betrachten wir die Schlüsselfaktoren zu einem erfolgreichen Projektsetting mit Offshore-Anteil.

Kommunikation als Schlüssel

Der Kernpunkt der erfolgreichen Zusammenarbeit im Projekt – mit und ohne Offshore-Komponente – ist die Kommunikation im Team. Betrachten wir die Wortbedeutung von „Kommunikation“ im Duden, lesen wir: „Verständigung untereinander; zwischenmenschlicher Verkehr besonders mithilfe von Sprache, Zeichen“.

Vor allem in agilen Projekten ist eine gut funktionierende Kommunikation im Projektteam entscheidend, um schnell und gezielt auf Feedback von Stakeholdern und neue Anforderungen reagieren zu können. Der tägliche Austausch zwischen Entwicklern und Testern ist die Grundlage dafür, dass der Tester parallel zum oder sogar vor dem Entwickler Testfälle spezifizieren kann.

So definieren beim Ansatz von ATDD (Acceptance Test-Driven Development) Akzeptanztests die Requirements der Software, und der Tester spezifiziert diese noch vor Entwicklungsbeginn (Gar12).

Durch ein frühzeitiges Test-Design können daher neue Funktionalitäten unmittelbar getestet und abgenommen werden. Dokumentation ist in agilen Projekten durchaus vorhanden, wird jedoch ergänzt durch die Informationen von Stakeholdern, Product Ownern, Entwicklern und Testern. Somit ist eine regelmäßige Kommunikation untereinander unabdingbar.

Die Kommunikationspsychologie offenbart, dass wir auf verschiedenen Ebenen kommunizieren. In erster Linie kommunizieren wir auf verbaler sowie nonverbaler Ebene. Des Weiteren enthält die Kommunikation immer einen Inhalts- und einen Beziehungsaspekt. Seit Watzlawick wissen wir, dass sich zwischenmenschliche Beziehungen in der Kommunikation offenbaren. In seinem ersten Werk Menschliche Kommunikation, welches 1969 erschienen ist, beschreibt Watzlawick fünf Axiome der menschlichen Kommunikation (Wat69). Das erste und oftmals zitierte Axiom besagt: „Man kann nicht nicht kommunizieren.“ Als zweites Axiom nennt Watzlawick: „Jede Kommunikation hat einen Inhalts- und einen Beziehungsaspekt, wobei Letzterer den Ersteren bestimmt.“

Betrachtet man diese beiden Grundsätze, wird einem die Herausforderung der Kommunikation in verteilten Teams sofort bewusst. Zuallererst fällt es schwer, eine persönliche Beziehung zum Gegenüber aufzubauen, wenn man sich nicht trifft und sich nicht kennenlernen kann. Man betrachtet den anderen wie durch eine Scheibe, die keinen klaren Blick erlaubt. So fehlt in allen Gesprächen der persönliche Bezug zueinander, was oftmals zu Missverständnissen führt. Denn wenn wir eine Person kennen und einschätzen können, gleichen wir das Gesagte immer mit dem Bild ab, das wir von der Person haben. So ordnen wir z. B. eine schroffe Reaktion einer schwierigen Situation zu und nehmen diese nicht persönlich. Es wird jedoch problematisch, wenn wir unser Gegenüber nicht einschätzen können. Nicht von ungefähr verstehen sich Teamkollegen nach einem gemeinsamen Bier oder einem Team-Event oft besser, da sie sich wohlwollender interpretieren und als Mensch wahrnehmen. Crispin und Gregory raten dazu, das Teamgefühl zu stärken, auch wenn Tester und Entwickler nicht am gleichen Ort arbeiten: „Testers and customers sitting close to the programmers enable the necessary communalization. If logistics prohibit co-location, teams can be inventive“ (Cri09, S. 65).

offshore testing

Zudem spielt nonverbale Kommunikation für das gegenseitige Verständnis eine große Rolle, da sie hilft, die Worte im richtigen Kontext zu deuten. So kann die Gestik verraten, wie ein „Das stimmt aber nicht“ gemeint ist. Fällt die Möglichkeit des persönlichen Gespräches weg und wird durch eine Videokonversation ersetzt, hilft zumindest noch die Mimik dabei, das Gesagte richtig einzuordnen und darauf angemessen zu reagieren. Verzichtet man jedoch auf Video und baut alleine auf eine Hörverbindung, wird es bereits deutlich schwieriger, miteinander zu kommunizieren und schwierige Situationen zu lösen. Hält man die Kommunikation per E-Mail für ausreichend (und dienlich der persönlichen Absicherung), verzichtet man auf eine weitere Quelle der Interpretation, welche durch die Stimmlage übertragen wird. Zu guter Letzt, wenn man beim Chat gelandet ist, ist oftmals gar nicht mehr ersichtlich, wie welcher Ausspruch gemeint ist.

Dieses Wissen ist beim Aufsetzen des Projektes und bei der Entwicklung einer guten Kommunikationskultur sehr nützlich. Es liegt auf der Hand, dass die Kommunikation besser läuft, je mehr Kanäle für die Interpretation der Worte zur Verfügung stehen. Dabei sei darauf hingewiesen, dass auch der Austausch über Chat-Programme gut funktionieren kann, wenn zuvor eine persönliche Basis der Verständigung geschaffen ist und die Kommunikation nicht über Chat alleine läuft.

Herausforderungen meistern

Ist ein gutes Fundament gelegt worden und kann das Team sich der verschiedenen Mittel der Kommunikation angemessen bedienen, können die zu Beginn genannten Herausforderungen im Offshore-Testing in Angriff genommen werden.

Hierzu ist es entscheidend, die einzelnen Teammitglieder zu Beginn des Projektes gezielt auszuwählen. Das Projekt-Setup dem Offshore-Partner zu überlassen, ist ungenügend, da man sich – wie auf deutscher Seite auch – der Fähigkeiten der Teammitglieder versichern muss. Es ist daher ratsam, sich persönlich und vor Ort von der ausreichenden Qualifikation der Mitarbeiter zu überzeugen. Die Investition in eine sorgfältige Teamauswahl zahlt sich aus. Ob man an dieser Stelle spart, kann durchaus über den Erfolg oder Misserfolg des gesamten Projektes entscheiden. Crispin und Gregory beschreiben die Kernkompetenzen „Selbstorganisation“ und „Proaktivität“ des agilen Testers als „Ability to work as a part of a self-organizing team in which you determine your tasks on a daily basis in coordination with coworkers rather than waiting for work to be assigned to you“ (Cri09, S. 68).

Im Folgenden ein paar Interviewfragen, die über die Eignung der Kandidaten als agile Tester Aufschluss geben können:

  • Hat der Kandidat bereits Erfahrungen in agilen Projekten gesammelt? In Projekten mit verteilten Teams? Mit ausländischen Kunden?
  • Kann die Kandidatin sich benötigte Informationen eigenständig aus dem Team beschaffen? Und mit diesen strukturiert Testfälle erstellen?
  • Wie genau geht der Kandidat bei der Testfallerstellung vor? Kann er dies an einem Beispiel zeigen?
  • Ist die Ausdrucksweise (Wortschatz, Akzent) der Kandidatin verständlich?
  • Testet der Kandidat mit Leidenschaft oder nur, weil er keine anderen Möglichkeiten hat?

Steht das Team, wird dann häufig vom Offshore-Partner eine Kontaktperson genannt (der „Team Manager“), über die die Kommunikation laufen soll. Es ist wichtig, darüber hinaus auch mit jedem einzelnen Teammitglied Kontakt aufzunehmen und zu pflegen, um den Informationsfluss zu stärken.

Aus Erfahrung lassen sich nach einer gewissen Zeit Personen definieren, die im Team eine Lead-Rolle einnehmen können und möchten. Die Test-Leads unterscheiden sich vom zu Beginn definierten „Manager“ darin, dass sie sich täglich und Hands-on mit der Materie auseinandersetzen und einen guten Überblick aufbauen. Außerdem sind sie vom Typ her kommunikationsstark und tragen zu Problemlösungen bei. Es ist lohnenswert, sich in der Zusammenarbeit mit dem OffshoreTeam auf diese Test-Leads zu fokussieren, ohne den Kontakt zu den einzelnen Testern zu vernachlässigen. Die Test-Leads unterstützen die Zusammenarbeit zwischen den Teams und halten die Kommunikation im Fluss.

Auf deutscher Seite sollte ein Testspezialist (Test Manager, Testkoordinator oder agiler Test-Coach) als „Brückenkopf“ eingesetzt werden, der unterstützt, die Testaktivitäten des Offshore-Teams mit dem Onsite-Projektgeschehen zu synchronisieren. Er nimmt die entscheidende Rolle ein, Quality-Gates zu definieren und zu überprüfen und darüber hinaus für einen guten Informationsfluss zu sorgen. Diese Person ist mit Bedacht zu wählen, da sie eher eine koordinative Coaching-Rolle einnimmt als eine im klassischen Sinne des Testmanagers hierarchisch-steuernde Rolle.

Unter diesen Voraussetzungen sind auch die oben genannten Herausforderungen wie proaktive Informationsbeschaffung, eigenständiges Test-Design und das Ansprechen von Schwierigkeiten anzugehen und zu lösen. In der Kommunikation können beide Teams aufeinander zugehen und lernen, Probleme weder unter den Tisch zu kehren, noch sie zu direkt zu formulieren und das Gegenüber hierbei vor den Kopf zu stoßen.

Fisher und Fisher geben zudem den Ratschlag, als Brückenkopf für ein Offshore-Team verlässlich und zugänglich zu sein, um genügend
Gelegenheit zu bieten, Schwierigkeiten anzusprechen und früh anzugehen:

„Be accessible and responsive (…) Find ways to make yourself regularly available to team members. This can be tricky when working across multiple time zones. Establishing a rotating schedule of in-person visits for different sites can help. Likewise, setting regular virtual meeting times (via teleconference, videoconference, etc.) provides team members with the assurance that there will be an opportunity to address questions of problems without a significant waiting period.“ (Fis01, S. 94)

Zum Aufbau eines persönlichen Bezuges sowie zum gegenseitigen Verständnis für die unterschiedliche Arbeitsweise ist es ratsam, vor allem zu Beginn des Projekts das persönliche Kennenlernen sowie einen Austausch von Teammitgliedern zu ermöglichen. Hierbei ist es wichtig, diesen Austausch in beide Richtungen zu organisieren, so dass Vertreter des deutschen Teams die Arbeit vor Ort in Indien kennenlernen und Vertreter des indischen Teams ebenso die Vorgehensweise des deutschen Teams erfahren. Zurück im eigenen Team, nehmen diese Personen eine zentrale Rolle in der gegenseitigen Verständigung wahr und wirken vermittelnd als „Botschafter“.

Letztendlich ist eine gemeinsame Basis der Verständigung zu schaffen, die über den gesamten Projektverlauf hinweg gepflegt und erweitert wird. Auf diese Art und Weise fühlt sich auch ein verteilt sitzendes Team als ein Team mit gemeinsamem Ziel.

offshore testing

Und es lohnt sich doch

Zurückkehrend zum Hauptziel des OffshoreTestings, nämlich Kosten zu sparen, ergeben sich folgende Erkenntnisse:

  • Die Effizienz des Offshore-Testteams nimmt erst nach einigen Sprints zu. Ist die anfangs etwas längere Lern- und Einarbeitungsphase abgeschlossen, kann das Offshore-Team bei guter Kommunikation genauso effizient arbeiten wie ein OnsiteTeam. Somit nimmt die Kostenersparnis zu, sobald das Team eingearbeitet ist. Diese Kostenersparnis erreicht im Verlauf des Projekts eine Plateauphase und wird somit langfristig kalkulierbar.
  • Personelle Fluktuation bleibt als einziges Risiko bestehen und muss bereits in der Planungsphase bedacht werden. Es ist nach Möglichkeiten zu suchen, die Fluktuation bei Offshore-Partnern gering zu halten. Hierbei ist es ratsam, mit dem Partner offen zu sprechen und Fluktuation ggf. an monetäre Pönale zu binden. So ist der Partner selbst darauf bedacht, für eine geringe Fluktuation zu sorgen, und investiert z. B. in gute Gehälter oder personelle Entwicklungsmöglichkeiten für seine Mitarbeiter.
  • Es zeigt sich, dass agiles Testen mit Offshore-Teams keine geeignete Maßnahme ist, um schnell Kosten zu sparen und effizient zu arbeiten. Ein Offshore-Team ist mit Bedacht auszuwählen, und es ist genügend Zeit einzukalkulieren, bis das Team effizient arbeitet. Die wichtigsten Kriterien sind hierbei die Integration des Offshore-Teams in das Gesamtprojekt und eine gute Kommunikationsbasis. Ist dies geschaffen, kann das Projektteam als Gesamtheit auf Probleme reagieren und schwierige Herausforderungen meistern. Dies wiederum führt zur gegenseitigen Schätzung der Teammitglieder – ungeachtet des Standortes.
  • Um ein Offshore-Testteam aufzusetzen, lohnt sich die Investition in Experten, die analog zu Agilen Coaches die Zusammenarbeit im agilen Projekt fördern und speziell auf Testspezifika im agilen und Offshore-Kontext eingehen. Die Entscheidung, offshore zu gehen, bringt eine Reihe an Herausforderungen in das Projekt, die das Team aufgreifen und bearbeiten muss, um erfolgreich zum Ziel zu kommen. Ein
    Testexperte kann das Offshore-Team unterstützen, zu einem effizienten und integrierten Teil der Projektstruktur zu werden und die Brücke zwischen onsite und offshore zu bilden.

Abschließend ist festzustellen, dass sich die Anforderungen an ein verteiltes Team von denen an ein reines Onsite-Team nicht maßgeblich unterscheiden. In der agilen Softwareentwicklung ist grundsätzlich eine gute Kommunikationskultur für den Projekterfolg ausschlaggebend. Ist diese nicht geschaffen, kann das Projektteam keine herausragenden Ergebnisse erbringen.

Aufgrund der räumlichen Distanz ist die Ermöglichung einer guten Kommunikation im verteilten Team eine Kernherausforderung, die durch eine Vielzahl an Maßnahmen zu meistern ist. Es gilt wie immer: (Verteilte) Kommunikation ist der Schlüssel!

Referenzen

 

  • (Bau13) Manfred Baumgartner, Martin Klonk, Helmut Pichler, Richard Seidl, Siegfried Tanczos, Agile Testing, Der agile Weg zur Qualität, Hanser, 2013.
  • (Cri09) Lisa Crispin, Janet Gregory, Agile Testing, A Practical Guide for Testers and Agile Teams, Addison-Wesley, 2009.
  • (Duden) http://duden.de/suchen/dudenonline/kommunikation
  • (Fis01) Kimball Fischer, Mareen Duncan Fisher, The Distance Manager, A Hands-On Guide to Managing Off-Site Employees and Virtual Teams, McGrawHill, 2001.
  • (Gar12) Markus Gärtner, ATDD by Example, Addison-Wesley, 2012.
  • (Wat69) Paul Watzlawick, Janet H. Beavin, Don D. Jackson, Menschliche Kommunikation – Formen, Störungen, Paradoxien. Huber, 1969.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kategorien

Recent Posts