In Unternehmen gehören sie zum Alltag: Projekte, die mit viel Schwung und Begeisterung gestartet wurden, dann aber aus unterschiedlichen Gründen wieder eingeschlafen sind oder zumindest vor sich hindümpeln. Agile Projekte sind zwar aufgrund ihrer dynamischen Struktur ein Stück weit immun gegen dieses „Einschlafen“, weil jedoch in vielen Organisationen nicht-hierarchische auf hierarchische Strukturen treffen, werden auch die agilen Projekte in Mitleidenschaft gezogen.
Wenn also nun ein Product Owner (PO) ein bestehendes Produkt übernimmt – was sollte er in welcher Reihenfolge tun, um die Dinge wieder ins Rollen zu bringen? Zunächst gilt es für ihn, den Status quo des Projekts zu ermitteln. Dazu gehören folgende Punkte:

• Zunächst ist es wichtig, genau zu prüfen, welche Rahmenbedingungen des Projekts noch unbekannt sind, und zwar anhand des Cynefin-Frameworks. Es ist ursprünglich ein Wissensmanagement-Modell, hat sich jedoch auch als Strategiemodell bewährt und erlaubt es, den Komplexitätsgrad eines Projekts zu ermitteln. Je nach Einordnung in einen der vier Quadranten des Frameworks kann der PO entscheiden, wie das Produkt, das er übernimmt, idealerweise entwickelt werden müsste.

• Im nächsten Schritt schaut sich der PO genau an, wie das Produkt tatsächlich aktuell entwickelt wird und wie groß die Diskrepanz zur passenden Cynefin-Framework-Kategorie ist: Ist es als Wasserfall-Projekt mit einem Planungshorizont von einem Jahr aufgesetzt? Und müsste laut Cynefin-Framework eigentlich ganz anders entwickelt werden? Wie lässt es sich dann umwandeln? Auf diese Fragen findet der PO hier Antworten und steckt die passende Vorgehensweise ab.

• Anschließend analysiert der PO die Kompetenzen der beteiligten Personen: Wer arbeitet alles mit? Welche technischen und sozialen Skills liegen vor? Passen sie zu den anstehenden Aufgaben?

• Schließlich überprüft der PO auch die liquiden Mittel – ohne die lässt sich kein Projekt umsetzen.

• Am Ende der Statusanalyse nimmt er das Produkt selbst in den Fokus. Die zu stellenden Fragen sind hier sehr produktspezifisch. Um es an einem Fallbeispiel zu verdeutlichen: Bei einer App, die für die Einwohner einer Stadt zu entwickeln ist und in der alle kommunalen Dienstleistungen und Services auf einen Blick erfasst und zum Teil auch genutzt werden können – vom öffentlichen Nahverkehr über Ausweisbeantragung und Schwimmbadeintritt bis Abfallentsorgung –, könnte es um folgende Fragen gehen: Welche Schnittstellen braucht die App eigentlich? Welche Eigenbetriebe und Tochterunternehmen müssen berücksichtigt werden? Welche Revenue Streams sind zu erwarten? Kann die App monetarisiert werden? Ist das überhaupt vorgesehen und sinnvoll?

Die Ergebnisse seiner Statusanalyse überträgt der PO dann in ein Business Model Canvas. Dort lassen sie sich übersichtlich präsentieren, sodass nicht nur der PO, sondern auch alle Stakeholder ein stimmiges Bild von der Situation bekommen.

Anschließend überlegt der PO, mit welcher Veränderung des Status quo er den ersten großen Effekt auf den Business Value seines Produkts schafft. Dann priorisiert er und beginnt mit dem obersten Item. Wenn er hier schnell Ergebnisse vorweisen kann, dann bereitet er den Boden für einen wichtigen Erfolgsfaktor des Projekts: das Vertrauen bei den Stakeholdern.
Um noch einmal zum Beispiel der App für kommunale Dienstleistungen und Services zurückzukehren: Dort lief das Projekt schon ein dreiviertel Jahr und hatte hohe Kosten verursacht, als der neue PO es übernahm – die App bzw. Plattform war aber noch nicht einmal online. Deshalb ermittelte er nach seiner Statusanalyse, dass es den Business Value des Projekts am meisten erhöhen würde, wenn die App möglichst schnell online ginge – noch bevor er beispielsweise die Personalsituation an die neuen Gegebenheiten anpasst.

Erst anschließend ist es wichtig, sich mit der Vision des Projekts bzw. Produkts zu beschäftigen und davon weitere Dinge abzuleiten: Was ist die Strategie für die nächsten zwei, drei Jahren, wie sieht die Roadmap aus, was sind die Epic Ziele, was die Aufgaben? Product Owner sehen sich an dieser Stelle oft mit Aussagen wie „Das wissen wir doch jetzt noch nicht!“ konfrontiert. Sie können dennoch Roadmap, Ziele etc. für das Produkt oder das Projekt formulieren. Auf Basis der Lebens- und Projekterfahrung lassen sich Querverbindungen ziehen, und sobald es neue Fakten gibt, lassen sich diese Dinge auch anpassen; hier ist nichts in Stein gemeißelt. Mit jedem kleinen Schritt das Unbekannte bekannter machen – darum geht es generell im Scrum. Und deshalb gilt dies genauso für die Strategie, die Roadmap und alle nachfolgenden Schritte.