Motivations-Sprit für’s Seifenkisten-Rennen

Psychologische Sicherheit löst die Bremse, die Teams davon abhält, ihr volles Potenzial zu entfalten (Edmondson). Aber der Treibstoff, der die Kiste zum Fahren bringt, ist Motivation. Das tollste Fahrzeug, mit dem besten Motor und dem schicksten Lack, wird das Rennen nicht machen, wenn es mit angezogener Handbremse oder gar ohne Benzin an den Start geht. Da hilft weder eine Peitsche – oder sonst irgendeine hippe Methode – noch eine optimierte Rennstrecke bzw. ein ausgeklügelter Prozess. Deswegen lautet das 5. Prinzip des Agilen Manifests: „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“

Product Owner können autonome Motivation von Teams unterstützen

Wie können Product Owner also dafür sorgen, dass der Wagen vernünftig betankt ist? Zunächst einmal ist es wichtig, dass sie sich überhaupt dessen bewusst sind, dass sie mitverantwortlich für den Sprit sind. Und sie sollten sich auch darüber im Klaren sein, dass es verschiedene Arten von Treibstoff gibt, von denen für agile Arbeit nur eine Art geeignet ist: Die autonome Motivation. Autonome Motivation entsteht durch die Selbstbestimmtheit, Kompetenz und Eingebundenheit, die Menschen in einer Tätigkeit erleben. Und daran können Product Owner schon ein wenig drehen. Spannenderweise gehen einige der Aspekte zur Förderung dieser Faktoren Hand in Hand mit Rahmenbedingungen für psychologische Sicherheit. Das sollten wir uns noch einmal genauer anschauen.

Methodenkoffer für Product Owner

Da mir die Themen „Kommunikation“, „Entrepreneurship“ und „Motivation“ für Product Owner so wichtig sind, gibt’s dazu drei Seminare mit hohem Praxisanteil. Anpassungen an den individuellen Firmenkontext sind auf Anfrage möglich.


Autonomie in der Entscheidung des „Wie“

Menschen haben das Bedürfnis, eigenständig zu entscheiden, wie sie sich verhalten. Das beißt sich mit detaillierten Vorgaben zu der Art und Weise, wie sie Dinge ausführen sollen. Natürlich kann man nicht einfach sagen „Lauf los!“, ohne die Richtung anzugeben. Erst recht nicht mit der Erwartung, dass diejenigen dann auch da ankommen, wo man sie erwartet. Diese fehlgeleitete Erwartungshaltung hat schon bei „Laisser Faire“ nicht funktioniert.

Product Owner werden also umso erfolgreicher sein, je besser sie es verstehen, die Produktvision in ihr Team zu übersetzen. Wenn allen klar ist, wohin die Reise gehen soll, können sie besser an einem Strang ziehen. Nicht umsonst steht im Agilen Manifest das Prinzip der Selbstorganisation. Wenn POs explizit Spielraum geben, können alle selbständig entscheiden, wie sie ihren maximalen Beitrag zum Gelingen erbringen können. Dafür hilft es z.B. auch, die Akzeptanzkriterien für Inkremente glasklar mit dem Team zu vereinbaren. Dann muss nämlich keiner mehr irgendwem über die Schulter schauen, um zu prüfen, ob denn auch alles richtiggemacht wird. Wichtigste Maxime ist hier, den Grad der Entscheidungsfreiheit und damit auch der Verantwortungsübernahme explizit zu machen. Das POEM von Tim Klein und Oliver Winter bietet hier einen hilfreichen, strukturierten „Redeanlass“. Denn zu wissen, woran man ist, bedeutet auch Autonomie.

Seitens des POs tragen situationsbezogene Demut oder besser der Anspruch, nicht allwissend zu sein (siehe psychologischen Sicherheit) wesentlich dazu bei, dass die Teammitglieder sich als erwachsene Menschen ernst genommen fühlen, dementsprechend Verantwortung übernehmen und als Folge auch den Product Owner besser im Loop halten.

Kompetenz wächst durch ihre Anwendung

Menschen wollen einen Beitrag zur Wertschöpfung leisten. Besonders im agilen Umfeld mit seinem starken Fokus auf Funktionsfähigkeit und Kundenmehrwert ist das natürlich prima! Wenn man sie denn lässt… Denn um diesen Baustein für gesunde Motivation zu ermöglichen, müssen Menschen in einem günstigen Korridor zwischen Herausforderung und „Können beweisen“ unterwegs sein.

Diesen Korridor können POs mitgestalten, indem sie ihr Team befähigen, seine Expertise wirkungsvoll einzusetzen. Zum einen durch die gemeinsame Entwicklung der Backlog-Elemente. Dann muss das Team nicht so viel Energie investieren, um herumzuraten, was denn z.B. die Intention einer User Story sein könnte. Die Teammitglieder können sich auf die wertschöpfenden Tätigkeiten konzentrieren, in denen sie kompetent sind. Außerdem ist dies eine gute Gelegenheit, das Können der Teammitglieder zu würdigen und weiterhin „einzuwünschen“.

Und zum anderen können Product Owner durch die Priorisierung der Tasks dem Bedürfnis nach Entwicklung Raum geben. Natürlich sollte die Reihenfolge der Items zuallererst durch den Kundenbedarf bestimmt werden. Aber wenn z.B. Teammitglieder eine Möglichkeit sehen, sich in einem Thema weiterzubilden (mit konkretem Bezug zu einer User Story oder allgemeiner), um das Gelernte dann baldmöglichst anzuwenden, kann eine Product Ownerin diesen Spielraum gewähren. Exzellenz kann es schließlich nur geben, wenn man den Horizont auch erweitern kann.

Wenn Product Owner ihre Teams in die Gestaltung von Lern-Experimenten mit einbeziehen, wird das Kompetenz-Bedürfnis auch angesprochen. Denn selbst, wenn das Ergebnis des Experiments nicht so war, wie erhofft, sieht das Team doch einen Fortschritt auf dem Erkenntnispfad der emergenten Antworten. Sprich: Es werden alternative Wege ausgeschlossen, die man jetzt nicht mehr mit im Blick behalten muss bzw. es ergeben sich Muster, die einen voranbringen. Zudem werden Rückschläge oder langsame Fortschritte durchaus als Lernerfahrung verbucht und tragen (in Maßen) zur Erfüllung des Kompetenzwunsches bei.

Und zu guter Letzt zahlt auch der Abbau technischer Schulden auf das Kompetenz-Konto ein. So wie ein Scrum Master dafür Sorge tragen muss, dass dem Team Impediments aus dem Weg geräumt werden, die seine Arbeit behindern, trägt der PO die Verantwortung dafür, den Weg für die inhaltliche Arbeit des Teams freizuräumen.

Eingebundenheit – mittendrin und voll dabei

Dieses etwas sperrige Wort bezeichnet das Bedürfnis, Teil eines größeren Ganzen zu sein. Auf der sozialen Ebene ist hier sicherlich ein Agile Master eher gefragt, selbst wenn ein Product Owner natürlich auch eine wertschätzende Beziehung zu den Teammitgliedern pflegen sollte. Auf der inhaltlichen Ebene, die sich aus dem „Warum“ speist, ist der PO klar am Zug. Product Owner müssen ihrem Team Gelegenheit geben, den wahren Wert in ihrer Tätigkeit zu sehen. Die Produktvision ist hier der wichtigste Aspekt, da durch sie der Fokus von dem täglichen Kleinklein auf einen tieferen Sinn gelenkt wird. Echte Kundenbedürfnisse aus konkreten Pains geben dem Team einen besseren Pack-an. Und wenn diese Kundenbedürfnisse erfüllt werden können, ist dies viel befriedigender, als nur das Abhaken einer Aufgabe auf einer To-Do-Liste.

An dieser Stelle wird auch wieder klar, wie wichtig es für ein Team ist, in den vollständigen Wertschöpfungsprozess eingebunden zu werden. Zum Beispiel fühlt sich ein Team erst vollständig eingebunden, wenn eine User Story nicht nur technisch abgenommen ist, sondern auch die Rückmeldung vom Kunden erfolgt. Nebenbei trägt dies auch zum Gefühl der Kompetenz bei, da erst das abschließende Feedback eine Lernkurve ermöglicht. Und wenn sich, wie zu erwarten, Anforderungsänderungen ergeben, dann sind diese viel leichter zu „verdauen“, wenn man den Sinn für das gesamte Produkt verinnerlicht hat.

Eine Product Ownerin tut also gut daran, dem Team zu vermitteln, dass sie gemeinsam mit ihm im Boot sitzt. In einem komplexen Umfeld, in welchem es ja nicht möglich ist, Antworten vorab zu kennen, entscheidet die Kollaborationsfähigkeit des gesamten Teams über den Erfolg des Produktes. Ist also die Kommunikation zwischen POs und ihren Teams gut und kennen die Teammitglieder ihren Beitrag zu einem erfolgreichen Produkt, fühlen sie sich auch viel eher dafür verantwortlich, neue Erkenntnisse und sich entwickelnde Antworten (emergente Praktiken) aufzunehmen und zu berücksichtigen.

Nachhaltiger Antrieb

Es ist unglaublich mühsam, wenn man ein Team ständig anschieben muss. Und es ist auch nicht effektiv – weder für ein erfolgreiches Produkt, noch für das Team. Und vor allem ist es wahnsinnig frustrierend für Product Owner. Also lieber einmal nach Coveys Prinzip „Sharpening the Saw“ innehalten und überlegen, wie man den Tank gut füllen kann. Und übrigens: Autonome Motivation ist echt schadstoffarm!