Kommunikation: Klartext. Freundlich, prägnant, kein Schnickschnack
Softwareentwickler sind nicht gerade als die großen Kommunikatoren bekannt. Doch was heißt schon groß? Vielleicht legt man hier die falschen Maßstäbe an.

(Bild: Jeffrey F Lin/Unsplash)
- Stefan Mintert
Moin.
Sprechen vor Publikum ist eine große Sache. Es gibt Vereinigungen für Sprecher, es gibt Debattierklubs, es gibt Sprachtrainer und vieles mehr. Wer überzeugen will, muss ein grandioser Sprecher sein. Einer, der nur einmal in einer Generation vorkommt. Dieser Mensch wird interviewt, auf ihn hört man.
So oder so ähnlich dürfte die landläufige Meinung zum Thema "Wie wichtig ist Kommunikationsfähigkeit?" aussehen. Merkwürdig nur, dass die Kapitäne der besten Sportmannschaften beim Thema Kommunikation im oben genannten Sinne durchfallen. Sie halten keine Reden. Sie geben keine besonderen (oder gar keine) Interviews. Sie sind ruhig und äußern sich wenig.
Zumindest öffentlich. Denn im Team sieht es anders aus. Hier sind sie gut vernetzt, sprechen viel mit allen Teammitgliedern. Manchmal mit Worten, manchmal mit Körpersprache. Eloquenz und elaborierte Ausführungen sind da nicht zu finden. Dafür Klartext. Fachliche Botschaften. Auf den Punkt. Verständlich. Kein Schnickschnack.
Das, was Sam Walker über Captains von Sportmannschaften herausgefunden und in seinem Buch "The Captain Class" beschrieben hat, können Menschen in der Softwareentwicklung allemal.
Wer im Softwareteam mit Leidenschaft ĂĽber Software spricht, ĂĽber Architektur, Patterns, Refactoring, Tools und Methoden setzt Akzente, bestimmt die Themen und die Richtung.
Die Richtung bestimmen? Das ist ein anderes Wort fĂĽr FĂĽhrung.
FĂĽhrung, die jeder und jede im Team ĂĽbernehmen kann. FĂĽhrung, von der ein Team nicht zu viel haben kann. FĂĽhrung, die niemanden in seiner/ihrer Position angreift. FĂĽhrung in der Sache, nicht in der Hierarchie.
Walker schreibt dazu: "Eine der großen wissenschaftlichen Entdeckungen über effektive Teams ist, dass ihre Mitglieder miteinander reden. Sie tun dies auf demokratische Weise, indem sie sich abwechseln. Die Leader dieser Art von Teams knüpfen viele Kontakte und sprechen mit Begeisterung und Energie mit allen. Auch die [besten] Teams haben eine solche Gesprächskultur – und die Person, die diese Kultur fördert und aufrechterhält, ist der Kapitän. Trotz ihrer mangelnden Begeisterung für öffentliche Gespräche unterhalten sich die meisten dieser Kapitäne innerhalb der privaten Grenzen ihrer Teams ständig und verstärken ihre Botschaften durch Gesten, Blicke, Berührungen und andere Formen der Körpersprache. Das Geheimnis effektiver Teamkommunikation ist nicht Grandiosität. Es ist ein Strom von Gesprächen, der praktisch [...] und beständig ist."
Was fange ich als Mitglied eines Softwareteams damit an?
Wem die Richtung seines Teams nicht gefällt, wem die Produktausrichtung nicht gefällt, wem die Managemententscheidungen nicht gefallen, wer in einer Feature Factory steckt und raus möchte, sollte die Führung in der Kommunikation übernehmen! Ob eine Sportmannschaft ihr Ziel erreicht, zeigt sich zwischen Anpfiff und Abpfiff. In dieser Zeit gibt es keine Stakeholder, keine User, keine Manager, also auch keine Kommunikation mit diesen Personen. Sogar der Trainer steht am Rand und damit auch diese Kommunikation.
Bei Teams, die Software entwickeln, ist das anders. Es gibt keinen Anpfiff und keinen Abpfiff. Hier darf es nicht bei Gesprächen im Entwicklerteam bleiben. Der direkte Austausch mit allen(!) Stakeholdern ist wichtig und man sollte den Product Owner damit nicht allein lassen. Sonst findet sich das Entwicklerteam im sprichwörtlichen Silo und ohne Einfluss auf die Richtung wieder. Wenn es um die hier gemeinte Kommunikation geht, gehört zum "Team" jeder Mensch, der Einfluss auf die Ausgestaltung des zu entwickelnden Produkts hat. Und jeder von diesen Menschen ist "Entwickler".
Um als Softwareentwickler mit denen sprechen zu können, die formal nicht zum Team gehören, reicht es nicht aus, über Architektur und technische Schulden reden zu können. Ein ganzheitliches Verständnis des Produkts und dessen geschäftliche Auswirkungen sind notwendig, damit die Kommunikation über Silogrenzen hinweg gelingt. Wer aus einer Position ohne formale Macht heraus (sein Team aus der Feature Factory) führen möchte, ist gut beraten, den Austausch mit allen Beteiligten in die eigene Hand zu nehmen. Dafür ist es wichtiger, überhaupt zu kommunizieren als lange über fein geschliffene Aussagen nachzudenken. So wie die (manchmal unsichtbaren) Kapitäne der besten Sportmannschaften.
In eigener Sache:
- Was wünscht sich ein Product Owner von Entwicklern, um nicht in der Feature Factory zu landen? Darüber habe ich mit Kathleen Janz, langjährige Product Owner, gesprochen. Einen Mitschnitt gibt es in der Podcast-Folge "Product Owner in der Feature Factory - Täter oder Opfer?"
- Heise-Leser, die ihre Führungsskills ausbauen möchten, bekommen mit dem Promocode "2024heise10" bei der Buchung des Workshops Leading self-organized Software-Teams einen Nachlass von 10 Prozent. Der Code ist für Buchungen innerhalb von zwei Wochen ab dem Erscheinen des Artikels gültig.
(rme)