Meetingkultur: "Ich nehm’ das mit" darf nicht zur Regel werden

Moin.

Escape the Feature Factory: 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.

Viele kennen aus Meetings den Satz “Ich nehm’ das mit.” Mir begegnet er immer wieder mal. Er fällt mir besonders auf, wenn ein Product Owner oder Teamleiter ihn gegenüber dem Team äußert. “Ich kläre das”, ist eine Variante davon. Sollte es dabei um organisatorische oder administrative Fragen des Unternehmens gehen, um die sich der/die Vorgesetzte kümmert (z.B. Urlaubsanträge, Reisekostenabrechnung, Vertragsfragen) ist das kein Thema für mich.

Spannender wird es bei Gesprächen über neue Features, Anforderungen und Funktionen des Produkts, an dem das Team arbeitet. Wenn ich dann höre, “Ich nehm’ das mit”, ist offensichtlich eine Frage des Teams vorausgegangen, die der Product Owner oder Teamleiter nicht beantworten kann. Das kann mal vorkommen. Klar. Blöd ist nur, wenn es wirklich oft vorkommt. Denn mit jedem “Ich nehm’ das mit” geht eine Besprechung zu Ende, die nicht zum Ziel geführt hat, die es nicht geschafft hat, das Thema abschließend zu klären. Im Gegenteil. Es folgt zwangsläufig ein Follow-up. “Ist ja kein Problem. Dafür haben wir ja unsere Regelmeetings.” Wirklich? Dafür haben wir Regelmeetings? Damit Dinge nicht geklärt werden? Wohl kaum.

Was kann man als Teammitglied tun, damit es besser läuft? Im ersten Schritt: Darauf achten, ob das “Ich nehm’ das mit”-Muster eine Ausnahme ist (dann ist es ok) oder ob es oft vorkommt.

Im zweiten Schritt kann man fragen, "Wohin nimmst Du es mit?” Die Antwort dürfte lauten: “In ein anderes Meeting.” Gemeint ist immer: zu einer anderen Person. Dann stellt sich die Frage: Weshalb ist die Person nicht in der gerade laufenden Besprechung des Teams anwesend? War es unvorhersehbar, dass ihr Beitrag gebraucht werden würde? Wenn es um die Besprechung von neuen Features, Anforderungen, Tickets und Ähnlichem geht, ist meist klar, wer dabei mitreden sollte, wer die Stakeholder sind.

Im dritten Schritt sollte man für zukünftige Meetings vorher überlegen, wer für die Themen gebraucht wird, und dann stellt man sicher, dass diese Personen anwesend sein werden. Entwicklerinnen und Entwickler sollten nicht darauf warten, dass der PO von allein auf die Idee kommt. Wem Gesprächspartner fehlen und die Meetings deshalb ergebnislos enden, sollte die Initiative ergreifen. Hier ein paar Vorschläge:

• Ladet die erforderlichen Leute selbst ein. Das gibt Stress mit dem Product Owner? Dann…
• … bittet den Product Owner um die Einladung.
• Stellt eine “Definition of Ready for Refinement” oder Ähnliches auf (statt “Refinement” kann da auch “Discussion” stehen). Dazu gehört etwa: “Kein Refinement/Discussion ohne die erforderlichen Gesprächspartner”.
• Schreibt vor einem Meeting in die zu besprechenden Tickets, wer dabei sein muss. Wenn die Besprechung beginnt und die Leute fehlen, überspringt man das jeweilige Ticket und geht zum nächsten über.

(rme)