Sei es drum, des Pudels Kern ist ja, dass durch die Einführung von Scrum die „traditionellen“ Rollenmodelle ausgedient haben und nun die richtigen Mitarbeiter für die Scrum Ergebnisverantwortlichkeiten gefunden werden müssen. Aber warum tun sich Banken dabei so extrem schwer? Ich möchte das an dem Beispiel des Product Owners erläutern, da sich bei dieser Personalie die Institute am schwersten tun. Um das zu verstehen, aber nochmal kurz zu den traditionellen Rollenmodellen.
Es war einmal, oder: Die traditionelle Change-the-Bank-Organisation
Traditionell folgen Projektorganisationen der Aufbauorganisation der Bank. Heißt, es gibt eine Projektleitung, bestehend aus einem fachlichen Projektleiter, welcher für die involvierten Fachbereiche steht, und einen IT-Projektleiter, welcher für die beteiligten IT-Abteilungen steht.
Darunter befinden sich meist mehrere Teilprojekte mit entsprechenden Teilprojektleitern jeweils für die fachlichen und die IT-Themen sowie für das Thema Test. Die Teilprojektleiter steuern dabei die Umsetzung ihrer jeweiligen Aufgabenpakete und die Projektleiter überwachen den Gesamtfortschritt und die klassischen Dimensionen Qualität, Kosten und Zeit.
Damit folgt die Projektorganisation der Aufbauorganisation der Bank mit einer Trennung von Fachbereich- und IT, aber darüber hatte ich ja schon berichtet (siehe meinen Blog-Artikel). Diese Trennung erfolgt allerdings auch im laufenden Betrieb. Hier wird oft zwischen einem Application Owner und einem System Owner unterschieden. Während der System Owner in der IT-Organisation beheimatet ist und sich eher um IT-Infrastrukturthemen kümmert, ist der Application Owner auf der Fachseite und kümmert sich um fachliche Freigaben, Berechtigungen und ähnliche Dinge.
Der Product Owner, die eierlegende Wollmilchsau
Schaut man sich die Verantwortlichkeiten eines Product Owners einmal genauer an, stellt man fest, dass diese Person gleich mehrere klassische Rollen innehat:
- TPL Fach bzw. PL Fach: Er muss ein tiefes Verständnis des Business haben, um die Gespräche mit den Stakeholdern inhaltlich überhaupt verstehen zu können und Anforderungen bewerten zu können.
- Enterprise Architekt: Er muss die Geschäftsstrategie verstehen und ableiten können, was dieses für sein verantwortetes Produkt funktional und technisch bedeutet.
- TPL IT bzw. PL IT: Er muss ein gutes Verständnis der IT-Prozesse im Unternehmen haben und wissen, welche Technologien strategisch im Unternehmen verwendet werden sollen
- Testmanager: Er muss die Testprozesse kennen, die erforderlich sind, um Software produktiv einzusetzen.
- IT-Manager: Er muss eine Produktstrategie und eine Produkt-Roadmap entwickeln können.
Wo finden wir denn nun so eine Person in einer Bank? Leider gar nicht. Und diese wird sich auch so schnell nicht finden lassen, denn dazu muss er zu viele Kenntnisse aus zu unterschiedlichen klassischen Rollen mitbringen. Was also tun?
Der Application Owner als Product Owner? Bad idea…
In der Anfangszeit ließ sich beobachten, dass die Rolle des Application Owners als Product Owner „umdeklariert“ wurde. Nun war es so weit: Der Fachbereich, vertreten durch den Application Owner, konnte endlich selbst entscheiden, was umgesetzt wird. Die Entwickler wurden angehalten nur noch fachliche Funktionen möglichst schnell und einfach umzusetzen. Was war die Folge? Der geneigte Leser ahnt es, die Anwendung war nach kurzer Zeit nicht mehr wartbar, weil technische Schulden nicht umgesetzt wurden und man am Ende nur noch mit Bugfixing beschäftigt war. Von Time-to-Market wollen wir mal lieber gar nicht erst reden. Es fehlte die technische Expertise, was es heißt eine Software zu entwickeln.
Gehen wir mal einen Schritt weiter: Stellen Sie sich einmal vor, ich bin Kunde Ihrer Bank und verwende Ihre Online-Banking-Software für Wertpapiertransaktionen. Würden Sie mich zum Product Owner Ihrer Wertpapieranwendung machen? Wohl eher nicht! Warum machen Sie dann jemanden aus dem Fachbereich zum Product Owner? Was also tun? Naheliegend ist, eine Doppelspitze aus Fachbereich und IT als Product Owner zu besetzen. Klingt super, oder?
Das Highlander-Prinzip beim Product Owner: Es kann nur einen geben!
Die Frage war jetzt rhetorisch formuliert, aber um es einmal auf die Spitze zu treiben: Nehmen Sie mal an, zwei Fachbereiche würden die Anwendung verwenden, z.B. Einkauf und Rechnungswesen. Würden Sie dann drei Product Owner, also zwei aus dem Fachbereich und einen für die IT, für die Anwendung einsetzen?
Einmal abgesehen davon, dass ich geteilte Verantwortung so gut wie nie als funktionierend erlebt habe, machen Sie hier einen Stakeholder zum Entscheider. Aus Scrum-Sicht ein fataler Fehler, denn Entscheidungen über das Produkt können nicht mehr unabhängig vom Stakeholder getroffen werden, was aber eine wesentliche Eigenschaft des Product Owners ist. Wie bekomme ich aber diese eierlegende Wollmilchsau von Product Owner in meinem Unternehmen etabliert, wenn ich keine Mitarbeiter mit den erforderlichen Kenntnissen habe?
Quo Vadis Product Owner?
Ein Großteil der Kenntnisse eines Product Owners sind IT-Kenntnisse. Seien es Architekturen, IT-Prozesse oder IT-Management-Prozesse. Daher ist es zunächst einmal naheliegend, Product Owner in den Reihen der IT zu suchen. Um die Unsicherheit in fachlichen Fragen, z.B. bei der Bestimmung des Nutzens, zu kompensieren, können zwei Dinge sinnvollerweise umgesetzt werden. Zum einen ein aktives Coaching der Product Owner, zum anderen können Key-Stakeholder helfen, die fachlichen Themen einzuordnen, zu verstehen und zu priorisieren. Ich möchte diese nicht als fachliche Coaches bezeichnen, eher als fachliche Berater, welche dem Product Owner in diesen Fragestellungen zur Seite stehen.
Mein Fazit zur Rolle des Product Owners in Banken: Den Product Owner aus dem Fachbereich zu besetzen ist keine gute Idee, da die Trennung von Stakeholder und Product Owner nicht mehr gegeben ist. Es ist also Aufgabe, diese Rolle erst einmal zu entwickeln und geeignete Personen entsprechend zu unterstützen, damit sie in die Rolle hineinwachsen können. Aber bis dahin ist es noch ein weiter Weg.
Andreas Milanese
