Agiles Powerplay

Martin Lederer - metaMind
Solutions Architect
Mehr erfahren
Expertenbeitrag

Machtgefälle gibt es nicht nur in klassischen Organisationen, sondern auch in flachen Hierarchien und agilen Teams. Die Dynamik unter der Oberfläche wirkt sich auf die Kommunikation etwa in Scrum-Teams aus – und den Erfolg ihrer Projekte.

Machtgefälle haben auch heute noch Auswirkungen im Arbeitsalltag – und auch auf Scrum-Teams (Quelle: Adobe Stock / Robert Kneschke).

Innerhalb von Organisationen sind Machtgefälle durch den kulturellen Wandel seit den 1990ern praktisch unsichtbar geworden. Dennoch haben sie auch heute noch Auswirkungen im Arbeitsalltag, auch auf Scrum-Teams. Diese sind in deutschen Konzern, die sich nicht primär mit der Erstellung von Software beschäftigen, zumeist sehr heterogen. Der Product Owner kommt oft aus dem Unternehmen selbst und ist fachlich, mit oder ohne Personalverantwortung, dem unteren Management zuzuordnen. Der Auftraggeber ist, als jemand, der ein paar hundert Personentage Budget auftreiben kann, in der Regel über dem Product Owner angesiedelt.

Der große Rest sind Entwickler aller Couleur (also auch Designer, UXler, Analysten etc.) sowie der Scrum-Master. Dieses Potpourri ist nun selten komplett extern eingekauft, sondern es finden sich eventuell noch ein oder zwei interne Mitarbeiter, ein paar externe Kräfte sowie selbstständige Unterauftragnehmer und Mitarbeiter von Tochtergesellschaften. Diese haben nicht nur unterschiedliche Interessen, sondern auch ein unterschiedliches Standing zum Projekt und zueinander, was den zentralen Punkt eines agilen Projektes beeinflusst: Die Kommunikation innerhalb des Teams und nach außen.

Man muss gar nicht an die großen machiavellistischen Manöver denken, um sich vorzustellen, dass viele Hügel in dieser Projektlandschaft liegen, welche einer offenen und gradlinigen Kommunikation im Wege stehen. Die beliebte Retrospektive, ein Kernelement des Scrum-Prozesses, kann zur zeitverschwendenden Abnickveranstaltung werden, je nachdem, wie die Macht im Team gelagert ist – und wie spürbar sie unter dem Gewebe der Unternehmenskultur ist. Die Kommunikation wird erschwert, gestört oder sogar soweit beeinträchtigt, dass sie den Projekterfolg gefährdet, etwa wenn Informationen nicht fließen können. Die Linien, entlang derer sich das Machtgefälle ausrichtet, sind Betriebszugehörigkeit, Spezialwissen, Hierarchie – neben wenig Greifbarem wie etwa der Reputation.

Ein Projekterfolg kann aufgrund der Machtgefälle und einer erschwerten oder gar beeinträchtigten Kommunikation gefährdet werden (Quelle: iStock / AlonzoDesign).

Patterns of Force als Hürden

Um nicht zu theoretisch zu werden, ein paar reale Beispiele aus dem Beratungsalltag:

  • Der Scrum-Master ist ein externer Mitarbeiter von einer kleinen Consulting-Agentur als neuer Dienstleister im Unternehmen. Der Auftraggeber verlangt vom Scrum-Master, dessen Rolle er zu verkennen scheint, dass das „Projekt läuft“.
  • Ein anderer Scrum-Master verhindert nicht, dass der Kunde ins Projekt „reinregiert“. Als sich der externe Senior-Entwickler dagegen wehrt, wird er aus dem Projekt entfernt.
  • Die zwei Product Owner sind Interne. Sie machen dem Projektteam klar, dass Scrum schon gut wäre, aber man zur Deadline X den Funktionsumfang Y liefern müsse – so sei das eben.
  • Product Owner und Team kommen von einer großen Agentur. Unerfahrene Mitarbeiter werden ins Team gestafft, zum gleichen Tagessatz wie die Seniors. Die Qualität ist niedrig, aber die Entwickler spüren, dass sie zunächst der eignen Agentur verpflichtet sein sollen. Die fachlichen Stakeholder des Kunden bekommen ein geschöntes Bild.
  • Eine Scrum-Masterin nimmt ihre Rolle sehr ernst. Das Team meldet in der Retro lediglich, dass alles zum Besten stehe, um ihren zeitraubenden und anstrengenden Interventionen zu entgehen.
  • Eine Entwicklerin kopiert wiederholt Code, ein anderer Entwickler hat „keine Zeit“ für richtige Dokumentation. Das Team adressiert die Probleme nicht, da der Auftraggeber klar gemacht hat, dass nur bei ausreichender Funktionalität die nächste Budget-Tranche freigegeben würde. Das Team wiederrum muss den Code nicht betreiben, sondern ihn nur irgendwie abgenommen bekommen.

Gerade das letzte Beispiel soll verdeutlichen, dass Machtauswirkung und Kommunikationsflüsse ein komplexes Geflecht bilden können, bei dem es keine eindeutigen Sieger und Verlierer gibt.

Das Projekt würde wohl ein bisschen anders funktionieren, wenn es Scrum-ideal aufgesetzt wäre: Es auf n Personentage terminiert (als Time-/Ressource-Box), und alle Mitarbeiter sind Interne. In diesen n Personentagen schaffen sie, in Absprache mit den internen Kunden und internen Nutzern, was möglich und sinnvoll ist.

Nicht-funktionierende Kommunikation ist schwer zu erkennen

Die Scrum/Agile-Literatur geht mit dem Thema insgesamt recht optimistisch um. Eine Empfehlung ist, das Team und die Stakeholder auf die Scrum-Prinzipien zu verpflichten, welche die Relevanz der Kommunikation unterstreichen. Nur: Wenig behindert die notwendige Kommunikation (in ihrer Qualität) wie ein Machtgefälle. Scrum erkennt zwar die realen Kommunikationsströme als unverzichtbare Voraussetzung für den Projekterfolg, bietet aber leider wenig Hilfe dabei, wie man Indikatoren für eine Schieflage einrichtet und diese ausgleicht. Diese kommunikative Problemlösung hängt in einem Henne-Ei-Zyklus fest: Um eine offene und direkte Kommunikation zu bekommen, braucht man offenen und direkten Informationsaustausch.

Um eine offene und direkte Kommunikation zu bekommen, braucht man offenen und direkten Informationsaustausch (Quelle: iStock / AndreyPopov).

Dabei sind die negativen Einflüsse von Macht auf Kommunikation durchaus lösbar, auch in den oben genannten Beispielen. Das könnte aber nur etwa durch eine stetige Sensibilisierung für das Thema geschehen, um sich des Problems zu vergegenwärtigen und es auf die Oberfläche zu heben: Kommunikation in einem Umfeld, in dem Machtgefälle vorhanden sind, muss mit großem Fingerspitzengefühl geprüft und betrieben werden. Mit einem Ausgleich der Machtgewichte läuft die Kommunikation plötzlich besser, und Fehler im Scrum-Setup können diskutiert und bearbeitet werden. Ein weiterer Punkt auf der Pre-Flight-Checkliste der Scrum-Master, neben „Definition of Done“ und dem „Scrum-Ziel“, wäre ein guter Anfang.

In einer kleinen Serie wollen wir ein paar Untiefen von agilen Vorgehensmodellen in der Praxis ausloten – dabei geht es nicht darum, rundum „bessere“ Alternativen zu erarbeiten, sondern eher Schwächen zu verstehen, um besser mit ihnen arbeiten zu können.

Im nächsten Beitrag bleiben wir beim Thema Kommunikation, aber innerhalb des Scrum-Teams und bei den Perspektiven der einzelnen Mitglieder.

Quelle Titelbild: iStock / relif

Martin Lederer - metaMind
Solutions Architect
Mehr erfahren

Weitere Beiträge

Future Workplace

Vom Personal-Verwalter zum Potenzial-Entfalter

Weiterlesen
Future Workplace

Digital Adoption: Warum es auf die letzte Meile ankommt

Weiterlesen
Agile Enterprise

Stunde der Entscheidung: Kreuzungen in Projekten

Weiterlesen

Kommentieren

Diesen Beitrag teilen

Alle Beiträge von
Agile Enterprise