Know How-Transfer in agilen Teams: Einer gegen alle und alle gegen einen

Als ein Kollege und ich vor einigen Monaten gebeten wurden, Vorschläge zur Effizienzsteigerung in der Softwareentwicklung eines Kunden zu erarbeiten, erlebten wir eine überraschende Situation: Ein Startup-Unternehmen, bei dem es an nichts mangelte: Agile Methode, ein gelebter SCRUM-Prozess, State of the Art Entwicklungs-Stacks, ein motiviertes Team, tolle Büroräume und ein Kicker. Dennoch steckte die Entwicklungsabteilung voll in der Sackgasse: Das Team konnte sich nicht auf eine Strategie für das nächste Jahr einigen, Synergien verpufften und einige hatten den Eindruck, man entwickle an den Bedarfen der Stakeholder vorbei. Wie geht das zusammen?

In einem solchen Fall beginnt das typische Beratungsprojekt mit einer Analysephase. Der Kickoff mit dem Führungsteam war noch zurückhaltend einheitlich. Man mache grobe Vorgaben und die Entwicklungsabteilung organisiere sich weitgehend selbst in Sprints. Fachlich halte man sich heraus und überlasse den Teams die Wahl der besten Methoden. Die darauffolgenden Fokusinterviews mit den Beteiligten zeigten aber schon ein differenzierteres Bild: Irgendwie sei es doch komisch, dass es trotz demokratischer Entscheidungswege immer in dieselbe Richtung laufe, sei es bei der Wahl der Programmiersprache oder der Entscheidung für eine Softwarearchitektur. Die Richtung komme aber vielen wie eine Sackgasse vor.

Ich wurde neugierig, was da vor sich geht, hatte zu diesem Zeitpunkt aber noch kein genaues Bild. Normalerweise arbeite ich, wenn ein neues Projekt beginnt zunächst gerne ein paar Tage beim Kunden mit. Ein solcher Einblick über die alltäglichen Erfolge und Misserfolge am Arbeitsplatz ist für die Beratung Gold wert. Leider war das in diesem Projekt aufgrund einer kurzen Laufzeit nicht möglich. So brachten mein Kollege und ich die gesamte Entwicklungsabteilung in einem Workshop zusammen. Die zwei Tage waren intensiv und ein Lehrstück, wie in diesem Team Zusammenarbeit und Entscheidungsfindung verstanden wird.

Was die gewählte Softwarearchitektur über Teamdynamik verrät

Eine der wichtigsten Fragen, die sich dem Kunden stellte, war die Wahl einer effizienten und effektiven Softwarearchitektur. In diesem Falle gab es zwei grundsätzliche Möglichkeiten: Monolithisch oder modular. Vereinfacht gesagt geht es bei der Entscheidung darum, ob bei einer Software alle wichtigen Funktionen aus einem Guss sein müssen oder ob man weitgehend unabhängig von beispielsweise der Wahl der Programmiersprache in kleinen Einheiten individuell arbeiten kann und diese später ähnlich wie Lego zu einem größeren Ganzen zusammengefügt (aus technischer Sicht ist diese Erklärung unzureichend, wer es genauer wissen will, dem bietet Google sehr viel spezifischere Erklärungen).

Beides, der Monolith als auch das Modul, haben vor und Nachteile. Am Anfang steht aber die Erkenntnis, dass ein Computer alleine gar keine Architektur benötigt, um eine Software auszuführen. Software-Architektur wird nur benötigt, um die Struktur der (Projekt-) Teams abzubilden, die an der Software arbeiten.

Dem Computer ist in diesem Zusammenhang egal, ob eine bestimmte Funktion fest in den Code integriert ist oder modular aus einer anderen Struktur heraus geladen wird. Es sagt also mehr über die Teamorganisation aus, welcher Weg gewählt wird.

Unternehmen sind ein professionelles Verhältnis, kein Familiäres

In unserem Beispiel wurden beide Positionen heftig verteidigt. Die Besonderheit bestand darin herauszufinden, welche Argumente fachlich fundiert waren und welche aus persönlichem Interesse heraus angeführt wurden. Denn dieses Startup-Unternehmen war erfolgreich. Während die Organisation in kurzer Zeit auf über 200 Mitarbeiter anstiegt, zentrierte sich von Beginn an ein großer Teil der Softwareentwicklung um ein bis zwei Schlüsselpersonen. Für sie war die Software „ihr Baby“, das sagten sie auch so.

Ein solches Engagement ist für Unternehmen Fluch und Segen zugleich. Vor allem in der Anfangsphase profitieren Unternehmen davon, wenn die Mitarbeiter „für die Sache brennen“. Das sollte aber kein Dauerzustand sein, da ständiges Brennen eine psychologische Belastung für den Mitarbeiter auf der einen Seite ist (irgendwann kann das sog. „Burnout“ folgen). Auf der anderen Seite erschweren Wissensinseln die Zusammenarbeit im Team. Und gerade bei Programmierern ist es eine besondere Herausforderung, Wissen im Team zu teilen.

Aus solchen und anderen Gründen, versuche ich in meiner Beratung, das Persönliche soweit es geht außen vor zu lassen. Meiner Meinung nach ist es nicht klug, „Babys“ und andere Familienkonstellationen im Arbeitskontext zu pflegen. Das Baby gehört nämlich nicht dem Programmierer. Auch wenn es sein Werk ist, es gehört dem Unternehmen. Wenn es aber emotional wird (jeder will schließlich nur das Beste für sein Baby), dann besteht die Gefahr, dass unternehmerische Entscheidungen verzerrt werden.

Keine Glaubensfrage, sondern eine fundierte Entscheidung

In einer solchen Situation geraten agile Methoden schnell an ihre Grenzen. Sie sehen in bestimmten Domänen autonome Teamentscheidungen vor, was auch gut so ist. Allerdings setzt dies voraus, dass zumindest die Mehrheit des Teams alle Parameter sachlich einschätzen kann. Wenn nur ein oder zwei Personen tiefe Einblicke in die Funktionszusammenhänge haben und die Argumente nicht für alle überprüfbar sind, können sie eine Diskussion schnell mit ihrem Expertentum stilllegen.

Aus der Gruppendynamik ist bekannt, dass sich in Gruppen fast immer die Meinungsführer profilieren. Manchmal ohne, dass die Gruppenmitglieder es direkt merken. Man muss nicht immer einen expliziten Machtanspruch formulieren, um ihn zu bekommen. In Konsequenz ermöglichen es dominierende Personen anderen sich zurückzunehmen, bis hin zu sogenannten Schweigern.

Zwischen diesen beiden Prototypen zeigt sich das Verhältnis zwischen Anspruch und Verwirklichung. Und Anspruch und Verwirklichung zu verhandeln, ist die wesentliche Herausforderung in agiler Entscheidungsfindung.

Organisationsstruktur als Abwehrmechanismus

Klassischer Weise, und darin liegt eine Berechtigung von Formalisierung, bieten Organisationen Strukturen an, mit all dem umzugehen, was Menschen die zusammenarbeiten möchten, jenseits der reinen Fachlichkeit mitbringen (Isabel Menzies Lyth). Lange Zeit behaupteten sich daher auch umfangreiche formale Regeln, klare Hierarchien und autoritäre Strukturen, wie sie die ursprünglichen Hauptvertreter einer idealen Bürokratie, Max Weber (1921) oder Henri Fayol (1916), postulierten.

Das hat natürlich mit moderner Unternehmensführung wenig zutun. Agile Methoden haben sich bewährt und ersetzen auch jenseits der Softwareentwicklung immer mehr das klassische Projektgeschäft. Dadurch sind aber klassische psychologische Abwehrmechanismen nicht außer Kraft gesetzt:
Spaltung in gut und böse („die Fachbereiche haben eh keine Ahnung“), Verleugnung („dieses Tool funktioniert bei uns nicht, dazu sind unsere Anforderungen zu speziell“) oder Ironie („Ja sicher, wenn ihr aus unserem Laden ein Bürokratiemonster machen wollt.“) wären nur drei Beispiele für nicht logisch erklärbare Verhaltensweisen, die in einer agil gesteuerten Gruppe passieren können.

Das Team und die Einzelperson im Blick

Die oben beschriebenen Themen lassen sich mit dem agilen Methodenkoffer alleine nicht richtig in den Griff bekommen. In unserer Beratung haben wir daher immer mehrere Ebenen im Blick: Das Team, aber auch die Einzelpersonen.

Teammaßnahmen zielen auf Entscheidungsprozesse sowie bewusste und unbewusste Dynamiken in der Gruppe: Welche Koalitionen gibt es und welche Auswirkungen auf Zusammenarbeit haben sie. Daneben empfehlen wir das Coaching von wichtigen Stakeholdern, um schwierige und individuelle Themen besser beleuchten zu können. Die Erfahrungen aus der systemischen Beratung der Gruppe spielen in Einzelcoachings mit ein und umgekehrt werden Verbesserungen in der Gruppendynamik erreicht, indem Themen des Einzelnen in einem geschützten Raum bearbeitet werden. So könnte ein Coaching beispielsweise darauf abzielen, dass sich ein zentraler Wissensträger im Software-Team zu einem Mentor hin entwickelt. Im individuellen Coaching würden hier Themen der Wissensvermittlung der Spaß thematisiert, den es macht, Menschen mitzunehmen.

Mit Blick auf das Team kann der Coachee seine neuen Verhaltensmuster und Rollen unter Moderation ausprobieren. Ziel dieser Intervention ist es, der Einzelperson und dem gesamten Team neue Perspektiven aufzuzeigen und sie geschützt ausprobieren zu lassen.

Das Ergebnis einer solchen Betrachtungsweise ist im Idealfall eine ganze Architektur von Interventionen zur Teamdynamik, die typische agile Methoden ergänzen und befruchten. Das sind beispielsweise Sounding Boards, Reflecting Teams oder Outdoor Events, kombiniert mit regelmäßigen Coachings zum Thema Mitarbeiterführung und Wissensmanagement für Einzelpersonen.

Dadurch, dass nicht logische Themen in anderen Formen bearbeitet werden, werden schließlich auch beispielsweise die Daily Standups im Scrumsprint effektiver. Denn auf einmal ist mehr Platz für die Sache und die beste Lösung für das Unternehmen. Auf diese Weise amortisiert sich ein scheinbarer Mehraufwand für „softe Themen“ sehr schnell im fachlichen Outcome.