Ich bin Pragmatiker. Anwendung über Theorie. Ausprobieren über Studieren. Entscheidung statt langes Reden. Experimentieren gehört für mich zum Alltag dazu, bezogen auf unsere Nutzer, wie auch mit dem Team.

Das digitale Produktmanagement ist ein schnelllebiges Geschäft. Wir sind fortwährend mit neuen Anforderungen konfrontiert. Die Systeme, die wir bauen, sind veraltet, sobald wir sie veröffentlichen.

Auch unser eigener Organismus, die Teams und das Unternehmen, entwickeln sich ständig weiter. Aber arbeiten wir an uns in der gleichen Weise, wie wir an unseren Produkten arbeiten?

Das Framework

Gerade lese ich es wieder überall. Was ist Agile? Was ist der Unterschied zwischen Lean Startup, Design Thinking und Agile? Die Rede ist von Frameworks, von denen wir uns DIE Lösung erhoffen.

Unsere Diskussionen sind teilweise sonderbar detailverliebt. Wie sollen wir das geschriebene Wort auslegen, fragen wir uns.

Was mich fasziniert, wir reden mehr über die Frameworks selbst, anstatt über die angestrebte Veränderung. Klassische Frage von Outcome vs. Output.

Das Oxford English Dictionary definiert ein Framework wie folgt:

Eine Grundstruktur, die einem System, Konzept oder Text zugrunde liegt.

Eine Grundstruktur, ein Modell, ein Ordnungsrahmen. Wir reden hier also nicht von einem Gesetzestext, sondern eher von einem Impulsgeber. Ein Framework dient dazu, Ideen zu geben und Muster aufzuzeigen.

In einem wundervollen Artikel hat Jeff Patton unter anderem über die Probleme des Agile Manifestos geschrieben. Dort heisst es:

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Zwölf Prinzipien Agiler Softwareentwicklung

Patton führt dazu aus:

Sie können in jedem Sprint das liefern, was Sie versprochen haben, und es ist möglicherweise egal, wenn die Arbeit nicht zu den Ergebnissen führt, die Ihr Unternehmen vorhergesagt hat. Agiles Vorgehen nach Vorschrift kann dazu führen, dass Sie ein großartiger Dienstleister sind, aber kein erfolgreicher Produktentwickler.

The Mindset That Kills Product Thinking

Und genau hier liegt unser menschliches Problem. Natürlich ist es einfacher ein Framework einfach zu nehmen und für unser eigenes Schaffen zu kopieren. Wir müssen uns jedoch mit dem Gedanken beschäftigen, ob wir wirklich damit unsere Ziele erreichen.

Die Adaption

In meinem Artikel über das Formen eines Teams habe ich ausgeführt, dass jeder Mensch mit seiner eigenen Geschichte und seinen Erfahrungen kommt, positiven wie auch negativen. Dementsprechend entstehen die vielfältigsten Organismen.

Vor ein paar Jahren habe ich ein Team als Produktmanager übernommen, in dem zwei verschiedene Release-Prozesse alternierend gelebt wurden. Für das Team funktionierte das gut. In dem Moment, in dem ich Teil des Teams wurde, entstanden jedoch neue Dynamiken. Meine Erwartungen und Erfahrungen treffen auf einen Organismus, der für sich funktioniert.

Vermeintlich wäre es einfach, nun ein Framework oder eine gewisse Arbeitsweise auf das Team zu übertragen. Das wird jedoch aus mehreren Gründen nicht gelingen.

Erstens löst eine Änderung von Prozessen bei den Betroffenen etwas aus. Oft sind das eher negative Dinge, wie Bedenken vor dem Ungewissen. Veränderung ist schwer und daher muss man hier behutsam vorgehen.

Zweitens ist jeder Organismus anders. Jedes Team hat unterschiedliche Bedürfnisse. Zum Beispiel hat ein reines Android App Team andere Arbeitsweisen als ein Web-Team. Bei einem funktionsübergreifendem Aufbau kommen auch entwicklungsferne Funktionen wie Marketing oder Analysten dazu.

Wir können also keine Blaupause von Team A auf Team B übertragen. Lasst uns adaptieren, die Grundstruktur nehmen und versuchen Elemente zu nutzen, die unseren Organismus verbessern.

Das Experiment

Bevor wir ein neues Produkt oder eine Funktion für unsere Kunden veröffentlichen, testen wir. Wir sprechen mit unseren Nutzern, probieren Dinge aus und verändern das Produkt immer wieder. Wir würden nicht auf die Idee kommen einen Wettbewerber ganz stumpf zu kopieren. Vielmehr nutzen wir die Impulse und Marktstandards und adaptieren sie für die Bedürfnisse unserer Kunden.

In dem vorhin erwähnten Team haben wir die Release-Prozesse innerhalb eines Experiments angeglichen. Die Bedenken waren vielfältig und dennoch konnten wir gemeinsam eine Veränderung einführen, die sich nicht nur auf das Team positiv ausgewirkt hatte.

Bisher waren die Rituale beider Plattformen, Android und iOS, getrennt. Es wurde entweder Android oder iOS getestet und in dem jeweiligen App Store veröffentlicht. Für mich als alleinigen Produkt Manager hätte das eine enorme Doppelbelastung bedeutet, da ich jede Woche für eine Plattform mit den verschiedenen Prozessen beschäftigt wäre.

Um das zu ändern, haben wir die alternierenden Prozesse abgeschafft und zusammengelegt. Statt jede Woche zu testen, testen wir nur noch alle zwei Wochen, aber dafür zusammen. Statt jede Woche eine App zu veröffentlichen, senden wir beide Apps alle zwei Wochen in die Stores. Was vorher als problematisch galt, war am Ende positiv auf verschiedenen Ebenen.

Änderungen, die wir im Team in Bezug auf unsere Prozesse angehen, sehe ich immer als eine Phase an. Wir probieren aus und entscheiden nach einer gewissen Zeit, ob wir mit den Veränderungen gut leben können. Teilweise iterieren wir und verbessern uns sogar noch mehr. Manchmal lassen wir es einfach sein.

Das Ziel

Wir müssen uns fragen, welches Ziel wir verfolgen. Es ist das Eine mit dem Label “Agile” zu werben. Wir müssen es auch leben. Für mich bedeutet das nicht einfach blind einem Framework zu folgen und wirklich auf die Bedürfnisse im Team zu reagieren.

Es spielt im Grunde keine Rolle, ob ein Team seine Arbeitsprozesse nach Scrum, Kanban oder einem anderen Framework ausrichtet. Das entscheidende ist: Das Team muss für das Unternehmen und seine Nutzer wertvolle Arbeit erbringen und sollte dabei auch Spass haben.

Outcome über Output. Macht euch frei von den Zwängen der Frameworks. Sprecht miteinander und entscheidet gemeinsam, welche Rituale ihr für ein erfolgreiches Arbeiten benötigt. Überprüft eure Arbeitsweisen regelmäßig aber ohne Zwang. Probiert Dinge aus, d. h. experimentiert für vier Wochen und schaut, ob die Änderung euch vorwärtsgebracht hat.

Zum Ende verweise ich auf den Duden:

Agil, von großer Beweglichkeit zeugend; regsam und wendig.

Duden

Literaturtipp

Klickt, kauft und macht uns reich – der Literaturtipp zum Thema agile Frameworks am Beispiel von Spotify:

Image 1: Photo by Jack B on Unsplash

Image 2: Photo by Anne Nygård on Unsplash