Ich schreib‘s an jede Wand, neue Rollen braucht die Bank

Da habe ich mir so einen schönen Titel frei nach Ina Deter (die Kinder der 80er werden es kennen) einfallen lassen und was passiert? Der Scrum Guide ersetzt den Begriff Rolle durch Ergebnisverantwortlichkeit…

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

Der Manager ist tot – Lang lebe der Manager!

OK, der Titel ist ein wenig geklaut, schrieb doch das CIO Magazin vor langer Zeit unter einer ähnlichen Überschrift, dass es den klassischen CIO nicht mehr lange geben werde. Damals war Outsourcing der Auslöser, welcher die Aufgaben und Tätigkeiten einer IT neu definierte. Und jetzt? Agilität spricht von selbstorganisierenden Teams, die Entscheidungen eigenständig treffen, Product Owner, welche die Hoheit über ein zu erstellendes Produkt haben, wer braucht da noch Manager?

Definiert Scrum nicht sogar nur drei Ergebnisverantwortlichkeiten – Entwickler, Scrum Master und Product Owner? Manager kommen da nicht mehr vor und tatsächlich sind Manager mit am stärksten vom agilen Wandel betroffen. Aber was ist denn nun mit Managern, benötige ich sie noch, oder sind diese in einem agilen Unternehmen überflüssig geworden? Tatsächlich lässt sich in vielen Banken beobachten, dass im Management viele Positionen abgebaut wurden, insbesondere im mittleren Management. Das spräche dafür, dass Manager in einer agilen Welt nicht mehr benötigt werden. 

Der Aggregatzustand oberhalb von flüssig: überflüssig

Liebe Manager: an dieser Stelle bitte einmal kräftig durchatmen. Manager werden auch zukünftig benötigt. Allerdings nicht mehr in dem bisherigen Umfang und mit neuen Aufgaben. An dieser Stelle, liebe Manager, müsst ihr sehr tapfer sein, denn euer Job wird sich durch Agilität signifikant verändern. Der neue Typ Manager ist ein Agile Leader. Toller Begriff, aber was steckt da eigentlich dahinter? Und vor allem, was ändert sich in den Jobrollen? 

Der neue Typ Manager ist mehr mit den Themen Führung und Coaching beschäftigt, als damit, Entscheidungen zu treffen. Das heißt, die Verantwortung für die Weiterentwicklung der Mitarbeiter im agilen Sinne liegt bei den Managern. Ihr Ziel ist es, Teams zu befähigen, im agilen Sinne zu arbeiten und sie weiterzuentwickeln, um ihr Unternehmen noch agiler werden zu lassen. Agile Leader nehmen das Unternehmen mit auf die agile Reise, und sorgen gemeinsam dafür, dass das Unternehmen immer besser wird. Aber ist es dann nicht damit getan, alle Mitarbeiter auf eine Scrum Schulung zu schicken? Weit gefehlt. Warum, mache ich mal an einem konkreten Beispiel klar.

It’s a long way to Tipperary und ein noch längerer zu agilen Teams

Nehmen wir mal an, ich bin Manager in einer weltweit operierenden Bank. Die Strukturen waren in der Vergangenheit immer streng hierarchisch und den Mitarbeitern wurde über Jahrzehnte angewöhnt, keine eigenen Entscheidungen zu treffen. Jetzt kommt Agilität, also schicke ich meine Mitarbeiter auf eine dreitägige Scrum Schulung und sorge dafür, dass sie ihre Zertifizierung bekommen. Nun soll das Team zum ersten Mal agil zusammenarbeiten und es gilt, die ersten Entscheidungen zu treffen. Was wird wohl passieren? Mit hoher Wahrscheinlichkeit wird man Sie bitten, eine Entscheidung zu treffen, was Sie selbstverständlich im Sinne des agilen Gedankens ablehnen. Aber war diese Entscheidung richtig? Sie ahnen die Antwort: Nein. 


Aber warum war das nicht richtig? Sollten Teams nicht selbst Entscheidungen treffen? Natürlich sollen sie das, aber die Welt ist nun mal nicht schwarzweiß, sondern hat deutlich mehr Grautöne. Für die Entwickler unter meinen Lesern: Agilität hat nicht den Datentyp Boolean. Das Zauberwort in diesem Zusammenhang lautet „Agile Maturity“, bei welcher die unterschiedlichen Mitarbeiter in ihren Ergebnisverantwortlichkeiten unterschiedliche Senioritätsstufen erreichen können, im Übrigen auch Manager...

Es ist noch kein Meister vom Himmel gefallen: Keep calm and play poker

Die gängigen Maturity Modelle gehen von fünf Entwicklungsstufen aus. Vom einfachsten Level, in welchem die Mitarbeiter stark geführt werden sollen, bis hin zu Stufe fünf, in welcher Mitarbeiter echte agile Vollprofis sind. Als Agile Leader muss ich diese Entwicklungsstufen kennen, um individuell auf Teams eingehen zu können und diese auch entsprechend gezielt weiterzuentwickeln. Einen unerfahrenen Mitarbeiter muss ich anders coachen als jemanden, der schon zehn Jahre Berufserfahrung hat. 


Unter diesem Gesichtspunkt wird auch klar, dass es nicht richtig war, als Agile Leader die Entscheidung wieder ins Team zu geben, da dieses noch zu unerfahren war, diese selbst zu treffen. Die Frage lautet nun, wie kann ich als Agile Leader mit den unterschiedlichen Entwicklungsstufen umgehen? Die Antwort ist simpel: Einfach eine Runde Poker spielen. Stopp! Das Taxi ins Casino Wiesbaden bitte wieder abbestellen, denn wir spielen Delegation Poker. Hier gibt es unterschiedliche Arten, wie ich mit offenen Entscheidungen in Teams umgehen kann. Von Verkünden, über Verkaufen, Befragen, Einigen, Beraten, Erkundigen bis hin zu Delegieren habe ich mögliche Vorgehen, die ich als Agile Leader verwenden kann. Je erfahrener das Team, umso mehr kann ich Entscheidungsgewalt abgeben. Ziel ist immer, dass das Team in die Lage versetzt wird, Entscheidungen eigenverantwortlich zu treffen, je erfahrener das Team, umso weniger muss ich als Agile Leader eingreifen.

Quo vadis Manager?

Tja, das mal als kleiner Ausblick, wie sich das Leben als Manager zukünftig ändern wird. Wird es schlechter, auf keinen Fall. Aber wesentlich anders. Fokus ist nun die agile Entwicklung des Unternehmens voranzutreiben. Der Weg ist lang und da auch immer wieder Mitarbeiter mit wenig Erfahrung ins Unternehmen kommen, wird er in absehbarer Zeit nicht enden. Wichtig ist die neue Führungsrolle im Unternehmen zu verstehen und mit Leben zu versehen. Der Agile Leader ist Coach und Führungskraft, er muss den agilen Gedanken nicht nur verstehen, sondern auch transportieren und ist gleichzeitig Vorbild für die agile Organisation. Je erfahrener die Mitarbeiter werden, umso weniger wird der Agile Leader entscheiden, sondern die Mitarbeiter dahingehend unterstützen, die richtige Entscheidung zu finden. Wird diese Rolle angenommen, muss selbst erfahrenen Managern zugestanden werden, in diese neue Rolle hineinzuwachsen und sich entsprechend weiterzuentwickeln.

Mein Fazit zur Rolle des Managers in Banken: Es werden zukünftig mit Sicherheit weniger Manager benötigt, als es heute noch der Fall ist. Diejenigen Manager müssen sich aber zum Agile Leader weiterentwickeln, um signifikanten Mehrwert für das Unternehmen zu erzielen. Hierfür müssen diese aber auf diese neue Reise mitgenommen und auch entwickelt werden, was aus meiner Sicht noch viel zu wenig passiert. Agile Leader in der höchsten Entwicklungsstufe müssen eben auch erst ausgebildet und gecoacht werden, will ich als Unternehmen erfolgreich Agilität einsetzen.

Andreas Milanese