Produktmanagement und Agile – Agile Missverständnisse

Nutzen Sie Jira für die Softwareentwicklung? Finden Sie, dass agile Vorgehensweisen in der Umsetzung von Themen sehr hilfreich sind? Und versuchen Sie irgendwie alle Themen im Unternehmen nun agil und mit Jira anzugehen? Ja, dann haben wir schon drei Gemeinsamkeiten entdeckt!

Ok, noch ein Versuch: Werden Sie jede Woche gefragt: „Wo stehen wir?“ und „Wann ist das Projekt XY fertig?“ Und Nicht-Jira-Nutzer sehen „irgendwie gar nichts“, egal welche Ansicht von Jira von Ihnen vorbereitet wird? Und weil es mit Jira dann doch auch mal kompliziert werden kann, werden Trello, Office-Tools, etc. für die tägliche Arbeit nebenher genutzt? Ich spüre Ihr Nicken: Weitere drei Gemeinsamkeiten – Treffer versenkt. ?

Lesen Sie weiter um zu erfahren, wie ein Missverständnis zwischen agiler Entwicklung und geplanter und durchaus terminierter Investition entstand. Und ich erzähle Ihnen, welches Verständnis im Produktmanagement wir dafür entwickelt haben.

Der Trend seit den 2000er-Jahren ist klar hin zur agilen Umsetzung von Softwareprodukten und Atlassian hat mit der Lösung Jira eine für viele passende Lösung für die operative Umsetzung der Entwicklung geschaffen. Auch in unserem Unternehmen hat beides Einzug gehalten: Erst haben wir mit Kanban und Scrum erprobt was besser zu uns passt und sind bei Scrum geblieben. Im zweiten Schritt haben wir unsere Aufgaben für die agile Produktentwicklung mit Jira abgebildet. Jeder Schritt hat seine Zeit gebraucht, aber beides hat sich erfolgreich eingeschwungen.

The Stories of My (Produktmanager) Life

Das Produktmanagement hat viele Aufgaben und je nach Unternehmen wird Produktmanagement unterschiedlich gelebt – klar. Eines ist jedoch allen gemein: Wer das Budget gibt, der hat eine besondere Aufmerksamkeit (verdient). In Story-Form würde ich die daraus resultierenden Anforderungen beispielsweise so ausdrücken:

• Als Produktmanager möchte ich darstellen (können), mit welchem Zeiteinsatz wir die strategischen Ziele für unser Produkt/unseren Service verfolgen, um die Zielerreichung sicherzustellen.
• Als Produktmanager möchte ich jederzeit einen Überblick über den Status meiner Entwicklung und einen groben Zeitpunkt für die voraussichtliche Auslieferung eines Pakets/einer Epic/eines Projektes haben, um dies mit den Stakeholdern besprechen zu können.
• Als Produktmanager möchte ich den Plan/die Roadmap für alle verständlich und nachvollziehbar darstellen. Ich möchte alle Auswirkungen der Planung und der möglichen Änderungen dieser Planung transparent machen, so dass jeder die passenden Entscheidungen für seine Arbeit treffen kann.

Sicher gibt es noch mehr und je nach Situation stehen andere Aspekte im Vordergrund. Bei mir drücken diese Stories den Reifegrad unseres agilen Produktmanagement-Prozesses ganz gut aus. Der Umgang mit Stories und Epics klappt und die Sprints laufen so, wie man es eben mit Scrum macht. Aber ein letzter Baustein, das Zusammenbringen der Stakeholder-Sicht (Strategie-Vorgaben und deren Nachverfolgung) und der gelebten agilen Arbeitsweise hat noch Potenzial nach oben.

Kennt agiles Vorgehen keine Termine?

Scrum einzuführen bedeutete einen Kulturwandel voranzutreiben. Weg von einer Wasserfallplanung mit großen Konzepten, hin zu kleinen Iterationen, hin zu einer schnelle Rückmeldung und hin zu neuen Entscheidungen zu den Prioritäten alle 2 Wochen. Und wie viel im nächsten Sprint erledigt werden kann, das entscheidet nur das Team alleine.

Dies führte insgeheim zu der Wahrnehmung, dass „Dinge eben fertig sind, wenn sie fertig sind.“ Eventuell braucht man halt noch einen Sprint – ein Zustand, der das Team vor Adrenalin schützt. Die Auftraggeber nicht. Sie möchten schlicht wissen, wann etwas fertig ist und was sie dann haben. Jeder weitere Sprint lässt den Adrenalin-Spiegel eher steigen.

Und genau in der Mitte dieses Adrenalinspiegel-Gefälles sitzt das agile Produktmanagement (egal ob Produktmanager oder Product Owner). Auf der einen Seite die Segnungen der Agilität, auf der anderen Seite die Wichtigkeit von verbindlicher Planung. Wie bringt man das zusammen? Wenn es um Produktentwicklung geht, dann hat beides seine Richtigkeit. Meine Erfahrung zeigt: Es ist ein Thema von Transparenz und Kommunikation.

Schauen wir uns das nochmal aus den zwei Perspektiven an. Die Geschäftsleitung gibt dem Produktmanagement ein strategisch wichtiges Thema vor und möchte das Produkt in drei Monaten passend erweitert haben. Der Product Owner erstellt zusammen mit dem Team ein begeisterndes Konzept, das in grob drei Monaten umsetzbar sein sollte. Das Team plant immer einen Sprint und optimiert darauf, dass alles im Sprint fertig wird. Schaut man immer nur 2 Wochen voraus, läuft man schnell Gefahr den Aufwand für eine Story nicht mehr in den Gesamtzusammenhang zu stellen und macht „zu viel/zu schön“. Und Softwareentwicklung dauert (oft) länger, als man ursprünglich denkt. Die Geschäftsleitung hat das Ende der drei Monate fest im Kopf, das Team eher den nächsten Sprint. Wo man im Wasserfall oft komplett Schiffbruch erleidet, kann man eben auch in kleinen Etappen agil untergehen.

Hier muss eine gemeinsame Bewertungsbasis der Fortschritte und der verbleibenden Anforderungen transparent und im offenen Austausch gepflegt werden. Agilität sollte helfen möglichst früh ein passendes Produkt an den Kunden auszuliefern, nicht zu einem beliebigen Zieltermin ein perfektes Produkt zu erstellen. Der Zeitraum, für den ein Budget zur Finanzierung von Entwicklungen bereitgestellt wird, kennt immer einen Anfang und ein Ende. Das agile Vorgehen ist nur der Modus, wie innerhalb des Zeitraums an dem Thema gearbeitet wird.

Ein Thema, zwei Ebenen

Macht man sich diesen Umstand bewusst, dann bekommt man die scheinbar verschiedenen Welten der Geldgeber und der Umsetzer besser miteinander verbunden. Der Vorwurf eines Teams an die Stakeholder „Man kann nicht im Wasserfall denken und gleichzeitig agil arbeiten wollen!“ kann so aufgelöst werden: Es geht um verschiedene Ebenen. Der Geldgeber denkt eine Ebene über der agilen Vorgehensweise und muss so abgeholt werden. Das Produktmanagement muss beide Welten verstehen und diese geschickt verbinden.

Jira alleine genügt hier nicht. Googeln Sie nach „In Jira den Überblick behalten“ und sie finden gleich zwei Lösungen aus dem Hause Atlassian: Gantt-Darstellungen in Confluence werden genutzt und die Erweiterung Jira Portfolio adressiert genau das Problem. Wir haben mit beiden Ansätzen versucht das Thema bei uns anzugehen, jedoch hat es nicht geklappt. In unserem Fall lag der Grund darin, dass beide Sichten eher von Entwicklern bevorzugt werden. Und natürlich haben wir auch Excel verwendet. Doch auf Dauer war auch das keine Lösung.