© best_vector/Shutterstock.com
Ownership vs. Leadership

Kolumne: Karrieretipps


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 terming...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang