Der Scrum Master als Übersetzer und Dolmetscher

Bild: Startup Stock Photos / Eric Bailey - CC0 1.0

Einer von vielen Diskussionspunkten bei einer Scrum Master-Selbsthilfegruppe einer Fachdiskussion am Wochenende: zu den vielen Aufgaben eines Scrum Masters gehören auch die eines Übersetzers und Dolmetschers. Zum Teil im wörtlichen Sinn (immer mehr IT-Fachkräfte in Deutschland sind zugewandert und sprechen kaum deutsch), vor allem aber im übertragenen - ein Großteil der Probleme zwischen Entwicklungsteams, Fachabteilungen, Management, Kunden und sonstigen Stakeholdern hat seinen Ursprung darin, dass es vielen Beteiligten nicht möglich ist ihr Anliegen so zu formulieren, dass alle anderen es verstehen und nachvollziehen können.

Hintergrund und Ursache dieses Phänomens ist meistens die unterschiedliche Herkunft, bzw. Bildungshistorie der verschiedenen Gruppen: Entwickler haben in der Regel ein Studium oder eine Ausbildung im Bereich der Informatik oder eines verwandten Bereichs hinter sich (z.B. ein Mathematikstudium oder eine Lehre als Mediengestalter), Manager haben meistens einen betriebswirtschaftlichen Hintergrund und Mitglieder der Fachabteilungen einen ihrer Spezialisierung entsprechenden, also Marketing, Vertrieb, Einkauf, Produktion, etc. Im Rahmen ihrer Sozalisierung haben nun diese verschiedenen Gruppen ein z.T. sehr spezifisches Vokabular und Begriffsverständnis erlernt, dass sie in ihrer alltäglichen Kommunikation unbewusst und völlig selbstverständlich einsetzen. Die Verständlichkeit dieser Begriffe für den jeweils anderen wird dabei nicht hinterfragt und einfach vorausgesetzt, und zwar nicht aus bösem Willen sondern aus dem Glauben heraus, dass sie allen gleichermaßen bekannt wären. Wenn das aber nicht der Fall ist entsteht eine Kommunikationsstörung: die Nachricht wird vor dem Absenden codiert, kann aber vom Empfänger nicht decodiert werden (siehe Sender-Empfänger-Modell).

Grundsätzlich ist es zwar so, dass Störungen dieser Art von allen Teammitgliedern erkannt und vermieden werden sollten, häufig scheitert das aber, wofür eine ganze Reihe von Gründen ursächlich ist: fehlende Empathie, fehlende Selbstreflektion, fehlendes Problembewustsein, fehlendes Ausdrucksvermögen und dergleichen mehr. Ohne Hilfe würden die Beteiligten in vielen Fällen aneinander vorbeireden, deshalb am Bedarf vorbeigehende Produkte entwickeln und mit sich mit großer Wahrscheinlichkeit irgendwann in Schuldzuweisungen und Konfrontationen verstricken. Da spätestens das definitiv ein Impediment wäre sollte jeder Scrum Master möglichst früh und vorbeugend den oben genannten Kommunikationsstörungen vorbeugen, entweder indem er es delegiert oder indem er sich selbst darum kümmert. Bleibt nur die Frage: wie soll das gehen?

Der einfachste Weg ist in diesem Fall die Einigung auf eine einheitliche Codierung, bzw. auf einen gemeinsamen Sprachgebrauch. Der Versuch diesen einheitlichen Sprachgebrauch herzustellen ist beispielsweise der Grund dafür, dass oft großer Wert auf das klassische User Story-Format gelegt wird (Als [..] möchte ich [...] damit ich [...] kann). Auch das Verfassen allgemein verständlicher Akzeptanzkriterien hilft dabei ein einheitliches Verständnis herzustellen (siehe auch Qualität ist mehr als Testen: User Stories und Akzeptanzkriterien). Mit diesen relativ einfachen Maßnahmen lässt sich bereits ein Großteil der Mißverständnisse ausräumen, für den verbleibenden Rest ist dann aber tatsächlich die Arbeit als Übersetzer und Dolmetscher nötig. Zum Einen im wörtlichen Sinn (an die Fachabteilung: "Wenn ein Entwickler sagt, dass er die Datenbank indiziert, meint er damit, dass er die Produkte für die neue Suchfunktion auffindbar macht") zum Anderen aber auch für die Vermittlung von Hintergründen (an den Entwickler: "Wenn das Management die neuen Funktionen unbedingt bis November haben will liegt das daran, dass dann das Weihnachtsgeschäft beginnt").

Eine derartige Dolmetscher-Tätigkeit kann zu Beginn in erstaunlichem Ausmass zeitfressend sein, weshalb sie häufig nicht erledigt oder aufgeschoben wird. Da aber ein gemeinsames Sprachverständnis (wenn es einmal da ist) große Verbesserungen der Produktivität und des Betriebsklimas bewirken kann sollte damit so früh wie möglich begonnen werden. Und je häufiger solche Übersetzungen stattgefunden haben, desto seltener werden sie benötigt. Dabei ist es übrigens unwichtig ob sich eine gemeinsame Sprachcodierung herausgebildet hat oder ob die des jeweils anderen decodiert werden kann - Hauptsache die Leute verstehen sich.