28. Februar 2023
Darf der Stakeholder das?
SMART DEVELOPMENT NEWS 2023
Agilität findet in vielen Formen Einzug in die Entwicklung mechatronischer Produkte. Im besten Fall kann der Scrum Guide nahezu vollständig umgesetzt werden. Oft gibt es aber organisatorische oder strukturelle Rahmenbedingungen, die in der Praxis besondere Lösungen erfordern. Damit sind solche Teams nicht minder agil – ganz im Gegenteil, soweit die Sonderlösungen gut auf die spezifischen Herausforderungen zugeschnitten sind, bieten sie meist eine bessere Basis für die Entwicklung des agilen Mindsets, da sich die Teams nicht mit „unlösbaren“ Problemen des Lehrbuch-Scrums herumschlagen müssen. Eine Herausforderung bleibt aber in jeder Art von Umsetzung bestehen – das Zusammenspiel zwischen agilen Teams und den (Manager-)Stakeholdern. Dabei wird Neuland betreten, das Unsicherheit und Spannungen verursacht. Und nicht selten stellt sich die Frage:
"Darf der Stakeholder das?"
Der Review als einzige Interaktion zwischen agilem Team und Stakeholdern?
Der Scrum Guide beschreibt fünf Events bzw. Meetings. Es gibt die Sprint-Planung, das Daily, das Backlog Refinement, das Review und die Retrospektive. Einzig im Review sind als Teilnehmer die Stakeholder explizit erwähnt. Das bedeutet, dass in einem zweiwöchigen Sprint – der am häufigsten eingesetzten Sprintdauer im Umfeld mechatronischer Projekte – die Stakeholder nur für die Dauer von 1,5 Stunden innerhalb von 14 Tagen mit dem Teammitgliedern interagieren.
Für manchen Top-Manager mag das durchaus eine angemessene, oft sogar deutlich häufigere Kontaktfläche sein. Aber für Gruppenleiter bzw. Teamleiter, die mit ihren Teammitgliedern vor dem agilen (Pilot-)Projekt nahezu täglich zusammengearbeitet haben, ist das ein radikaler Schnitt. Und das zumal mit dem agilen Projekt auch häufig eine geänderte Sitzordnung einhergeht – agile Teams sollen co-located sein, also im selben Bereich sitzen. Damit wird das agile Team die neue Heimat des Mitarbeiters, während das organisatorische Team an Bedeutung verliert und es somit weniger Möglichkeiten für den Plausch an der Kaffeemaschine gibt.
Der Stakeholder als Störfaktor
Darüber hinaus wird in vielen Erfahrungsberichten aus agilen Projekten das „Eingreifen“ von Stakeholdern außerhalb des Reviews als Störfaktor beschrieben – der Ausdruck „Reingrätschen“ wird dabei öfter verwendet. Diese Art von Störungen wird dann als eine der Gründe genannt, warum man unbedingt einen Scrum Master braucht, der die Teams vor diesen Interventionen schützt.
Insoweit ist es verständlich, dass die Stakeholder insbesondere aus dem Bereich der Gruppen- und Teamleiter nicht nur verunsichert sind. Ein bisschen kann man das Gefühl mit „From Hero to Zero powered by Agile“ beschreiben, das sich in diesen Kreisen entwickelt. Ist das der Sinn von agilem Arbeiten?
Sicherlich nicht, denn eines darf man dabei nicht vergessen. Die allermeisten Stakeholder sind wertvolle Erfahrungsträger, die nicht umsonst mit Führungsaufgaben betraut worden sind. Sie verfügen über langjähriges Wissen, das viele der Mitarbeiter nicht haben. Dieses Potenzial nicht in adäquater Form abzurufen, wäre fatal für das Unternehmen. Und es ist auch klar, dass anderthalb Stunden in zwei Wochen nicht ausreichen, um dieses Potenzial ausreichend einzubringen.
Die Selbstorganisation der Teams muss im Vordergrund stehen
Allerdings ist auch klar, dass sich mit der Einführung von agilem Arbeiten etwas verändern muss. Der Wissens- und Erfahrungstransfer zwischen Führungskraft und Mitarbeiter erfolgt nicht mehr in der engen Beziehung wie vormals. Insbesondere auch als – gegebenenfalls deutlich spürbare – Kombination aus fachlicher und disziplinarischer, also weisungsgebender Führung. Agilität zielt insbesondere darauf, diese Verbindung zu durchbrechen.
Fachliche Führung sollte sich zu einem Coaching bzw. einer Beratung entwickeln. Während disziplinarische Führung eher Administration (Urlaub, Vertragswesen etc.) und persönliche Entwicklung (Aus- und Weiterbildung) bedeutet.
Aber was ist der Sinn dieser Vorgehensweise? Warum ist diese geänderte Herangehensweise am Ende erfolgreicher für das Unternehmen? Es gibt zwei Aspekte, die dafür den Ausschlag geben.
Bessere Entscheidungen im Team treffen
Die meisten Entwicklungsvorhaben von mechatronischen Produkten sind in der Stacey-Matrix im komplexen Bereich. Dabei besteht ein hohes Maß an Unsicherheit, was entwickelt werden soll, also welche Ausstattung an Produktmerkmalen das Produkt haben soll. Damit einhergehend, aber auch häufig losgelöst davon, gibt es Unsicherheit, wie das Produkt entwickelt werden soll. Letztlich geht es dabei nicht nur um die Frage der technischen Spezifikation. Ein immer wichtiger werdender Faktor ist das Verhalten von Markt und Kunden. Welches Kaufverhalten zeigt der Kunde, welche Merkmale werden die Wettbewerbsprodukte, über die zum Zeitpunkt der Entwicklung noch keine Informationen vorliegen, haben?
Diese Fragestellungen bringen selbst in Vorhaben, die seit Jahrzehnten in ähnlicher Form durchgeführt wurden, eine hohe Komplexität (Beispiel: Automobilindustrie). Die Zeiten, wo Produktmanager durch Lastenhefte das Produkt genau spezifizieren und dann die Entwicklungsteams mehrere Jahre Zeit haben, genau dieses Produkt in guter Qualität zu entwickeln sind vorbei. Viel zu schnell ändern sich Markt und Kunden, aber auch Technologien.
In diesem Umfeld gilt es, die besten Entscheidungen zu treffen – das Produkt muss auf den Punkt genau passen. Nicht zu wenig, aber schon allein aus Kostengründen auch nicht zu viel. Die agile Prämisse ist, dass solche Entscheidungen am besten im Team getroffen werden. Es gibt die Rolle des Product Owners, der die Verantwortung dafür hat. Da aber bei mechatronischen Produkten sehr häufig die Technik bzw. Technologie die Grundlage für die Entscheidung zu Ausprägungen von Produktmerkmalen sind, können die Entscheidungen nur im Team getroffen werden. Die Erfahrung zeigt, dass solche Entscheidungen im Team in den meisten Fällen besser sind als die Entscheidung eines einzelnen Managers. Selbst wenn man unterstellt, dass dieser Manager sich mit Kollegen und/oder Mitarbeitern zu seinen Entscheidungen im Team berät, kann der Zeitaufwand für den Austausch und die Abwägung von Alternativen bei weitem nicht dem entsprechen, was ein (agiles) Team schafft.
Komplexe Entscheidungen brauchen einen konstruktiven Diskurs und viele Perspektiven. Solche Prozesse verkürzen zu wollen, bedeutet das hohe Risiko, zwar schnell eine Entscheidung zu haben, aber die falsche. Daher kann und sollte man in diesen Fällen ruhigen Gewissens auf die „Schwarm-Intelligenz“ des Teams setzen.
Gute Mitarbeiter ein Umfeld für motiviertes Arbeiten bieten
Aber es gibt noch einen zweiten Aspekt, der zunehmend an Bedeutung gewinnt. Wie rekrutiert ein Unternehmen gute Mitarbeiterinnen und Mitarbeiter und wie bietet es Ihnen ein Umfeld, in dem sie motiviert und engagiert arbeiten können? Um es kurz machen, es gibt drei Faktoren, die dabei eine wichtige Rolle spielen: Autonomy (Selbstorganisation), Mastery (Fachliche Exzellenz) und Purpose (den Sinn des Handelns verstehen).
Diese Faktoren sind zunächst völlig unabhängig davon, ob agil gearbeitet wird oder nicht. Und zweifelsohne lassen sie sich auch im klassischen Arbeitsumfeld zumindest teilweise gut umsetzen. Aber interessanterweise fördert agiles Arbeiten genau diese drei Faktoren, und zwar besonders an der Stelle, um die sich der Kern dieses Beitrags dreht. Denn beim agilen Arbeiten wird die Zusammenarbeit zwischen dem agilen Team und den Führungskräften auf eine neue Ebene gebracht. Das klassische Führen durch Expertise und ggfs. auch Weisung verliert deutlich an Bedeutung. Dagegen werden Coaching und Beratung wichtiger. Während vormals die Kommunikation oft im Push-Prinzip erfolgte, geschieht sie im agilen Umfeld mehr im Pull. Die Teammitglieder suchen sich die fachlichen Führungskräfte – die nicht notwendigerweise die Gruppen- oder Teamleiter sein müssen – von denen sie Rat und Unterstützung benötigen. Es gilt auch als klar kommuniziertes Unternehmensprinzip, dass Rat einzuholen und Rat zu geben gewollt sind und dafür Zeit zur Verfügung steht.
Darf der Stakeholder das?
Aber was genau bedeutet das für den Stakeholder? Wie oben erwähnt, kann und soll es nicht der Zweck des agilen Arbeitens sein, die Interaktionsfläche zwischen Führungskraft und Team auf 1,5 Stunden pro Sprint zu reduzieren. Dennoch ist die Aktionsfläche dazwischen kritisches Neuland, denn nirgendwo ist beschrieben, wie sie aussehen soll bzw. gestaltet werden kann.
Die wichtigste Prämisse, die sich aus vielen agilen Projekten ergeben hat, ist, dass sie robust und authentisch sein soll. Es gibt viele Möglichkeiten, die Kommunikation zwischen Team und Führungskraft außerhalb der Reviews zu gestalten. Soweit sie sich an den drei Motivationsfaktoren Autonomy, Mastery und Purpose orientiert, kann zunächst nicht viel falsch sein. Das Pull-Prinzip für das Einholen von Beratung wurde bereits erwähnt und dass dazu Zeitanteile in den Sprints eingeplant werden sollten. Wenn es die oder der Vorgesetzte schafft, anstelle des Teamleads die Rolle des trusted Advisors einzunehmen, wird sie oder er ohnehin eine tragende Rolle einnehmen.
Vor diesem Hintergrund gibt es auf die Frage: „Darf der Stakeholder das?“ eine eindeutige Antwort – Vielleicht! Soweit ihr oder sein Ansinnen ist, die klassische Führungsrolle zu stärken, ist der Ansatz fragwürdig. Ist die Intension dagegen, die oben genannten positiven Faktoren zu stärken, dann darf der Stakeholder das. Vielleicht muss man an der einen oder anderen Stelle noch optimieren, in welcher Form das Verhalten umgesetzt wird. Aber das kann in konstruktiven Gesprächen sicherlich geklärt werden.
Wichtig ist die Kernbotschaft für agile Teams und Führungskräfte: Es gibt durchaus gewollte Interaktionsfläche zwischen ihnen außerhalb des Reviews. Es kann aber eine gute Idee sein, sich in der ersten Phase eines agilen Piloten von einem agilen Coach unterstützen zu lassen. Denn wer nur den Scrum Guide liest, wird auf diese Frage keinen Lösungsansatz finden. Daher kann es helfen, wenn gleich von Anfang an in einer moderierten Diskussion, die Kontaktfläche zwischen Team und Führungskräften geklärt wird.