Zur Geschichte
Vor der Einführung von Holacracy im Januar 2016 hatten wir bereits ein eigenes Corporate Governance System entwickelt. Es basierte auf der agilen Projektmanagement Methode Scrum, die wir seit 2010 "atmen". Mit anderen Worten, wir hatten die Rollenstruktur und Arbeitsorganisation à la Scrum im gesamten Unternehmen abgebildet. Dies betraf das Management unserer Kundenprojekte, aber auch das Management unserer “Zentrale Dienste”. Ich erinnere mich, dass ich die Rolle des Scrum Master im Büro Lausanne hatte. Meine Hauptaufgabe war es, einen Rahmen zu schaffen, in dem sich Liipers in Lausanne ohne Hindernisse arbeiten. Ich führte einen "User Stories"-Backlog für die Entwicklung unseres Büros und wir haben die Verarbeitung dieser Stories in "Sprints" organisiert. Unser Admin-Team hatte auch ein physisches Scrum Board, das kontinuierlich alle aktuellen und kommenden Aufgaben aufzeigte.
Dieses agile Governance-System "à la Liip" hat einige Jahre gut funktioniert. Bis es zu restriktiv wurde. Es war für das Projektmanagement gedacht, nicht für die internen Prozesse des Unternehmens. Wir mussten das System laufend/immer wieder anpassen, damit es funktionierte. Bei 100 Mitarbeitenden (davon 6 Führungskräfte, weil wir damals eine Hierarchie hatten), mussten wir uns den Tatsachen stellen: Diese Version von Scrum für Liips Governance war nicht mehr effizient genug.
Wie entwickeln wir die Unternehmensorganisation so, dass sie unser Wachstum nachhaltig absorbiert (~20% mehr Mitarbeitende pro Jahr)?
Zwei Optionen kamen in Frage:
- Die Führungsstufen erweitern: Entweder das Managementteam vergrössern oder ein Mittelmanagement einführen.
- Recherchieren, um ein radikal anderes System zu finden.
Für uns stand fest, dass hierarchische Systeme zum Scheitern verurteilt sind, somit wurde es die zweite Option.
Und dann kam Holacracy
Die Recherche führte uns auch zu Frédéric Laloux’ Buch "Reinventing Organizations" und zu Holacracy. Die expliziten Regeln in der Verfassung, der klare Open Source Bezug und die Skalierbarkeit faszinierte uns. Das zehn Jahre alte System Holacracy hatte bereits interessante Referenzen (darunter Zappos mit 1500 Mitarbeitern).
Beeinflusst Holacracy die Arbeit, die ich mit meinen Kunden mache ?
Wenn wir andere Unternehmen coachen,die Holacracy oder Selbstorganisation einsetzen wollen, stellt sich oft die Frage:
Muss ich den Kunden beibringen, wie Holacracy funktioniert?
Die Antwort ist nein. Ich glaube, dass die meisten unserer Kunden die Änderung nicht bemerkt haben. Seit 2010 steuern wir alle unsere Projekte mit Scrum. Holacracy ist ein Instrument, das wir nur intern einsetzen, zur Unternehmensführung.
Scrum und Holacracy : eine Symbiose
Der Einsatz von zwei hochgradig integrierten Arbeitsmethoden vereint in einem Unternehmen erscheint gefährlich. Wenn ich zurückblicke, sehe ich, dass sie sehr gut harmonieren. Unser Organigramm zeigt, dass alle Projektteams die Kernrollen von Scrum geschaffen haben: Scrum Master (SM), Product Owner (PO). Der Zweck und die Verantwortlichkeiten von SM und PO wurden dem Scrum-Leitfaden entnommen. Die Teams schufen auch die zusätzlichen Rollen, die sie benötigten: Frontend/Backend/Fullstack Developers, DevOps, UX Designer, etc. Alle diese Rollen arbeiten weiterhin mit Scrum in Kundenprojekten zusammen und sind in der Holacracy-Struktur zu finden.
Vergleich aller iterativen Prozesse der beiden Verfahren:
| Processes | Purpose | Who is invited | Scope |
|---|---|---|---|
| Holacracy | |||
| Governance | Spannungen betr. Struktur bearbeiten | Mitglieder des Kreises (Liipers) | Struktur des Kreises / der Firma |
| Tactical (triage) | Operative Spannungen bearbeiten | Mitglieder des Kreises (Liipers) | Projekte innerhalb des Kreises / der Firma |
| Scrum | |||
| Backlog grooming | Produkt Backlog revidieren, damit er für die nächsten Sprints bereit ist | Scrum team (Liipers & Kunden) | Kundenprojekte |
| Sprint Planung | Definieren, was während dem nächsten Sprint gemacht wird | Scrum team (Liipers & Kunden) | Kundenprojekte |
| Sprint review | Demonstrate what has been done in the sprint that is ending | Scrum team (Liipers & Kunden) | Kundenprojekte |
| Sprint Retrospektive | Prozess und Struktur des Projektes prüfen und optimieren | Scrum team (Liipers & Kunden) | Struktur/Funktionalität des Scrum Teams |
Jeder dieser Prozesse hat einen spezifischen Zweck und wird für den reibungslosen Ablauf der Projekte und für die kontinuierliche Verbesserung benötigt. Wir stellen jedoch fest, dass es zu einer Überschneidung zwischen den Holacracy-Prozessen und der Scrum-Retrospektive kommen kann.
Die selbstorganisierten Teams (oder Kreise) bei Liip beahlten die Retrospektiven in ihrer Form. Nicht alle Themen (oder "Spannungen"), die sich aus der Retrospektive ergeben, werden behandelt. Spannungen in Bezug auf interne Probleme werden bei der nächsten taktischen Holacracy-Sitzung des betreffenden Teams aufgenommen. Dieses Treffen ist oft kurz nach der betreffenden Retrospektive geplant.
Macht weiterhin Retrospektiven!
Nach 3 Jahren Praxis finde ich es nützlich, Retrospektiven "à la Scrum" zu pflegen: Durch Gruppeninteraktion ermöglichen sie es, Spannungen an die Oberfläche zu bringen, die wir allein nicht unbedingt identifiziert hätten.
Meine Empfehlung ist: Wenn du den Weg Richtung Holacracy einschlägst, während du Scrum praktizierst, mach weiterhin Retrospektiven. Und stelle sicher, dass du die soliden Prozesse von Holacracy nutzt, um Spannungen zu bearbeiten!
Was ist deine Erfahrung? Was denkst du dazu? Ich freue mich, deinen Kommentar zu lesen!