5 Abos und 1 Abonnent
Artikel

Wie Organisationen sich mit Holacracy und Scrum selbst führen können

Braucht Selbstorganisation Führung? Ja! Doch Führung in selbstorganisierten Systemen ist an agile Rollen gekoppelt. Wir zeigen anhand von zwei prominenten Beispielen, wie das aussehen kann.

 

Wir alle erfüllen in unserem Leben mehrere Rollen. Wir sind Freund, Nachbarin, Elternteil, Arbeitskollegin oder Vereinsmitglied. Diese Rollen gehen mit verschiedenen Verantwortlichkeiten und Erwartungen an unser Verhalten einher, die von der oder dem Träger*in der Rolle unabhängig sind. Unsere Rollen verändern sich ständig, Verantwortungen wachsen oder werden weniger, wir nehmen neue Rollen an oder legen alte ab: Elternsein verändert sich, wenn das Kind älter wird, wir werden Teil des Vereinsvorstands und vielleicht wird die Nachbarin zur Freundin.

Rollen-basierte Organisationsmodelle tragen dem Umstand Rechnung, dass auch eine Organisation und ihr Umfeld ständig im Wandel sind. Mit Rollen können Arbeitsbereiche und Verantwortungen definiert werden, ohne das Unternehmen, in dem die Menschen arbeiten, in einer starren Hierarchie zu strukturieren. Dabei wird die Autonomie von Individuen und Teams respektiert, sie können selbstorganisiert arbeiten. Macht das Führung obsolet? Wir zeigen anhand von zwei Organisationsmodellen, welche Rolle(n) Führung in der Selbstorganisation haben kann.

Holacracy ist ein Modell der Selbstorganisation, das traditionelle hierarchische Strukturen hinter sich lässt. Es verteilt Verantwortung und Kompetenzen auf vielen Schultern und ermöglicht es, diese immer wieder umzuverteilen, um einem agilen Umfeld gerecht zu werden. Oft wird angenommen, ein solches Modell verabschiede sich gänzlich von Führung. Das sei keineswegs so, sagt Brian Robertson, der Entwickler von Holacracy. In einem Holacracy-Unternehmen werde Führung immer noch gebraucht.

Doch Führung und Management einer Organisation liegen nicht mehr in der Hand einer Führungskraft, sondern werden in festgelegten Rollen und Abläufen strukturiert. In einer holokratischen Organisation hat eine Person keine feste Position samt Stellenbeschreibung. Stattdessen erfüllt jede*r eine oder mehrere Rollen. Diese werden über ihren Zweck, einen konkreten Handlungsbereich und Aufgaben, mit welchen sie ihren Zweck erfüllen sollen, definiert.

Dabei ist für alle transparent, wer gerade welche Rollen innehat. Außerdem können sich Rollenbesetzung und Rollenbeschreibung verändern. Dahinter steht der Gedanke, dass Menschen die Perspektive einer Rolle einnehmen und diese ausfüllen können, ohne mit ihr zu verschmelzen. Es herrscht Rollen-Autonomie, jede*r ist dazu befugt, eigenständig zu entscheiden, wie eine Rolle am besten ausgefüllt werden kann. Anstatt sich das Einverständnis einer Managerin oder eines Managers zu holen, orientieren sich bei Holacracy alle an der Holacracy-Verfassung und dem Purpose, dem Sinn und Zweck der Organisation. So ist sichergestellt, dass die Autonomie nicht im Chaos endet.

Verschiedene Rollen schließen sich zu Teams, sogenannten Kreisen, zusammen, um in einer kleineren Einheit einen gemeinsamen Zweck zu erfüllen. In regelmäßigen Strategie- und Steuerungstreffen stellen die Kreise sicher, dass alle Mitglieder ihre Aufgaben bestmöglich erfüllen können. Sie haben immer einen übergeordneten Elternkreis, mit dem sie über zwei Führungsrollen verbunden sind. Beide Rollen sitzen sowohl im Elternkreis als auch im Kindkreis.

Die individuelle Freiheit, mit der jede*r in einer holakratischen Struktur arbeiten kann, wird durch klar definierte Rollen ermöglicht, innerhalb derer der bzw. die Inhaber*in die Entscheidungsfreiheit hat, wie der Zweck der Rolle erreicht wird. Die anfallenden Aufgaben werden eindeutig zugeordnet. Jeder Kreis bestimmt selbst darüber, welche und wie viele Rollen er benötigt und kann bei Bedarf immer neue Rollen hinzufügen. Von Beginn an ist er jedoch mit vier Standardrollen ausgestattet, auf die sich die Führungsaufgaben bei Holacracy aufteilen.


Der Lead Link

hat den Überblick über Purpose, Ziele und Strategien eines Kreises. Er oder sie legt Prioritäten fest und passt Ziele an, wenn sich z.B. im übergeordneten Kreis Änderungen ergeben. Damit vertritt der Lead Link die Interessen des übergeordneten Kreises und bietet den anderen Rollen im eigenen Kreis Orientierung. Im Gegensatz zu einer oder einem klassischen Manager*in darf der Lead Link aber den anderen Mitgliedern des Kreises nicht sagen, was sie zu tun haben. Er oder sie hat zunächst weitreichende Kompetenzen, allerdings kann der Kreis diese auf andere Rollen im Kreis übertragen. Beispielsweise besetzt der Lead Link die Rollen und ist, wenn sich herausstellt, dass Rolle und Person nicht zusammenpassen, verantwortlich dafür, die Rolle neu zu besetzen. Diese Aufgabe kann aber aus der Rolle des Lead Links herausgelöst und durch Wahlen oder andere interne Prozesse ersetzt werden.


Der Rep Link

ist die Schnittstelle zum übergeordneten Elternkreis, er oder sie gibt Einblicke in den eigenen Kreis und vertritt dessen Interessen. Das wird etwa relevant, wenn es im Kreis zueiner Spannung kommt, deren Bearbeitung die aktuellen Befugnisse des Kreises überschreitet, weil sie beispielsweise etwas mit einem Projekt eines anderen Kreises zu tun hat. Somit kann der Rep Link in einem Interessenkonflikt mit dem Lead Link stehen, der die Interessen des übergeordneten Kreises in den eigenen Kreis trägt. Die Rolle des Rep Links und die Rolle des Lead Links können also nicht von ein und derselben Person besetzt werden.


Der Facilitator

leitet alle Kreis-internen Meetings an. Diese Rolle existiert nur während der Meetings und die Person, die sie innehat, nimmt mit ihr eine neutrale Haltung ein. Der Facilitator ist dafür verantwortlich, dass alle Regeln der Verfassung eingehalten werden. Der Lead Link kann diese Rolle nicht einnehmen, da in Meetings - die in der Holakratie der Dreh- und Angelpunkt der Organisation sind - sonst zu viel Macht in einer Person konzentriert wäre.


Der Secretary

ist fürs Mitschreiben und Dokumentieren innerhalb der Meetings zuständig. Die Rolle kann nicht von der gleichen Person besetzt werden wie die Facilitator-Rolle, da das die Meetings immens verlangsamen würde. Der Secretary legt alle Meetings des Kreises fest. Er oder sie arbeitet bei Meetings eng mit dem Facilitator zusammen. Sollte unklar sein, ob ein Vorgehen der Holakratie-Verfassung entspricht, ist es Aufgabe des Secretary, die Verfassung auszulegen. Die Ergebnisse der Meetings macht der Secretary allen zugänglich, damit sich auch abwesende Kreis-Mitglieder und Mitglieder anderer Kreise informieren können.



SCRUM

Scrum ist eine Methode des agilen Projektmanagements aus der Software-Entwicklung. Sie erlaubt es, ein großes Projekt in kleinere Einheiten zu unterteilen: in zwei- bis vierwöchige Sprints. Dank der häufigen Iterationen soll es möglich sein, sich schnell neuen Anforderungen und Umständen anzupassen und Zwischenergebnisse zu testen.

Führungsfunktionen werden bei Scrum auf den Schultern von drei verschiedenen Rollen verteilt: dem Product Owner, dem Entwicklerteam und dem Scrum Master. Sie beginnen den Prozess gemeinsam in einem Sprint Planning Meeting. Hier wird festgelegt, was im nächsten Sprint vom Team bearbeitet werden kann, Prioritäten gesetzt und Arbeitspakete geschnürt.

Dann geht es los. Im Daily Scrum bespricht sich das Entwicklerteam täglich 15 Minuten und plant den Ablauf des kommenden Tages. In einem Sprint Review wird das Ergebnis des Sprints am Ende überprüft und Feedback von allen relevanten Stakeholdern eingeholt. Darauf folgt die Sprint Retrospektive, in der evaluiert wird, was im zurückliegenden Arbeitsschritt gut lief und was weniger gut, um zukünftige Sprints zu verbessern.


Der Product Owner

ist dafür verantwortlich, das Projekt klar zu beschreiben, damit das Team genau versteht, worauf es hinarbeitet.Wie das Projekt aussieht, beschreibt der Product Owner mit Wissen über die Nutzergruppe. Diese Anforderungen priorisiert er oder sie im Product Backlog. Ganz wichtig ist es, dem Team eine motivierende und klare Vision vorzustellen, dabei mit allen Stakeholdern in Kontakt zu sein und den Markt im Blick zu haben. Am Ende eines Sprints akzeptiert der Product Owner das Ergebnis des Teams oder verwirft es.


Das Entwicklerteam

arbeitet selbstorganisiert an der Verwirklichung des Projekts. Es weiß selbst am besten, wozu es fähig ist und entscheidet daher eigenständig, in wie vielen Sprints es die vom Product Owner formulierten Produkteigenschaften erarbeiten kann. In einem Sprint Backlog, basierend auf dem Product Backlog, legt es fest, welche Anforderungen es im aktuellen Sprint bearbeiten wird. Es darf im Rahmen der Scrum-Leitlinien alles tun, was nötig ist, um das Sprint-Ziel zu erreichen.


Der Scrum Master

leitet den Prozess und unterstützt das Team. Er oder sie sorgt dafür, dass das Team gut arbeiten kann - frei von allen inneren und äußeren Störungen. Als Experte oder Expertin und gute*r Kommunikator*in ist der Scrum Master für die Einhaltung der Regeln und die Optimierung von Scrum im Unternehmen zuständig. Er oder sie leitet das Sprint Planning Meetingund ist für die Vorbereitung des Sprint-Reviews zuständig.

Möchte der Product Owner während eines laufenden Sprints neue Anforderungen an das Team stellen, ist es Aufgabe des Scrum Masters, das zu verhindern. Gibt es Konflikte innerhalb des Teams, hilft der Scrum Master dabei, sie zu lösen. Er oder sie schafft die Rahmenbedingungen für das agile Arbeiten des Teams und stellt sicher, dass es das Ziel eines Sprints nicht aus den Augen verliert. Dabei geht es darum, dem Team so viel Freiheit wie möglich zu lassen und auch zu akzeptieren, wenn es Entscheidungen trifft, die nicht in seinem oder ihrem Sinne sind.


Holacracy und Scrum sind zwei Modelle der Selbstorganisation, die auf Verantwortungsverteilung, Transparenz und Vertrauen basieren. Es gibt keine*n Manager*in mehr, die oder der vorschreibt, wie eine Aufgabe auszuführen ist. Stattdessen arbeiten alle in der Organisation oder am Projekt weitgehend selbstständig. Es wird klar definiert, was Führung bedeutet, welchen Zweck sie erfüllt und mindestens genauso wichtig: welchen nicht.

Zum Original