Bin ich eine Rolle? Und wenn ja, wie viele?

Lesedauer ca. 16 Minuten

Rollenbasierte Konzepte sind aktuell überall zu sehen, aber was ist eine Rolle?

Schauen wir auf Methoden im Bereich Lean/Agile wie bspw. Scrum, gibt es den Scrum Master und den Product Owner. Schauen wir auf SAFe wimmelt es nur so von Rollen (selbst wenn es komplizierter scheint als es ist, denn die Rollen über die Ebenen hinweg ähneln sich stark). Und in Methoden im Bereich Teal wie bspw. Holacracy und S3 bilden Rollen das wesentliche Element, entweder vordefiniert (bspw. Circle Lead oder Repräsentant) oder eben durch die Mitglieder selbst definiert. (Zu den Konzepten „Agile“ und „Teal“ siehe auch Alles und immer nur „Agile“? Was ist „Teal“?)

Rollen sind also ein zentrales Element in New-Work-Konzepten. Aber was ist eine Rolle eigentlich?

Während die Agilen Methoden hier keinen Definitionsrahmen geben, sondern die wenigen benötigten Rollen einfach direkt beschreiben, bieten Teal Methoden in der Regel eine Vorlage, dies zu tun. Hieran erkennen wir die Historie der beiden Konzepte und deren Schwerpunkt: Agile fokussiert auf die Ablauforganisation, also die Gestaltung von Prozessen und Teal fokussiert auf die Aufbauorganisation, also die Gestaltung von Strukturen, wo Rollen und Verantwortlichkeiten ein größere „Rolle spielen“.

Wer kennt das nicht? Das Unternehmen will sich agilisieren und die ersten Scrum Teams entstehen. Personen, die vorher eine (!) Stelle (!) hatten, haben nun mehrere Rollen, bspw. Product Owner und People Manager. Aber was bedeutet es eigentlich eine Rolle zu haben? Was ist eine Rolle? Oft kann man beobachten, dass sich dann Probleme ergeben, weil man die damit verbundenen Verantwortlichkeiten oder die Wirkung auf andere sich nicht ausreichend bewusst gemacht hat.

Und genau dies ist der Ausgangspunkt für diesen Artikel, der nichts anderes bewirken soll, als sich bewusst zu machen, welche Facetten dieser Begriff haben kann. Denn Rollen sind auch nur ein Werkzeug und wie immer gilt: „A fool with a tool is still a fool“. Also wenn man nicht weiß welche Dimensionen (Handlungs- vs. Wirkungsrollen) und Implikationen (bspw. Verantwortung und Motivation) Rollen haben, wird man schwer durch ihren Einsatz erreichen, was man erreichen wollte.


Aufbauorganisation vs. Ablauforganisation

Fangen wir an mit ein paar Definitionen. Zunächst einmal bleibt es dabei, dass es eine „Rolle“ überhaupt gibt. Und die Rolle wird von Menschen gefüllt/besetzt/ausgeführt oder im Holacracy-Sprech „energetisiert“ („Article I: Energizing Roles”, [HolacracyOne2016:2ff.]) . Dabei kann ein Mensch mehrere Rollen ausfüllen und eine Rolle kann mehrfach besetzt sein. Wozu das Ganze? Um Arbeit zu erledigen. Arbeit ist somit das zu Tuende (gerne klein geschnitten) und wird von den Rollen (bzw. mittelbar von deren Trägern) getan. Die Arbeit zeigt sich also in vielen Paketen und ein solches Paket kann von mehreren Rollen gemeinsam getan werden und wieder gilt auch andersherum: eine Rolle kann mehrere Arbeitspakete bearbeiten. Hier eine erste Übersicht auf diese Zusammenhänge:

Zusammenhang zwischen Mensch, Rolle und Arbeit
Abb. 1: Zusammenhang zwischen Mensch, Rolle und Arbeit

Oben wurde Arbeit als „das zu Tuende“ definiert. Sie zeigt sich also in einem Entstehungsprozess an dessen Ende ein Ergebnis steht. Das Handeln mündet in einem Ergebnisobjekt (wobei „Objekt“ nicht materiell sein muss, und „Denken“ ein Handeln im hiesigen Sinne sein kann). Wie oben gesagt und oft aus dem Arbeitsalltag bekannt, wird ein solches Ergebnis durch das Zutun Vieler erreicht. Dies ist der Entstehungsprozess, an dem mehrere Rollen beteiligt sind. Solch einen Entstehungsprozess haben die Konzepte Lean und Agile vor allem im Blick und die dort definierten Rollen wie Request Manager oder Product Owner sind somit Beteiligte/Mitmacher auf dem Weg zum Ergebnis. Solche Rollen will ich im Folgenden Handlungsrollen nennen und sie sind wesentliches Element der Ablauforganisation.

Kette Idee-Handeln-Ergebnis
Abb. 2: Der Idee folgt das Handeln, welches ein Ergebnis hervorbringt

Dieses Ergebnis soll meistens eine Wirkung erzielen. In dem Wort „erzielen“ steckt schon das Wort „Ziel“, welches seinerseits wieder einem (höheren) Sinn dienen soll. Für den Begriff Sinn werden alternativ auch „Vision“, „Purpose“, „Objective“ und weitere Begriffe verwendet. Populär ist eine Implementierung von Ziel-Sinn-Zusammenhängen mittels OKR mit Objective (O) als Sinn und Key Results (KR) als Zielen. Dies wird vor allem in den Teal Konzepten elaboriert. Lassen wir den Zwischenschritt „Ziel“ für die aktuelle Betrachtung aus dem Spiel und wir bekommen:

Zusammenhang zwischen dem Ergebnis des Handelns und der erzielten Wirkung und dem dahinter stehenden Sinn
Abb. 3: Zusammenhang zwischen dem Ergebnis des Handelns und der erzielten Wirkung und dem dahinter stehenden Sinn

Für den hinteren Teil der Wertschöpfungs- oder Sinnverwirklichungskette, werden in Unternehmen oft ebenfalls Rollen oder in Old Work Stellen definiert. War es früher der Abteilungsleiter, der zu verantworten hatte, wie das entwickelte Produkt sich verkaufen lässt, so gibt es heute den Product Owner, der die Auswirkungen „seines“ Produktes nun zu verantworten hat. Diese Rollen nenne ich im Folgenden Wirkungsrollen und sie sind Elemente der Aufbauorganisation.

Gesamtbild der Handlungsrollen und Wirkungsrollen
Abb. 4: Gesamtbild der Handlungsrollen und Wirkungsrollen

Verantwortung & Motivation

Ich möchte nun auf zwei Aspekte eingehen, die wichtig sind in diesem Kontext: Verantwortung und Motivation.

Verantwortung

Die Differenzierung von Ergebnis und Wirkung ist vermutlich die Grundlage für die gefühlt schon seit ewigen Zeiten ausgetragenen Diskussionen im Englischen rund um die Begriffe Repsonsibility und Accountablity. Responsible ist jeder Handelnde (ob in einer Rolle oder nicht) und das sich materialisierende Ergebnis (im Englischen wird das meist mit Output bezeichnet). Accountable ist eine bestimmte Rolle/Person und die Accountablity bezieht sich dann auf die Wirkung, die das Ergebnis entfacht (im Englischen dann Outcome).

In Scrum wird bspw. explizit der Rolle des Product Owners die Verantwortung für das Produkt im Sinne seiner Auswirkungen gegeben. Im Scrum Guide heißt es: „The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team“ (Kursivsetzung durch mich) , [SchwaberSutherland2020en]. Gleichwohl ist er auch am Entstehungsprozess beteiligt, weil er bspw. den Umfang einer Story mit sich verhandeln lässt, Rückfragen beantwortet und das Ergebnis abnimmt. Hier tragen alle am Entstehungsprozess Beteiligten jeweils Verantwortung für ihr Handeln und das gemeinsame Ergebnis[1], jedoch nicht für die Wirkung der erstellten Artefakte. Diese Verantwortung trägt der Product Owner allein. Freilich ist das Konzept „Agile“ weiter gefasst als Scrum und so kann man fordern, dass das gesamte Team in diese Verantwortung reinwachsen soll. Das wird bspw. im Agile Fluency© Project (siehe https://www.agilefluency.org/) deutlich, wenn die Praktik „Market Expertise“ eingeführt wird und man sich um die Zone „Optimizing“ kümmert: Hier soll das Team an der Wirkung seiner Ergebnisse teilhaben und selbst Experimente für den rechten Wirkungsstrang durchführen.

Dieses „an den Markt“ / „an den Kunden“ heranführen ist einer der Grundsätze in Rendanheyi: „Null Abstand zwischen Kunde und Team“. Das ist es, was Teal Konzepte auszeichnet: „evolutionary purpose“, eines der von Laloux als „breakthrough ideas“ benannten Merkmale [Laloux2014]. Die Heranführung der Rollen(träger*innen) an den Sinn und konsequente Ausrichtung jeglichen Handelns am Sinn. Eine direkte Übersetzung von „Rendanheyi“ beschreibt genau das: „Ren“ bedeutet Mitarbeiter, „Dan“ bedeutet Wert (also die Entfaltung von Wirkung des Ergebnisses im Hinblick auf den Sinn) und „Heyi“ bedeutet das Zusammenbringen von Ergebnis und Sinn [Haier2018]. So werden in Holacracy Rollen nach einem Schema definiert, welches zunächst mal nach dem Sinn der Rolle fragt. Und dieser Sinn orientiert sich am Sinn des Kreises (vereinfacht gesagt ist ein Kreis eine größere Rolle[2]), welcher sich wieder orientiert am übergeordneten Kreis usw. Und als ein weiteres Element werden „Accountabilities“ definiert. Im Teal-Sinne sollten diese „Verantwortlichkeiten“ nicht nur ergebnisorientiert (i. S. v. „Zuständigkeiten“), sondern auch sinnorientiert (i. S. v. ganzheitlicher Verantwortung) formuliert werden.

Während also in Teal-Unternehmen die Rollenträger*innen selbst in Verantwortung bis zur Wirkungsentfaltung in die Umwelt genommen werden, weil es bei Teal vor allem auf Sinnstiftung (daher auch gerne For-Purpose-Enterprises, FPE, genannt) und Selbstorganisation (eben auch im Sinne von Verantwortung) ankommt, definiert das Konzept „Agile“ entweder explizite Rollen, die diesen Teil übernehmen (wie in Scrum der Product Owner), oder hat dies gar nicht im Blick, weil es sich auf den Entstehungsprozess fokussiert.

Motivation

Motivation ist in der New-Work-Debatte ein riesiges Thema. Häufig wird auf Daniel Pink und sein Buch „Drive“ [Pink2011] referenziert, in dem er drei Treiber von Motivation identifiziert: Autonomy, Mastery, Purpose. Von mir gerne frei übersetzt mit Dürfen, Können, Wollen.

Wenn wir diese drei Motivationsfaktoren in das Schaubild integrieren, sehen wir welche Rollentypen hier wirken können.

Integration der Motivationsfaktoren in die Kette Handlung-Ergebnis-Wirkung-Sinn
Abb. 5: Integration der Motivationsfaktoren in die Kette Handlung-Ergebnis-Wirkung-Sinn

Purpose / Wirkungsrollen

In klassisch organsierten Unternehmen müssen CEO oder Abteilungsleiter*in erklären, worin der Sinn besteht und damit die Leute begeistern.

In agil organisierten Scrum Teams obliegt dieser Motivationsfaktor dem Product Owner. In Modellen, die Agilität skalieren, wird dies dann verschachtelt über die PO auf den verschiedenen Ebenen (in SAFe bspw. Product Owner – Product Manager – Solution Manager – Epic Owner).

In Teal Enterprises (For-Purpose-Enterprises, FPE) wird (über die (Gründungs)Mitglieder der Organisation) ein Sinn definiert, der fortan als im (Anker)Kreis formuliertes Element allen Rollen selbständig eine Ausrichtung gibt.

Autonomy & Mastery / Handlungsrollen

Für die im Entstehungsprozess liegenden Motivationsfaktoren Autonomy und Mastery liegt es in klassischen Organisationen wieder an der Führungskraft, denn sie bestimmt einen (meist engen) Rahmen innerhalb dessen die Mitarbeiter*innen überhaupt handeln dürfen und durch Zuteilung von Aufgaben bestimmt die Führungskraft, was sie den Mitarbeitern zutraut und ob es somit zu „noch bewältigbaren Herausforderungen“ kommt („Levelling“ in Gamification).

In Agilen Organisationen ist der Rahmen weiter gefasst und das Team darf als Gruppe vieles selbst entscheiden, bspw. wie viele Stories sie sich als Team zutrauen (Team Pull). Durch die Nähe zueinander können die Teammitglieder besser einschätzen, wem innerhalb des Teams was zuzutrauen ist und jede*r Einzelne wird ermutigt, sich selbst „zu nehmen“ (Member Pull) was er sich zutraut.

In Teal Organisations ist die Maxime die Umkehrung der Autonomie-Verhältnisse: Es gilt nicht mehr „Du darfst nur, was explizit erlaubt ist“, sondern „Du darfst nur das nicht, was explizit verboten ist“. D. h. Mitarbeiter*innen sind systematisch/systemisch autorisiert (Das Konzept sichert also den Motivationsfaktor Autonomie ab) und es ist in der Verantwortung jedes Einzelnen sich selbst und damit seine*ihre Fertigkeiten zu entwickeln (Mastery) – ähnlich einem Mitglied eines agilen Teams.

Zusammenfassung

Rollen sind aus den verschiedensten Gründen in vielen modernen Arbeitskonzepten enthalten.

Damit verkompliziert sich die Welt allerdings wieder, weil nicht mehr automatisch und ausschließlich in „Arbeiter*innen“ (Mitmacher im Entstehungsprozess = Handlungsrollen = Verantwortungsträger für Ergebnisse) und „Chefs“ (Verantwortungsträger für die Wirkung der entstandenen Ergebnisse = Wirkungsrollen) unterteilt wird, sondern Rollen sich über beide Verantwortungsbereiche erstrecken können (bspw. der PO in Scrum oder jegliche Rollen in einem Teal-Modell) und damit wesentliche Motivationstreiber in andere Hände gegeben werden.

Es ist also hilfreich, sich genau zu vergegenwärtigen, was eine Rolle eigentlich ist, wie sie definiert ist und wie sie wirkt. Hier schließt sich der Kreis für alle die gerade im Change-Management zur Einführung eines Rollenkonzepts unterwegs sind: Zunächst sind sie am Entstehungsprozess beteiligt, deren Ergebnis eine Rolle ist. Und dann werden sie wohl möglich in Verantwortung genommen, wie sich die Rollen auswirken. Warum wollten Sie noch gleich Rollen einführen? 😊

Referenzen

[Haier2018] Haier Group: „A General Understanding of Rendanheyi Model“, https://www.youtube.com/watch?v=zsfKfWshtiE , Zugriff am 29.04.2021

[HolacracyOne2016] HolacracyOne “Holacracy Constitution 4.1” (Desk Reference), 2016 – auch online unter https://www.holacracy.org/constitution

[Laloux2014] Laloux, Frederic, „Reinventing Organisations“, Nelson Parker, 2014

[Pink2011] Pink, Daniel, „Drive“, Penguin, 2011

[Robertson2015] Robertson, Brian J., “Holacracy”, Henry Holt, 2015

[Robledo2020] Robledo, Marco A., “3D Management”, Cambridge Scholars Publishing, 2020

[SchwaberSutherland2020de] Schwaber, Ken & Sutherland, Jeff, „Der Scrum Guide“, deutsche Übersetzung, 2020

[SchwaberSutherland2020en] Schwaber, Ken & Sutherland, Jeff, „Der Scrum Guide“, Zugriff 04.05.2022


Fussnoten

[1] Und nicht einmal das wird explizit gem. Scrum Guide verlangt bzw. muss man das in diesen Satz reininterpretieren: „Developer:innen sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Increments zu schaffen“ [SchwaberSutherland2020:6]

[2] Für mich wird hier ein Unterschied zwischen Teal und Turquoise deutlich, denn eigentlich ist eine Rolle nichts anderes als ein Kreis, aber ein Kreis ist nicht nur eine mehrfach besetze Rolle – nicht jedes Element scheint ein Fraktal zu sein, welches dem Ganzen selbstähnlich ist; für mich ein Unterschied zwischen „holistisch“ (Teal) und „wholistisch“ (Turquoise). (siehe auch [Robledo2020:48f])

Schlussbemerkung

Dies ist eine leicht überarbeitete Version meines Artikels, der zuerst in der Ausgabe 02/2021 der agile review von it-agile erschienen ist. Den Artikel können Sie hier auch als PDF runterladen.


Dieser Beitrag wurde veröffentlicht von:

am:



Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.