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.

In Pocket speichern vorlesen Druckansicht 1 Kommentar lesen
Fußball-Team im Gespräch

(Bild: Jeffrey F Lin/Unsplash)

Lesezeit: 5 Min.
Von
  • Stefan Mintert

Moin.

Escape the Feature Factory: Stefan Mintert

(Bild: 

Stefan Mintert

)

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potential sieht er im Leadership; unabhängig von einer Hierarchieebene. Die Aufgabe, dieses Potential zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind. Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können. Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

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."

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)