Kolumne

Karrieretipps: Ownership vs. Leadership – wo liegt der Unterschied?
Keine Kommentare

In agilen Strukturen gibt es die Rollen des Business Owners, des Product Owners, des Service Owners. Aber was bedeutet Ownership in diesem Zusammenhang? Können sich die Owner in ihren Rollen denn wirklich immer so verhalten, wie es lehrbuchhaft in der Scrum-Methodik von ihnen verlangt und erwartet wird? Und umgekehrt: Agieren die Owner in ihren Rollen denn tatsächlich immer so, wie es nötig wäre, oder stehen hier andere Rollen im Weg, die sie gewollt oder ungewollt zusätzlich übernehmen (müssen)?

Der Kunde steht im Mittelpunkt der IT – das gilt im IT-Service-Management genauso wie in der Entwicklung oder bei der Implementierung. Agiles Arbeiten hat branchenübergreifend und in nahezu alle IT-Bereiche Einzug gefunden. Damit verfolgt man grundsätzlich den Zweck einer anpassungsfähigeren und stärker kundenfokussierten Ausrichtung. So weit, so gut. Mit der Einführung der Owner-Rollen sollen die komplexen Zusammenhänge und notwendigen Abstimmungen zwischen dem Business und der IT besser gelingen.

Dennoch entstehen oft Reibungsverluste genau dann, wenn die Owner ihr Revier eher verteidigen als es zu öffnen. Was ist damit gemeint? Wenn die Fachabteilungen z. B. Kompetenzen an den Service Owner abgeben müssen, hört der Spaß oft auf. Dann werden Service Level Agreements verfasst, die den Service Owner schnell in Schwierigkeiten bringen können, wenn er selbst nicht mit der notwendigen Manpower und den erforderlichen Kompetenzen ausgestattet ist.

In der Entwicklung ist das ähnlich. Oft herrscht das folgende Denken: Warum braucht es einen Product Owner, wenn es doch schon jemanden gibt, der die Führungsaufgabe übernimmt? Und sollten nicht alle am Entwicklungsprozess beteiligten Personen Ownership für ihr Produkt übernehmen? Hier ist oft die Wurzel des Problems zu finden.

Wie bringe ich mein Team dazu, Ownership zu übernehmen?

Oft herrscht inmitten alltäglicher Hektik ein reaktiver Arbeitsstil vor. Entwicklerinnen und Entwickler warten auf Informationen oder Freigaben, während sich an anderer Stelle schon wieder Baustellen auftun, die oberste Priorität haben. Der Product Owner versucht, alle Fäden zusammenzuhalten, hält seinen Kopf beim Management für das Produkt hin und stimmt sich mit allen Fachbereichen und Stakeholdern ab. Die Ideen und Anforderungen bringt er in das Entwicklerteam ein und spiegelt wiederum die Ideen und Umsetzung an seine „Kunden“ zurück. Ownership bedeutet also, die Verantwortung für die Entstehung eines optimalen Produkts im Rahmen eines termingerechten Release zu übernehmen. Aber Ownership ist nicht automatisch Leadership. Verantwortung kann und muss auch auf das Team verteilt werden, selbst wenn der Owner letztlich die Gesamtverantwortung trägt.

Spielt sich der Product Owner zu sehr als Leader auf, kann er nicht unbedingt auf die Unterstützung seines Teams hoffen. Gibt er andererseits zu viel Verantwortung ab, riskiert er, den Überblick zu verlieren. Klar ist, dass ein Product Owner über eine hohe Fachkompetenz verfügen muss, um Anforderungen und Umsetzbarkeit grundsätzlich beurteilen zu können. Aber die Hauptanforderung besteht darin, die Schnittstellen zusammenzubringen und vor allem auch das Entwicklerteam dazu zu bringen, die Anforderungen der Kunden passgenau zu einer Lösung zusammenzufügen.

Dazu müssen sich aber eben auch alle Projektmitglieder als Beteiligte mit Verantwortung verstehen und nicht als einfache Mitglieder in einem komplexen Prozess, auf den sie keinen Einfluss nehmen können. Jedes Teammitglied muss sich mit seinem Produkt, an dem es arbeitet, identifizieren. Jede Entwicklerin, jeder Entwickler muss sich für ihren und seinen Part am Ganzen verantwortlich, vor allem aber auch wertgeschätzt fühlen. Und da haben wir wieder das altbekannte Wundermittel Wertschätzung, das einen großen Teil dazu beiträgt, ob Mitarbeiter bereit sind, für ihre Arbeit vom Anfang bis zum Ende Verantwortung zu übernehmen, ob sie als Macher vorangehen, sich fehlende Informationen besorgen, Ideen konstruktiv einbringen – statt zu hadern und abzuwarten. Wer also sein Team zu mehr Ownership bewegen will, muss jedem und jeder Einzelnen Respekt, Anerkennung und Wertschätzung entgegenbringen.

Ebenso muss er ihnen Entscheidungsspielräume und Mitspracherecht einräumen. Dabei ist darauf zu achten, dass sich nicht immer nur die Lautstarken im Team durchsetzen und gehört werden, sondern dass auch die Stillen befragt werden. Jede Meinung sollte gleich viel zählen, und am Ende sollte die Arbeit des gesamten Teams sichtbar gemacht werden. Auch das ist Aufgabe des Product Owners, somit ähneln sich hier die Anforderungen, die auch an eine Leadership-Rolle gestellt werden.

Wo hört Ownership auf und wo fängt Leadership an?

Natürlich gibt es in beide Richtungen fließende Übergänge. Ein Product oder Service Owner muss durchaus Anforderungen erfüllen, die auch an Leader gestellt werden. Sie müssen es schaffen, das Team mit den relevanten Informationen zu versorgen, um das Produkt in Time und in Budget zu liefern. Ebenso müssen Leader täglich Ownership übernehmen, da sie die Gesamtverantwortung auf Managementebene für das Team und dessen Leistung tragen. Dennoch gibt es auch scharfe Trennungen, wie in Tabelle 1 dargestellt.

Leadership: Leader … Ownership: Owner …
… geben die Vision und Mission für das Team vor … kennen die Anforderungen der Kunden, steuern das Entwicklerteam und stellen alle relevanten Schnittstelleninformationen bereit
… überwachen die Einhaltung der Strategie … sorgen für die Umsetzung der Strategie
… räumen Hindernisse aus dem Weg bzw. stellen die notwendigen Arbeitsbedingungen auf höherer Ebene sicher … erkennen Hindernisse und tragen diese der Leadership vor
… überwachen die kontinuierliche langfristige Verbesserung der Arbeits-leistung und sichern den Erfolg … identifizieren Verbesserungspotenzial im Entwicklungsprozess in Abstimmung mit den Entwicklern
und vieles mehr und vieles mehr

Tabelle 1: Leadership und Ownership

Zusammenfassend lässt sich Ownership als ganzheitliche Anforderung beschreiben, die es schafft, mit allen relevanten Schnittstellen so zu kommunizieren, dass jeder sich als wichtiger Teil am Gesamtprozess versteht. Ein guter Ansatz ist es, Entwicklerinnen und Entwickler so an der Verantwortung zu beteiligen, dass sie während des Entwicklungsprozesses und beim fertigen Produkt ihre eigene Handschrift sichtbar machen können. Wer es schafft, Entwickler zu Ownern ihrer eigenen Arbeit zu machen, ohne dabei die eigene Ownership ganz abzugeben, der hat seine Rolle als Product Owner verstanden. Es bleiben jedoch immer noch die täglichen Herausforderungen im Umgang mit unterschiedlichen Persönlichkeiten und Rollenverständnissen von Seiten des Kunden und des Managements, welche die Aufgabe eines Product Owners oder Service Owners (aber natürlich auch die des Business Owners) so spannend und herausfordernd machen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -