Wer in diesen Tagen ein wenig über den Scrum-Tellerrand hinausblickt und sich mit Organisationsformen in Unternehmen im allgemeinen beschäftigt, wird recht schnell auf den relativ neuen Begriff »Holacracy« stoßen. Dahinter verbirgt sich ein System zur Selbstorganisation in Unternehmen und Organisationen (was selbstverständlich kein neues Konzept ist). Holacracy versieht dies jedoch mit einem System und Regeln. Für uns in der Agilen Welt stellt sich die Frage, wie weit wir schon in diese Richtung gehen, ob sich Scrum und Holacracy miteinander verbinden lassen, und ob das überhaupt sinnvoll ist.
Um uns eine Meinung bilden zu können, müssen wir zunächst natürlich einen genaueren Blick auf dieses Konzept werfen, auch wenn ich um Verständnis bitten muss, dass ich hier nicht zu sehr ins Detail gehen möchte. Es geht im Moment lediglich darum, einen ersten Eindruck zu gewinnen.
Diese Form der Selbstorganisation geht davon aus, dass klassische Jobbeschreibungen in Unternehmen die Wirklichkeit nur unzureichend abbilden können, dass sich Anforderungen stetig ändern (wer die Prinzipien der Agilen Softwareentwicklung kennt, wird jetzt aufhorchen), und dass Entscheidungen dort getroffen werden sollten, wo sie auch angefordert werden, nämlich im Team. Aus diesem Grund verabschiedet sich Holacracy vom klassischen hierarchischen Denken, in dem Rollen fest vergeben werden und Entscheidungen top-down getroffen werden. Stattdessen können beliebige Personen im Unternehmen beliebige Rollen übernehmen, die sie selbst definieren. Dieser Vorgang ist jedoch vollkommen transparent und wird nicht von einer einzelnen Person entschieden. Vielmehr macht man einen Vorschlag, wer eine Rolle übernimmt und wie diese auszusehen hat, und bespricht diesen mit den Personen, die betroffen sind. Eine Rolle kann auch weitreichende Entscheidungsbefugnisse beinhalten.
Ein Beispiel aus der Softwareentwicklung: Ein Entwickler möchte die Rolle eines Releasemanagers übernehmen und bespricht sich mit seinen Kollegen, was das alles umfasst. Man kommt zu dem Schluss, dass der RM darüber entscheiden sollte, wann ein Stand (aus technischer Sicht) ready-to-release ist. Dieser Kollege spricht sich mit den Product Ownern und den Lead Developern ab, beschreibt seine Rolle und seinen Wunsch, diese Rolle zu übernehmen. Wenn niemand Einwände hat, ist der Kollege zukünftig neben seiner Tätigkeit als Entwickler auch Releasemanager.
Diese Rollen und Verantwortlichkeiten sind nicht in Stein gemeißelt und mit Blut besiegelt. Im Gegensatz zu klassischen Jobbeschreibungen können sie sich verändern und sind sogar darauf ausgelegt, dass sie nicht bis in alle Ewigkeit Bestand haben. Daher ist es erforderlich, dass auch die Rollen und Rollenbeschreibungen einer wiederkehrenden Überprüfung unterzogen sind. Ändern sich die Anforderungen, muss man die Rollen verändern, zusätzliche schaffen oder auflösen.
Holacracy im Unternehmen hat weit reichende Konsequenzen. Man kann das nicht in einer einzelnen Abteilung ausprobieren. Dieses Konzept muss über alle Abteilungen bis hinein in die Geschäftsführung greifen, weil sich Entscheidungsprozesse vollkommen verändern. Wir können gern über das Thema reden – sprechen Sie mich an.
Wenn Sie die Agile Welt kennen und sich etwas tiefer in das Thema Holacracy einlesen, werden Sie viele Parallelen entdecken. Allem liegen sehr ähnliche Gedanken zugrunde, etwa die Annahme, dass klassische top-down Hierarchien ungeeignet sind, die Anforderungen in einem Unternehmen abzubilden. Auch die Fokussierung auf Veränderung ist beiden gemein.
Wenn wir z.B. Scrum betrachten, entdecken wir jedoch klare Jobbeschreibungen und feststehende Rollenzuordnungen. Wir haben einen Product Owner und einen Scrum Master, und in jedem Buch werden Sie im ersten Kapitel lesen können, was diese beiden zu tun haben und was deren Aufgaben und Verantwortlichkeiten sind. Hier stoßen wir nur wieder an eine Grenze von Scrum. Ein Unternehmen besteht nicht nur aus dem Entwicklungsteam. Entscheidungen werden über Abteilungsgrenzen hinaus gefällt. Die Entwicklung selbst ist komplexer als nur Entwickler – Product Owner – Scrum Master. Scrum liefert keine Antworten auf diese Fragen, will das auch nicht. Dennoch existieren diese Fragen in einem Unternehmen. Selbst innerhalb einer Entwicklungsabteilung gibt es unterschiedlichste Rollen und Anforderungen (denken wir nur an Tester, Releasemanager, Architekt usw.). Viele dieser Rollen ändern sich nur langsam, einige sind jedoch einem stetigen Wandel unterworfen oder werden nur für eine kurze Zeit benötigt.
Denken wir einmal: Es wird eine größere Migration benötigt, z.B. auf eine neue Ruby-Version. Wer kümmert sich darum und treibt das Thema? Wenn wir nur mit einem Entwicklungsteam arbeiten, kann der Product Owner die dafür notwendigen Schritte ganz normal ins Backlog einpflegen. Arbeiten wir jedoch mit mehreren Teams und Dinge müssen über Teamgrenzen hinweg bearbeitet werden, kann ein möglicher Weg sein, ein kleines temporäres Team zu bilden. Wer macht da mit, und wer agiert in diesem Zusammenhang federführend? Kümmert sich der Chief-PO um diese Sache, oder ist ein erfahrener Entwickler besser geeignet?
Man kann diese Frage beantworten, indem man den Hierarchien im Unternehmen folgend eine Entscheidung trifft und diese »nach unten« durchreicht. Alternativ – und das wäre der Holacracy-Ansatz – entscheidet das Team selbst, wer in dieser Frage Verantwortung übernimmt und wie alles organisiert sein sollte, weil die direkt betroffenen Personen eine solche Entscheidung aufgrund ihrer Kenntnisse und Erfahrungen viel besser treffen können.
An diesem Beispiel kann man schon sehen, dass beide Welten recht gut miteinander zu vereinbaren sind. Es ist kein Gegensatz, auf der einen Seite von festen Rollen wie Product Owner und Scrum Master zu sprechen, auf der anderen Seite aber zu akzeptieren, dass es viele weitere Rollen und Entscheidungen gibt, die von Scrum allein nicht abgedeckt werden können.
An dieser Stelle muss ich jedoch warnen: Holacracy eignet sich nicht als Experiment, und es ist auch nicht möglich, weitreichende Selbstbestimmung in einem isolierten Bereich eines Unternehmens einzuführen. Rollen reichen sehr oft über Abteilungsgrenzen hinaus. Es gilt also Ganz oder Garnicht.
Auch ist eine schrittweise Einführung nur extrem schwer möglich. Wo wollen Sie die Grenze ziehen? Die Entscheidung pro Holacracy muss keine endgültige sein, aber sie muss nicht nur von der Geschäftsführung mitgetragen werden, sie muss dort auch vorgelebt werden. Die Entscheidungsgewalt innerhalb eines Unternehmens verschiebt sich mit Holacracy noch viel mehr als mit Scrum.
