Stakeholder*innen, macht mit!

Frank

21. Juni 2021

Wie Stakeholder*innen eine positive Dynamik in die Softwareentwicklung bringen können

Es gibt viele unterschiedliche Arten von Stakeholder*innen. Eines haben die meisten aus unserer Sicht doch gemeinsam: Sie gehen davon aus, dass sie keine wichtige aktive Rolle im Rahmen von agiler Softwareentwicklung spielen. Ist das wirklich so?

Ganz wichtig: Stakeholder*innen müssen Orientierung geben

Die zunächst wichtigste Aufgabe von Stakeholder*innen heißt: Orientierung geben. Hierzu gehört die konkrete Vorgabe von Unternehmenszielen, Produktvision und ein Verständnis davon, wie durch das Lösen von Benutzer*innenproblemen diese Vorgaben erreicht werden können. Das klingt zunächst lapidar, ist aber genauso elementar wichtig. Denn: Gelingt dies, kann das Entwicklungsteam eigenverantwortlich loslegen. Und genau das soll es im Rahmen von agiler Softwareentwicklung ja auch tun: eigenverantwortlich arbeiten. Den Deal zwischen Team und Stakeholder*in könnte man also wie folgt beschreiben: Für den Geschäftswert ist der/die Stakeholder*in verantwortlich und das Team dafür, dass die Software auf diesen Wert einzahlt.

Wichtig auch: ein kritischer Blick auf die Entwicklungsarbeit

Ein kritischer Blick heißt aus meiner Sicht, dass gerade auch Stakeholder*innen fördern können, dass sich möglichst viele der im folgenden aufgelisteten Vorteile der agilen Softwareentwicklung in der eigenverantwortlichen Arbeit des Teams widerspiegeln:

Das Team zeigt mindestens einmal im Monat, was es fertiggestellt hat. Es sollte auch erklären können, wie und warum die Ergebnisse auf den Geschäftswert einzahlen.
Der/die Stakeholder*in kann beurteilen, ob die richtigen Dinge entwickelt wurden oder ob Fortschritt erreicht wird.
Das Team konzentriert sich auf die Aufgaben, die am meisten Wert schaffen.
Das Team kann jederzeit den letzten Stand der Entwicklungsarbeit ausliefern, wenn es gewünscht ist.
Das Team liefert realistische Release-Prognosen, um zeitabhängige Aspekte besser planen zu können.
Die Fehlerrate der Software ist niedrig, damit das Team mehr Zeit hat, um Fortschritt zu erreichen.

Diese Aspekte können beurteilt werden, ohne dass man selbst eine Ahnung hat, wie Software entwickelt wird. Sie sind aber ein guter Indikator dafür, ob das Team seine Sache beherrscht und die Rahmenbedingung für das Team angemessen sind. Sollten sich oben genannte Punkte im Review nur selten widerspiegeln und das Team hat keine konstruktiven Vorschläge, um die Situation zu verbessern, dann könnte die Agile Fluency Diagnostic Licht ins Dunkel bringen. So eine Diagnostik kann bei uns übrigens als Workshop gebucht werden. In einem späteren Blog-Artikel werden wir auch inhaltlich darauf eingehen.

Und: Kritischer Austausch für hohe Motivation aller

Ein Review eignet sich hervorragend dafür, um mit dem Entwicklungsteam in einen kritischen Austausch zu gehen. Und um in diesem Rahmen die oben genannten Punkte gemeinsam zu reflektieren. Stakeholder*innen zeigen ihr Interesse an der Arbeit des Teams, indem sie diese Punkte regelmäßig aktiv ansprechen. Diese konstruktiv-kritische Sicht kann für ein Team sehr motivierend sein. Jedes Teammitglied erfährt so, dass seine Arbeit in einem größeren Zusammenhang wichtig ist und sich somit sinnvoll anfühlt.

Wie weiter oben schon angemerkt, begegnen wir häufig Stakeholder*innen, die für den Projekterfolg verantwortlich sind und gleichzeitig ihre ersten Gehversuche auf agilem Terrain machen. Damit diese ihre Verantwortung von Anfang an wahrnehmen können, nimmt bei den Reviews bei unseren Teams noch eine Kollegin oder ein Kollege teil, der/die das Team aus Sicht der/des Stakeholder*in challenged und auf die oben genannten Punkte achtet. Er oder sie bespricht im Rahmen eines Coaching im Nachhinein mit den Stakeholder*innen alle Aspekte des Reviews. Mit der Zeit wird immer weniger Unterstützung nötig und die Teilnahme der/des Kolleg*in an den Reviews wird überflüssig.