Teamübergreifende Abstimmung – Welche Entscheidungsprozesse nutzen Communities of Practice?

Konsent harmoniert sehr gut mit Selbstorganisation von Teams und den Scrum-Prinzipien transparency, inspect and adapt.

Foto: Gaby Stein – pixelio.de

Von Birgit Mallow

In Teil I habe ich Repräsentanten-Konstrukte beschrieben, über die sich viele agile Teams abstimmen. Neben dem Scrum of Scrums (SoS) haben sich Communities of Practice (CoP) bewährt, in denen sich Team-Vertreter mit gleichen Themen treffen. Inhaltlich geht es dabei um Erfahrungsaustausch sowie die Klärung von Abhängigkeiten oder die Abstimmung von Themen, die potentiell für alle Teams von Interesse sind.

Entscheidungsprozesse in CoPs

Die Art und Weise, wie in den CoPs gearbeitet wird und vor allem wie Entscheidungen getroffen werden, kann in selbstorganisierten CoPs ganz unterschiedlich sein. Nach meiner Erfahrung ist das praktizierte Verfahren nicht unerheblich für die Effizienz eines CoPs und die Zufriedenheit aller Beteiligten. Dazu zählen natürlich auch die agilen Teams, die ihre Vertreter in die CoPs entsenden.

Manche CoPs starten mit dem Anspruch, Entscheidungen nach dem Konsens-Prinzip zu treffen.

Das heißt, es wird gemeinsam diskutiert und überlegt mit dem Ziel, eine Lösung zu finden, die alle Team-Vertreter befürworten. Die gute Absicht dabei: Die Lösung soll möglichst die Beste und zugleich möglichst die Beste für alle Teams sein, die von der Entscheidung betroffen sind. Gründe für das Vorgehen können auch sein, dass die agile Arbeitsweise generell noch in der Einführung und für viele Mitarbeiter relativ neu ist; vielleicht kennen sich auch die Team-Vertreter noch nicht so gut und wollen sich in der Startphase des CoP erstmal freundlich „beschnuppern“. Auch die Unternehmenskultur spielt eine Rolle. In manchen Organisationen ist es „guter Ton“, Konflikte zu vermeiden; in anderen Organisationen wollen die Team-Vertreter aber auch in ihren Teams und im CoP eine Harmonie erzeugen, die sie im übrigen Unternehmensalltag bisher eher vermissen. In der Praxis führt Konsens-Prinzip nach meiner Erfahrung meistens nicht zur besten, sondern – wenn überhaupt – zur zweit- oder drittbesten Lösung. Es passiert das, was wir aus vielen Gremien kennen: Da werden faule Kompromisse ausgehandelt oder aus Harmoniebedürfnis vorschnell wichtige Argumente aufgegeben. Oder es wird eben endlos diskutiert, weil immer irgend einem Team-Vertreter noch ein Aspekt einfällt, der vor der finalen Entscheidung zu behandeln wäre. Diese Strategie eignet sich nicht nur für die fast endlose Suche nach der besten Lösung, sondern auch zum geschickten Blockieren des gesamten CoPs. Für die Teams, die darauf warten, dass ihr Vertreter eine Entscheidung mitbringt, ist das natürlich unbefriedigend.
Es gibt sicher CoPs, die mit Konsens sehr gut zurechtkommen. Auch kann ein erfahrener Scrum Master als Moderator das CoP bei der Konsens-Findung mit Fragen, Spiegeln des Diskussionsverlaufs und mit Time-Boxing gut unterstützen. Ein wirklich guter Scrum Master wird das CoP aber schnell davon überzeugen, dass Konsens nicht der beste Weg ist.

Auch weit verbreitet ist die demokratische Abstimmung

In der Diskussion werden Sichtweisen und Argumente ausgetauscht und schließlich wird mit einer Mehrheit die Lösung gekürt. Die Entscheidung basiert also auf den Interessen und Sichtweisen der Mehrheit. Meistens ist die demokratische Abstimmung schneller bewerkstelligt als eine Konsensfindung. Für viele Teams ist das ein gutes Vorgehen.
Zur Schieflage kommt es aber, wenn wichtige Argumente einzelner Team-Vertreter zu wenig Gehör finden. Möglicherweise ist ja auch nur eine Minderheit der Teams von den negativen Konsequenzen einer CoP-Entscheidung betroffen. Manche CoPs führen deshalb zusätzlich das Veto-Prinzip ein. Wer gravierende Bedenken gegen einen Vorschlag hat, kann einen Mehrheitsentscheid mit seinem Veto verhindern. Das führt dann im CoP entweder zur Blockade oder zu einer erneuten Diskussion bis mehrheitsfähige neue Lösung entwickelt ist. Und es gibt auch das Phänomen, dass geschickte Team-Vertreter im Vorfeld in bilateralen Gesprächen die erforderlichen Mehrheiten schmieden, um ihren Vorschlag im CoP durchzusetzen. Das ist dann zwar „politisch geschickt“, aber für das CoP sowie alle betroffenen Teams nicht unbedingt nützlich. Und selbst wenn der Vorschlag objektiv sachlich ein sehr guter war, besteht die Gefahr, dass sich die Team-Vertreter und Teams der überstimmten Minderheit hintergangen fühlen.
Auch beim Einsatz demokratischer Abstimmung ist es also hilfreich, wenn CoPs durch einen erfahrenen Scrum Master moderiert werden, der zu Fairness, Ehrlichkeit und Transparenz anhält.

Derzeit noch nicht so weit verbreitet, aber generell sehr nützlich für effektive Gremienarbeit ist das Konsent-Prinzip

Deshalb ermutige ich Teams und CoPs gerne dazu, dieses Verfahren für sich auszuprobieren.
Konsent kehrt die gewohnte Form des Entscheidungsprozesses quasi um, denn es wird nicht nach der Zustimmung gefragt, sondern nach einem gravierenden Einwand, der zu begründen ist. Eine Grundannahme im Konsent ist also, dass jeder eingebrachte Vorschlag schon automatisch angenommen ist, wenn nicht etwas wirklich Schwerwiegendes dagegen spricht. Zugleich wird jeder Einwand als wertvoller Beitrag, als ein Geschenk an die Gemeinschaft betrachtet – das ist die zweite Grundannahme: Jeder Einwand hat eine gute Absicht. Eine dritte Grundannahme ist, dass es nicht notwendig ist, die beste Lösung zu finden, sondern überhaupt eine Lösung zu haben und mit dieser wieder einen Schritt weiter voranzukommen. Damit erhält im Konsent nicht automatisch die Mehrheit die Macht, sondern die Position jedes Einzelnen wird gestärkt und zugleich eine Blockade verhindert.
Wie funktioniert dieses Konsent-Prinzip, das in der Soziokratie entwickelt und auch von Holakratie übernommen wurde, ganz konkret?
Will ein CoP mit Konsent entscheiden, funktioniert das ebenfalls am besten mit einem erfahrenen Moderator. Die Entscheidungsfindung durchläuft dabei folgende Schritte:

  • Ein Vorschlag oder Antrag wird von einem Team-Vertreter vorgestellt und kurz erläutert. Im Architektur-CoP könnte es sich bspw. um eine grundlegende Architektur-Entscheidung handeln, die sich eines der agilen Teams als gute Lösung für die eigene Arbeit überlegt hat, die aber auch Konsequenzen für die Arbeit vieler oder sogar aller agilen Teams hat.
  • Im nächsten Schritt dürfen alle anderen Team-Vertreter im CoP dem Vorschlaggeber reihum Verständnisfragen stellen. Der Vorschlaggeber beantwortet die Fragen jeweils sofort.
  • Dann gibt es eine Runde zur Meinungsäußerung, damit alle CoP-Mitglieder gemeinsam einen Überblick darüber erhalten, wie jeder über den Vorschlag denkt. Es schließt sich eine zweite Meinungsrunde an, denn das Hören aller Sichtweisen in der ersten Runde kann ja bei jedem Mitglied zu einer Meinungsänderung führen.
  • Daran schließt sich eine Runde an, in der alle Team-Vertreter gefragt werden, ob sie einen schwerwiegenden Einwand haben. „Gefällt mir nicht“ oder „Finde ich nicht gut“ zählen dabei nicht als Einwände im Sinne des Konsent. Ein gravierender Einwand zeigt vielmehr auf, dass der Vorschlag, so wie er jetzt vorliegt, daran hindert das vereinbarte Ziel zu erreichen und damit zu einem Schaden für die Organisation oder für Teile davon führen würden.
    Wenn es keinen gravierenden Einwand gibt, ist der Vorschlag automatisch angenommen.
  • Gibt es einen echten und begründeten Einwand, bspw. in unserem Architektur-CoP die Konsequenz, dass einzelne Teams künftig erhebliche Mehrarbeit haben oder bereits geplante Arbeiten neu konzipieren müssen, dann gibt es einen weiteren Schritt:
    Der Moderator fragt zunächst den Einwandgeber, dann den Vorschlaggeber,  ob er eine Idee hat, wie der Einwand in den Vorschlag integriert werden kann. Wenn dann noch etwas offen ist, geht die Frage an alle Team-Vertreter weiter. Idealerweise gelingt die Formulierung eines neuen, integrierten Vorschlags innerhalb des laufenden CoP-Meetings, manchmal muss das aber auch bis zum nächsten Meeting vorbereitet werden.
    Für den modifizierten Vorschlag werden dann die o.g. Schritte nochmal durchlaufen.
  • Hat ein Entscheidungsvorschlag Konsent erhalten, wird dieser normalerweise mit einem „Ablaufdatum“ versehen. Spätestens zu diesem Termin wird die Entscheidung geprüft und Lessons Learned abgeleitet. Und dann wird ein modizierter Vorschlag vorgestellt oder die bisherige Entscheidung verlängert.
  • Sind CoPs mit dem Konsent-Prinzip gut vertraut, suchen Vorschlaggeber im Vorfeld bereits das Gespräch mit den anderen Team-Vertretern, um etwaige Einwände schon vor einem CoP-Meeting konstruktiv integrieren zu können. Dann geht die Entscheidungsfindung im CoP sehr schnell. Und doch hinterlässt sie bei den Beteiligten kein „Geschmäckle“ wie dies oft bei der „politischen Mehrheitsbildung im Vorfeld“ beim demokratischen Verfahren eintritt.

Das Konsent-Prinzip braucht etwas Übung, Disziplin und einen erfahrenen Moderator. Ungewohnt ist vor allem, dass für die Konsent-Entscheidung nicht diskutiert wird; die Teilnehmer sprechen vielmehr nacheinander im Kreis. Das führt zu einer hohen Transparenz, welche verschiedenen Sichtweisen und Meinungen zu einem Vorschlag bestehen. Und es ist sehr wertschätzend allen Teilnehmern gegenüber, denn jeder kommt zu Wort.

Ist Konsent erst einmal vertraut, führt es gerade in agilen Organisationen rasch zu einem guten Arbeitsfluss von Teams und CoPs. Denn es gilt noch eine vierte Grundannahme – alle Vorschläge dürfen immer weiterentwickelt werden: Hat jemand die Idee für eine noch bessere Lösung, bringt er diesen Vorschlag selbstverständlich ins CoP ein. Kein Vorschlag wird mit dem Argument „Das haben wir doch kürzlich erst entschieden…“ abgeblockt. Und wenn nach dem CoP-Meeting in einem Team ein wichtiges Hindernis gefunden wird, darf aus diesem Team heraus jederzeit der Konsent wieder zurückgezogen werden.

Damit harmoniert Konsent sehr gut mit selbstorganisierten, soweit möglich autonom entscheidenden Teams. Und es passt zu dem adaptiv-inkrementellen Vorgehen und den Prinzipien transparency, inspect and adapt von Scrum.

CoPs, die eine gute Reife an Selbstorganisation erreicht haben und routiniert mit Konsent arbeiten, können sich mit dem gleichen Verfahren auch einen CoP-Moderator selbst wählen: Jeder Team-Vertreter kann einen Kollegen aus der CoP-Runde als Moderator für eine fest definierte Zeit vorgeschlagen. Und wenn weder Derjenige selbst noch ein anderer Team-Vertreter einen stichhaltigen Einwand dagegen hat, gilt der Vorschlag als angenommen. Genauso wird in den agilen Teams dann auch der Team-Vertreter bestimmt, der das Team im CoP vertritt.

Weitere Arbeitsformen teamübergreifend

Neben den Konstrukten mit Team-Vertretern gibt es für ausgewählte Situationen natürlich auch Arbeitsformen, die die Mitarbeiter aus allen agilen Teams eines Entwicklungsvorhabens oder Unternehmens direkt einbeziehen: Hier kommen Großgruppenformate zum Einsatz.

  • Beliebt ist das bekannte Großgruppenformat Open Space mit dem Prinzip „Das ganze System in einem Raum“. Auch mehrere hundert Mitarbeiter können hier in wenigen Stunden konzentriert und parallel an selbst gewählten Themenstellungen arbeiten. Sinnvolle Einsatzszenarien können bspw. sein: Zusammenkunft aller Entwickler einmal jährlich oder jeweils nach einem großen Release, um verschiedene grundsätzliche technische und/oder fachliche Fragen für die Zukunft tiefer zu durchdringen sowie „Aspekte über den Tellerrand“ hinaus zu betrachten.
  • Eine stark strukturierte Großgruppenkonferenz ist das Release Planning aus dem Scaled Agile Framework (SAFe). Es wird z.T. auch unabhängig vom Framework SAFe eingesetzt. Im Release Planning sind alle agilen Teams beteiligt, die gemeinsam an einem Produkt entwickeln. Das Release Planning dient der Synchronisation der Teams und Team-Mitglieder vor dem nächsten Entwicklungszyklus. Die Teams sichten in der Konferenz simultan die Anforderungen, die für das nächste Release vorgesehen sind. Sie entwickeln ein möglichst einheitliches Verständnis von Produkt und Release-Ziel und zeigen für die Anforderungen Risiken und Abhängigkeiten zu anderen Teams auf. Jede Stunde kommen Team-Vertreter zusammen, um sich zu den Findings auszutauschen und das Vorgehen dazu abzustimmen. Die intensive Zusammenarbeit und der enge Austausch zwischen den Teams ebnet Kommunikationswege und das trägt oft für die gesamte Release-Entwicklungszeit.

Eure Birgit Mallow

Autor: Birgit Mallow

Ich bin Dipl. Informatikerin und Organisationsentwicklerin und seit rund 20 Jahren als Beraterin in renommierten Unternehmen verschiedener Branchen tätig. Meine berufliche Leidenschaft ist, Organisationen und Menschen in Veränderungsprozessen zu begleiten und zu unterstützen (Change Facilitation). Meine Arbeit als Organisationsentwicklerin hat diese fachlichen Schwerpunkte: - Agile Methoden / agile Coaching / agile Organisation - Werteorientierte Transformation / Kulturentwicklung - (Agiles) Business Process Management Ein mächtiger Antreiber ist dabei für mich, dass ich zur Gestaltung einer Arbeitswelt beitragen möchte, in der Menschen Freude an der Arbeit haben, den Sinn ihres täglichen Einsatzes erkennen und zugleich sehr wirksam für Wirtschaftlichkeit und den Erfolg ihrer Unternehmen sind.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.