Es ist unstrittig, dass sich Kommunikationsmuster und auch Qualität von Kommunikation im Ergebnis der Zusammenarbeit von Menschen niederschlagen. Oftmals werden aktive Maßnahmen ergriffen, Kommunikation zu verbessern. Dieser Artikel stellt die Frage von der anderen Seite: Welche Rahmenbedingungen müssen für gelungene Kommunikation erfüllt sein, damit weitere Maßnahmen fruchten können?
Melvin Edward Conway machte bereits 1968 die Beobachtung, dass Strukturen von Systemen durch die Kommunikationsstruktur der sie umsetzenden Organisationen vorbestimmt sind. Diese Beobachtung ist unter dem Namen Conway’s Law bekannt. 1968 gab es den Begriff Microservices wahrscheinlich noch nicht, den Begriff Modul hingegen schon. Conway beobachtete, dass gerade an den Schnittstellen zwischen Modulen Reibungsverluste auftraten. Ein treibender Faktor für diese Reibungsverluste ist zwischenmenschliche Kommunikation, genauer gesagt, nicht optimal verlaufende Kommunikation.
Mein Kollege Alexander greift dieses Thema in seinem Artikel „Probleme bei der Einführung von Microservices“ auf. Ausgehend vom Begriff des cross-funktionalen Teams stellt er die Frage, wie die Kommunikation innerhalb dieses Teams verbessert werden kann, so dass dieses Team in einem Softwareprojekt ähnlich gut wie ein OP-Team bei einer Herzoperation zusammenarbeiten kann.
Räumliche Nähe, persönliches Kennenlernen oder gemeinsame Freizeitaktivitäten werden dabei als Facilitatoren zwischenmenschlicher Kommunikation identifiziert ebenso wie von außen herbeigeführte Teambildungsmaßnahmen, Ganztages-Workshops oder auch längere Brainstorming-Sessions.
Für mich haben diese Ideen und Maßnahmen eine positive Natur, sie sollen aktiv fördern.
Was aber ist mit Faktoren, die gelungene Kommunikation verhindern oder erschweren? Drei Themen, die mir in den letzten Jahren immer wieder begegneten und die eng miteinander verknüpft sind, sind:
- Mangelndes Vertrauen
- Fehlende Ziele
- Angst
Mangelndes Vertrauen in ein Team oder innerhalb eines Teams führt zu starren Kontrollstrukturen und engen Vorgaben. Aufgaben werden feingranular vergeben und nicht cross-funktional. Menschen, die bisher im Backend tätig waren, werden auch zum Beispiel weiterhin nur einen - nämlich „ihren“ eigenen - Ausschnitt des Backends betrachten.
Fehlen dabei Ziele oder existieren diese nur außerhalb des Teams, verschlimmert sich das Problem noch: Anstatt evaluieren zu können, ob ein größeres Ziel erreicht wurde, wird nur noch die Erfüllung eben jener kleinteiligen Aufgaben kontrolliert.
All das schürt Ängste. Der Begriff Angst wurde bereits in verschiedenen Science-Fiction- beziehungsweise Fantasy-Büchern und -Filmen sehr treffend charakterisiert: Frank Herbert beschrieb Angst als „the Mindkiller“ („Litany Against Fear“, Dune, 1965), in Star Wars wird Angst als Weg zu Zorn und schlussendlich zu Leiden bezeichnet.
So drastisch muss es nicht sein, aber Angst verhindert offene Kommunikation. Menschen mauern und schützen ihre eigenen Silos. Verhaltensmuster, die sich fast eins zu eins in Mikro- und auch in Makroarchitektur von Systemen wiederfinden.
Die Ideen und Gedanken zu diesem Text wurden auf einem innoQ-Event gesammelt. Viele der innoQ-Events werden als Open Space organisiert. Ein Open Space ist ein Format, das gezielt offene Kommunikation ermöglichen soll. Der Impulsgeber war die Session „Hilfe, ich schreibe schlechten Code“, deren eigentliches Thema sich sehr schnell in Richtung Kommunikation an sich entwickelte. Was sage ich über mich selber, was über andere aus, wenn ich Codequalität bemängele oder vermeintlich bessere Qualität versuche vorzuleben? Gibt es überhaupt einen Raum und Empfänger im Raum für Fragestellungen dieser Art? Oder sind alle beteiligten Menschen so sehr in ihrem Kontext gefangen, dass jede Infragestellung als Angriff gesehen wird?
Ich möchte in einem Projekt offen über diese Themen sprechen können und sehe es - auch und gerade als IT-Berater - als meine Aufgabe an, die eigenen Fähigkeiten hinsichtlich inklusiver und gewaltfreier Kommunikation zu trainieren. Als Techniker liegt es nahe, auf viele Probleme technische Lösungen anzuwenden. Bevor wir das tun, sollten wir die richtigen Rahmenbedingungen schaffen und Faktoren beseitigen, die Kommunikation be- oder gar verhindern:
- Ein funktionierendes Anforderungsmanagement betreiben, um Ziele zu definieren, die ein eigenständiges Arbeiten ermöglichen. Dabei schaffen SMARTe Ziele (Spezifisch, Messbar, Ansprechend, Realistisch und Terminiert) Verständnis für das Ziel und seine Rahmenbedingungen.
- Den Personen beziehungsweise dem Team Vertrauen entgegen bringen, diese Ziele in ihren Rahmenbedingungen zu erreichen und damit ein selbstbestimmtes Arbeiten zu ermöglichen.
- Vertrauen kann nur entstehen, wenn die beteiligten Personen als solche wahrgenommen und respektiert werden. Erfahrener Respekt fördert Selbstsicherheit. Ohne Selbstsicherheit ist es schwierig, die Positionen anderer Menschen einzunehmen. Damit fällt eine notwendige Voraussetzung für Kritikfähigkeit - sowohl in gebender als auch in nehmender Hinsicht - weg.
Weder räumliche Nähe, noch Teambildungsmaßnahmen, noch Technik können diese Versäumnisse in meinen Augen aufholen. Gelungene Kommunikation in einem angstfreien Miteinander spiegelt sich - ebenso wie das Gegenteil - in Softwaresystemen wider.
In technischem Hinblick scheint es erwiesen zu sein, dass vertrauensvolles und angstfreies Arbeiten wichtig ist (vergleiche dazu den Artikel „Unendliches Vertrauen“ von Eberhard Wolff). Es ist wünschenswert, dass wir diese Haltung schon vor dem Einsatz technischer Lösungen einnehmen.
Ein ganz herzlicher Dank für ihr Feedback geht an meine Kollegen Ben, Eberhard, Alexander, Carsten, Claudia und Stefan.