Die meisten Projekte sind zu groß und zu komplex, um von einer Person alleine vollständig erledigt zu werden. Daher bilden sich schon seit vielen Jahren regelmäßig Teams, die gemeinsam Aufgaben erfüllen sollen. Abgesehen von vielen Witzen über Teams (Toll, ein anderer macht’s) sind Teams auch im agilen Kontext unverzichtbar.

Laut Hackman¹J. R. Hackman, Leading Teams: Setting the Stage for Great Performances, 1. Aufl., Harvard Business Review Press, Brighton, 2002. gibt es vier Punkte, die beachtet werden sollen, wenn ein Team gebildet werden soll:

1. Definition des Teamzwecks
2. Zusammenstellung des Teams und Einbettung des Teams in die Organisation
3. Organisation der Arbeit des Teams
4. Erledigung der Arbeit

Anhand der Frage, welche dieser Aufgaben vom Team (bzw. vom Management) übernommen werden, kann der Autonomiegrad eines Teams klassifiziert werden. Diese verschiedenen Autonomiegrade werden in diesem Artikel diskutiert. Dazu sollte angemerkt werden, dass ein Großteil dieses Artikels auf einem hervorragendem Buch von Hoffmann und Roock²J. Hoffmann, S. Roock, Agile Unternehmen: Veränderungsprozesse gestalten, agile Prinzipien verankern, Selbstorganisation und neue Führungsstile etablieren, 1. Aufl., dpunkt.verlag GmbH, Heidelberg, 2018. basiert.

Managergeführtes Team

Ist das Team einzig und allein mit der Erledigung der eigentlichen Arbeit (Punkt 4) betraut, muss der Manager die restlichen Punkte 1-3 übernehmen. Diese Rollenverteilung wird häufig negativ mit dem Ausdruck Taylorismus³Seite „Taylorismus“. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 25. Juni 2018, 17:17 UTC. URL: https://de.wikipedia.org/w/index.php?title=Taylorismus&oldid=178627131 (Abgerufen: 2. August 2018, 14:24 UTC). beschrieben. Typisch für solche managergeführten Teams sind die folgenden Ausprägungen:

• Detaillierte Vorgabe der Arbeitsmethode durch den Manager
• Festlegung des Leistungsortes und des Leistungszeitpunktes durch den Manager
• Durch den Manager extrem detaillierte und zerlegte Arbeitsaufgaben
• Einwegkommunikation vom Manager zu den Teammitgliedern, mit festgelegten und engen Inhalten
• Detaillierte Zielvorgaben durch den Manager bei für einzelne Teammitglieder nicht immer erkennbarem Zusammenhang zum Unternehmungsziel
• Externe (Qualitäts-)Kontrolle

Natürlich gibt es Fälle, in denen eine solche Trennung der ausführenden und planenden Arbeit sinnvoll ist. Im Falle repetitiver, nicht komplexer Aufgaben (zum Beispiel in der Serienfertigung) ist diese Methode seit vielen Jahren etabliert und liefert zuverlässige und verlässliche Ergebnisse. Für solche Aufgaben ist agiles Projektmanagement nicht geeignet. Gleichzeitig kann ein managergeführtes Team auch nicht als agiles Team betrachtet werden, da das Team nicht anpassungsfähig ist. Sämtliche Anpassungen an veränderte Bedingungen müssen stattdessen durch das Management vorgenommen werden.

Selbstorganisierendes Team

Ein selbstorganisierendes Team übernimmt zusätzlich zur Erledigung der Arbeit (Punkt 1) ebenfalls die Organisation derselben (Punkt 2). Dies ist die Mindestvoraussetzung für ein agiles Team, somit kann ab hier von agilen Teams gesprochen werden.

Diese Organisation der Arbeit umfasst drei Teilbereiche. Erstens soll das Team selbst entscheiden, wer wann welche Aufgabe übernimmt. Dazu gehört auch die Überlegung, wie Aufgaben unterteilt werden sollen. Im Scrum-Framework wird hierzu das Sprint Planning genutzt. Zweitens soll das Team den Arbeitsfortschritt selbst überwachen, im Scrum-Framework passiert dies in den Dailies. Drittens ist es Aufgabe des Teams, die eigene Teamorganisation selbst zu verbessern. Das Scrum-Framework nutzt hierzu die Retrospektive.

Es gibt einige Voraussetzungen an ein Team, damit es selbstorganisierend sein kann. Das Team muss zu Beginn meist lernen, die eigene Arbeit zu planen, und für diese Planung die Verantwortung zu übernehmen. Eine besondere Herausforderung ist die Kommunikation durch den Manager. Bei managergeführten Teams wird einfach nur die Arbeitsplanung kommuniziert, aber genau diese Arbeitsplanung soll ja vom Team vorgenommen werden. Stattdessen muss also die Kommunikation auf einer höheren Ebene stattfinden, das heißt, es muss der Teamzweck und der Organisationskontext kommuniziert werden. Dies führt zu einer Transparenz in der Kommunikation, und erfordert ein erhebliches Umdenken. Mögliche Modelle, wie solche Teamzwecke kommuniziert werden können, sind z.B. Visionen im Scrum-Framework, das Management-by-Objectives-Modell, oder das Nordstern-Konzept. Zu all diesen Punkten werde ich separate Artikel verfassen, und dann hier verlinken.

Bisher sprach ich von gestellten Aufgaben. Im agilen Umfeld ist dies eher unüblich, stattdessen werden normalerweise Kundenanforderungen formuliert, zum Beispiel durch User Stories. Diese Orientierung an Kundenbedürfnissen ist fundamental wichtig, wenn ein Team kundenwertoptimierend arbeiten soll. Damit gehört zur Arbeitsplanung, die Bedürfnisse des Kunden in entsprechende Aufgaben zu übertragen, und ist somit ebenfalls Aufgabe des Teams. Eine für den Manager (oder ein Product Owner) sinnvolle Aufgabe ist üblicherweise die Priorisierung der Anforderungen.

Weiterhin muss ein Team in der Lage sein, die Anforderungen vollständig zu erfüllen. Dazu muss ein Team alle relevanten Bereiche abdecken können. Hier eignen sich besonders cross-funktionale Teams. Gleichzeitig weiß das Team häufig selbst am besten, welche Fähigkeiten dem Team noch fehlt. Leider können selbstorganisierende Teams nichts unternehmen, um fehlende Fähigkeiten aufzubauen; der Übergang zum selbstgestaltenden Team ist fließend.

Selbstgestaltendes Team

Selbstgestaltende Teams übernehmen ebenfalls die Aufgabe der Teamzusammensetzung und der Einbettung des Teams in die Organisation.

Zur Teamzusammensetzung gehört die Frage, welche Rollen im Team benötigt werden, welche Personen Teammitglieder sind, und ob Fähigkeiten durch Weiterbildung einzelner Teammitglieder aufgebaut werden müssen. Natürlich erfordert dies auch Kommunikation mit anderen Teilen der Organisation, insbesondere, falls manche Personen von mehreren Teams benötigt werden. Die Organisation von Schnittstellen und der Zusammenarbeit mehrerer Teams fällt nun ebenfalls in den Aufgabenbereich des Teams.

Erneut gibt es einige Voraussetzungen, damit ein Team selbstgestaltend sein kann. Auch hier muss ein Team bereit sein, diese zusätzlichen Verantwortungen anzunehmen, und gecoacht werden, diese Verantwortungen auch bewusst einzusetzen. Außerdem kann es sinnvoll sein, gemeinsam mit dem Team über Budgets zu diskutieren, falls dieses weitere Teammitglieder einstellen möchte.

Je nach verwendetem Framework kann es ebenfalls nötig sein, dass das Team sämtliche Anforderungen eines Kunden auch komplett bearbeiten und erfüllen kann. Dies ist insbesondere bei Scrum der Fall. Wird das Kanban-Framework genutzt, ist diese Vorgabe nicht zwingend, da hier auch Expertenteams erlaubt sind. In diesem Falle muss das Team deutlich mehr Aufwand in die Interaktion mit anderen Expertenteams des Unternehmens investieren. Da hier die Gefahr lokaler Optimierungen besteht, während gleichzeitig das Kundenbedürfnis aus dem Fokus rutscht, ist das Kanban-Framework nur für erfahrene Teams empfehlenswert.

Selbstverwaltendes Team

Selbstverwaltende Teams besitzen die höchste Verantwortung und die höchste Autonomie. Zusätzlich zu den bisher genannten Aufgaben übernehmen selbstverwaltende Teams auch die Definition und Anpassung des Teamzwecks. Dies bedeutet, dass die Teams selbst entscheiden, ob sie existieren, wer ihre Kunden sind, und welche Produktvision sie für diese Kunden erfüllen möchten. Gleichzeitig dürfen selbstverwaltende Teams diese Aspekte jederzeit anpassen, und im Zweifel auch beenden und das Team auflösen.

Auf der einen Seite klingt dies nach Chaos, auf der anderen Seite führt dies zu maximaler Flexibilität der Teams, falls sich Anforderungen schnell ändern sollten. In der Praxis ändern sich Anforderungen meist nicht so schnell, sodass häufig selbstgestaltende Teams ausreichen. Es gibt allerdings zwei Szenarien, in denen selbstverwaltende Teams sinnvoll sein können, und beide beruhen auf zu Beginn nicht genau bekannten Anforderungen.

Das erste Szenario ist das Startup. Hier wird davon ausgegangen, dass zu Beginn eines Startups nicht klar ist, welche Kunden mit welchen Anforderungen bedient werden sollen. Stattdessen soll hier durch direkte und dauerhafte Interaktion mit dem Markt herausgearbeitet werden, welche Kundengruppen überhaupt existieren, welche Anforderungen diese besitzen, und wie diese durch eine Produktvision erfüllt werden sollen.

Das zweite Szenario ist die Horizont-3-Entwicklung. Eigentlich ist dieses Szenario nicht wirklich unterschiedlich vom Startup, da Startups im dritten Horizont beginnen (sollten). Dieses Szenario wird trotzdem getrennt aufgeführt, da auch in klassischen Unternehmen Innovationsprozesse über die drei Horizonte stattfinden. Das Konzept ist daher das gleiche wie im ersten Szenario: Zu Beginn eines Innovationsprozesses müssen zuerst die Kundengruppen und Kundenbedürfnisse herausgearbeitet werden, damit für diese ein Produkt entwickelt werden kann.

Auch hier gibt es Herausforderungen. Sollen Teams so flexibel sein, dass sie sich verändernden Anforderungen anpassen können, so müssen diese Anforderungen regelmäßig überprüft werden. Dies erfordert einen iterativen Prozess mit einer kontinuierlichen Zusammenarbeit mit den Kunden. Außerdem erfordert dies, dass Teams sich an den Anforderungen orientieren, und nicht einfach spannende Technologietrends umsetzen.

Zusammenfassung

Wenn ein Team ein Produkt auf Basis der Kundenwünsche entwickeln soll, so wird hierfür eine gewisse Flexibilität benötigt. Dies erfordert die Übertragung klassischer Managementaufgaben in die Hände des Teams, damit nicht immer auf Übersetzungen und Entscheidungen des Managements gewartet werden muss. Damit dieses System nicht in Chaos abkippt, muss ein klarer Rahmen definiert werden. Außerdem muss das Team in den Fähigkeiten geschult werden, die es benötigt, um diesen Rahmen effektiv auszufüllen.

Meine persönliche Erfahrung ist, dass selbstorganisierende Teams in einem unterstützendem Framework wie Scrum in vielen Umgebungen Wert schaffen können. Das Konzept funktioniert in Großkonzernen, Familienunternehmen und Startups genauso wie in nationalen oder internationalen Organisationen. Häufig erlebe ich, dass selbstorganisierende Teams schnell lernen, und sich zu selbstgestaltenden Teams entwickeln wollen. Diese Entwicklung ist zu begrüßen, und führt dazu, dass Teams noch besser Wert für den Kunden (und damit auch für das Unternehmen) schaffen können. Leider ist an dieser Stelle die Organisationsstruktur ein häufiges Hindernis, da ein hierarchisches Verständnis mit Organigrammen nicht so einfach zu autonomen Teams und deren Zusammensetzung passt. Ist die Organisation aber bereit, agiler zu arbeiten, können autonome Teams große Vorteile mit sich bringen.

Der vorige Teil dieser Artikelserie zu agilen Teams erwähnte an mehreren Stellen, dass in einem Team sämtliche Fähigkeiten vorhanden sein müssen, um die Anforderungen des Kunden erfüllen zu können. Dieser Artikel möchte Möglichkeiten zur Umsetzung dieser Forderung beschreiben.

Funktionsübergreifende Teams

Formal ist ein Team eine Gruppe von Menschen, die versucht, gemeinsam eine Aufgabe zu erledigen oder ein Ziel zu erreichen. Klassischerweise werden Teams in Unternehmen daher nach den Aufgaben gebildet. Ein naheliegender Gedanke ist dabei, die Aufgaben in Funktionen oder Phasen zu untergliedern, zum Beispiel Entwicklung, Produktion, Marketing, Logistik, Kundenservice und so weiter. Die so entstehenden Expertenteams haben den Vorteil, dass die Teammitglieder sich über „ihre“ Themen austauschen können, von den Erfahrungen profitieren können und im Falle eines Ausfalles schnell die Ressourcen ersetzen können. Das erfahrenste Mitglied kann zum Teamleiter befördert werden und so die Qualität der Arbeit und der Mitarbeiter sicherstellen.

Ein großer Nachteil dieser Expertenteams ist, dass sie monofunktional sind. Sobald eine Aufgabe mehr als eine Funktion benötigt, existieren Abhängigkeiten zwischen den Teams. Die so entstandene Komplexität ist schwer zu beherrschen. Dies führt zu Wartezeiten auf Antworten, vielen Meetings, und sinkender Qualität, da das Expertenwissen häufig in den Teamsilos gefangen ist. Manchmal wird jemand verantwortlich gemacht, diese Komplexität zu managen, aber meistens ist die Komplexität zu schwer zu überblicken.

Wird allerdings nicht nach Phasen oder Funktionen, sondern nach Produkten gegliedert, entsteht ein radikal anderer Blickwinkel. Nun werden für die Weiterentwicklung eines Produktes Experten aus verschiedenen Funktionen benötigt. Idealerweise wird die gesamte Wertschöpfungskette eines Produktes durch ein Team abgedeckt. So werden die Schnittstellen zu anderen Teams minimiert, was zu einer massiven Beschleunigung der Projekte führt.

Natürlich ist dieser Gedanke nicht neu, Projektteams sind normalerweise genau nach diesem Prinzip aufgebaut. Diese werden dann häufig als crossfunktional oder interdisziplinär bezeichnet, in der agilen Welt werden sie sie normalerweise funktionsübergreifend genannt.

Teamzusammensetzung

Für die Teamzusammensetzung ist die entscheidende Frage, ob das Team auf das Produkt oder auf den Kunden fokussiert sein soll. Dies klingt nach einem vernachlässigbaren Unterschied, ist aber essenziell für die Unternehmensstrategie.

Ein Team, das auf ein Produkt fokussiert ist, versucht das Produkt weiterzuentwickeln. Es schafft somit einen Mehrwert für das Produkt, und somit indirekt einen Mehrwert für den Kunden. Das Team erhält normalerweise eine Liste an Anforderungen, die es dann vollständig umsetzen muss. Dies ist meist schon schwierig genug, denn dies erfordert nicht nur, dass die Teammitglieder aus den dafür nötigen Experten rekrutiert werden, sondern auch, dass das Team alle das Produkt betreffenden Entscheidungen treffen darf.

Ein Team, das auf den Kunden fokussiert ist, versucht Probleme des Kunden zu lösen. Es schafft somit direkt einen Mehrwert für den Kunden. Dementsprechend benötigt ein kundenwertoptimierendes Team weitere Fähigkeiten zur Identifizierung der Kundenprobleme. Die einfachste Möglichkeit, diese Fähigkeit im Team zu installieren besteht daraus, Personen mit entsprechenden Rollen (z.B. Business Analysten) in das Team zu integrieren.

Andere Möglichkeiten basieren auf Weiterbildungsmaßnahmen der Teammitglieder, sodass diese in die Lage versetzt werden, Kundenprobleme zu identifizieren und in Lösungen zu übersetzen. Schulungen, Mentoring, Coaching, Pairing mit Business Analysten sind effektive Varianten, außerdem wäre denkbar, dass Business Analysten für einen begrenzten Zeitraum im Team mitarbeiten, bis das Team die entsprechenden Fähigkeiten gelernt hat.

Natürlich sollte bei der Teamzusammenstellung auch bedacht werden, dass die Persönlichkeiten der Teammitglieder zueinander passen. Nur weil die einzelnen Teammitglieder jeweils die beste Person für eine Teilaufgabe sind, heißt dies noch lange nicht, dass sie in Summe ein gutes Team bilden. In den meisten Fällen stellt die Teamzusammensetzung aber kein großes Problem dar, da heutzutage so gut wie jeder die Teamarbeit gewohnt ist und entsprechend teamfähig und kooperativ ist.

Teambegleitung

Je nach Autonomiegrad des Teams (siehe Teil I) und je nachdem, wie lange ein Team bereits zusammenarbeitet, benötigt ein Team Unterstützung, um gut zu arbeiten. Dies hängt sowohl mit den zu übernehmenden Aufgaben als auch mit den verschiedenen Phasen der Teamentwicklung zusammen. Daher werden im Scrum-Framework zwei Rollen zu Teambegleitung geschaffen: Der Product Owner und der Scrum-Master.

Die zentrale Aufgabe des Product Owners ist das Produkt. Er muss dafür sorgen, dass geleistete Arbeit des Teams auch einen Mehrwert für das Produkt liefert. Wird der Product Owner von außen bestimmt, bedeutet dies normalerweise, dass er Aufgaben (User Stories) definiert und priorisiert. Im Falle kundenwertoptimierender Teams führt dies zu einem Widerspruch. Das Team möchte Kundenprobleme lösen, der Product Owner möchte aber Mehrwert für das Produkt schaffen. Daher ist es bei kundenwertoptimierenden Teams üblich, dass die Teams selbst die Aufgaben definieren, der Product Owner dagegen lediglich die Priorisierung übernimmt.

Der Scrum-Master soll dafür sorgen, dass das Team die verschiedenen Phasen der Teamentwicklung erfolgreich durchläuft. Gleichzeitig muss er darauf achten, dass das Team im Sinne von Inspect & Adapt stets besser wird. Diese Aufgaben erfüllen die meisten Scrum-Master dann besonders gut, wenn sie keine Entwicklungsaufgaben im Team haben und nicht mehr als zwei Teams betreuen.

Zusammenfassung

Wenn ein Team ein Produkt auf Basis der Kundenwünsche entwickeln soll, so werden hierfür gewisse Fähigkeiten im Team benötigt. Dazu müssen die nötigen Fähigkeiten und Entscheidungskompetenzen im Team gebündelt oder aufgebaut werden. Gleichzeitig sollten ein Team, besonders am Anfang, begleitet werden.

Im Teil I dieser Serie zu agilen Teams beschrieb ich, dass agile Teams Aufgaben übernehmen, die klassischerweise von einem Manager übernommen wurden. Daher müssen sich Teams früher oder später mit der Frage auseinandersetzen, wie Entscheidungen getroffen werden sollen. In diesem Artikel möchte ich dazu einige Möglichkeiten vorstellen.

Entscheidungsfähigkeit

Es klingt banal, aber vor jeder Entscheidung muss sichergestellt sein, dass jedes Teammitglied entscheidungsfähig ist. Das setzt voraus, dass die Teammitglieder verstehen, was der Teamzweck ist, und wie die Wertschöpfung des Unternehmens stattfindet. Hier eignen sich Konzepte wie Visionen oder Nordsterne.

Das bedeutet, dass die Teammitglieder folgende Punkte verstehen müssen:

• die Kunden des Unternehmens
• die Probleme der Kunden des Unternehmens
• wie das Unternehmen diese Probleme löst
• wie das Unternehmen Problemlösungen entwickelt
• wie das Unternehmen damit Geld verdient

Auf Basis dieses Verständnisses können Teammitglieder Meinungen und Perspektiven bilden, die dann in einem Prozess zu einer Entscheidung führen.

Mehrheitsentscheid

Der Mehrheitsentscheid ist die einfachste und bekannteste Form der Entscheidungsfindung im Team. Üblicherweise läuft der Prozess in drei Schritten ab:

• Sammeln von Ideen und Lösungsvorschlägen
• Diskussion der Optionen
• Abstimmung

Manchmal finden sich hier noch Feedbackschleifen. Das bedeutet, dass aus der Diskussion neue Lösungsvorschläge generiert werden, oder bereits vorhandene Vorschläge überarbeitet werden. Je nach Team gibt es auch zur Abstimmung verschiedene Verfahren, zum Beispiel wird manchmal eine einfache Mehrheit, und manchmal eine absolute Mehrheit benötigt.

Der Mehrheitsentscheid hat einige Vorteile. Das Verfahren ist bekannt, das Verfahren ist schnell, und normalerweise ist es auch fair. Allerdings ist das Wort „fair“ an dieser Stelle verwirrend. Eigentlich soll ja nicht eine faire Lösung gefunden werden, sondern die beste Lösung. Häufig neigen Teams aber dazu, anstelle der besten Lösung einen Kompromiss zu wählen. Es ist eine große Herausforderung, diese Verwässerung der besten Lösung zu vermeiden.

Warum gehen Teams Kompromisse ein? Dies hängt mit dem Commitment der „Wahlverlierer“ zusammen. Nur weil sich eine Option durchsetzt, heißt das ja noch lange nicht, dass plötzlich alle Teammitglieder auf magische Art und Weise hinter dieser Lösung stehen. Die Unterstützung aller Teammitglieder ist aber für den weiteren Teamerfolg wichtig. Durch einen Kompromiss kann eine Lösung erzeugt werden, die dann von den meisten Teammitgliedern akzeptiert wird, denn es wurde ja jede Meinung irgendwie berücksichtigt.

Der Mehrheitsentscheid hat noch einen weiteren Nachteil. Im Extremfall kann der Mehrheitsentscheid dazu genutzt werden, Minderheitenmeinungen zu unterdrücken. Auch das beschädigt wieder das Commitment der „Verlierer“. Sollte sich dann gar abzeichnen, dass die gewählte Lösung nicht funktioniert, werden die unterdrückten Verlierer vermutlich behaupten, sie hätten es ja gleich gesagt, und man hätte doch auf sie hören sollen. Für die Teamdynamik ist dies außerordentlich schlecht.

Konsent

Das Konsentverfahren ist eine Alternative zum Mehrheitsentscheid. Hier werden im Schritt der Abstimmung drei Möglichkeiten angeboten:

• Daumen hoch: Ich finde den Vorschlag gut, und unterstütze ihn.
• Daumen zur Seite: Ich finde den Vorschlag nicht unbedingt gut, aber wenn die Mehrheit dafür ist, bin ich einverstanden.
• Daumen runter: Ich habe einen wichtigen Einwand.

Ziel des Konsentverfahrens ist nicht, dass alle Abstimmenden mit dem Daumen nach oben abstimmen. Ziel ist stattdessen, dass alle wichtigen Einwände gehört werden, und der Vorschlag so per Diskussion immer weiter verbessert wird. Dabei ist darauf zu achten, dass der Daumen runter nicht als Veto missverstanden wird, sondern nur verwendet wird, wenn sinnvolle Einwände diskutiert werden müssen.

Der Vorteil dieses Verfahrens ist ein hohes Commitment aller Abstimmenden, da durch das Anhören der Einwände auch diejenigen mit einbezogen werden, die den Vorschlag nicht unbedingt gut finden. Der Nachteil dieses Verfahrens liegt darin, dass die Diskussion der Einwände analog zu den Kompromissen bei Mehrheitsentscheiden dazu führen können, dass die Lösung verwässert. Gleichzeitig werden durch die Diskussion der Einwände eventuelle blinde Flecken aufgedeckt. Daher eignet sich das Konsentverfahren besonders gut, wenn eine Lösung nicht perfekt sein muss, aber nicht scheitern darf.

Üblicherweise wird der Daumen zur Seite auch verwendet, wenn es dem Abstimmenden egal ist. Der Daumen runter sollte auch verwendet werden, wenn der Abstimmende die Option(en) noch nicht ausreichend verstanden hat.

Konsultativer Einzelentscheid

In den vorigen Methoden sorgt der Bedarf, durch Kompromisse eine Mehrheit zu erzeugen, mitunter zur Verwässerung der besten Lösung. Soll dies verhindert werden, bedeutet dies, dass keine Mehrheit zur Entscheidung nötig ist. Das klingt absurd, entspricht aber der klassischen Entscheidungsstruktur: Die hierarchisch höher gestellte Person entscheidet unabhängig von Mehrheiten.

Dieses Modell kann auch für Teams angewendet werden. Da in Teams keine Hierarchien existieren, ist dieses Modell aber nicht so einfach umzusetzen. Die Grundidee ist daher, dass jedes Teammitglied zum Entscheider werden kann. Dabei wird vorausgesetzt, dass der Entscheider die anderen Teammitglieder anhört und sich deren Rat einholt. Das Ergebnis ist der Prozess des konsultativen Einzelentscheides.¹N. Pfläging, P. Steinmann, Organisation für Komplexität: Wie Arbeit wieder lebendig wird – und Höchstleistung entsteht, 3. Aufl., Redline Verlag, München, 2014.

Dieser Prozess besteht aus mehreren Schritten. Als erstes muss identifiziert werden, worüber entschieden werden soll, und wer die Entscheidung treffen soll. Da eine solche Entscheidung auch mit der Übernahme von Verantwortung verbunden ist, wird häufig die Person gewählt, der das Team am meisten vertraut. Dieses Vertrauen kann auf Expertise, Interesse an der Entscheidung oder guten Kommunikations- oder Moderationsfähigkeit und der Fähigkeit zum Interessensausgleich basieren.

Anschließend folgt die Konsultation. Dazu muss der Entscheider andere Teammitglieder konsultieren, also anhören. Je nach Art der Entscheidung werden hier viele oder wenige Teammitglieder angehört: Kleine, reversible Entscheidungen benötigen nur zwei oder drei Perspektiven, große, irreversible Entscheidungen fordern deutlich mehr Perspektiven. Natürlich kann der Entscheider auch externe Perspektiven hinzuziehen, sei es durch Recherche oder Beratung.

Der folgende Schritt ist die Entscheidung, basierend auf den gewonnenen Perspektiven. Dabei geht es nicht darum, es einer Mehrheit recht zu machen, oder aus den Einzelperspektiven eine Gesamtperspektive zu bilden, sondern die bestmögliche Entscheidung zu treffen. Natürlich muss die Entscheidung anschließend öffentlich gemacht werden, dazu gehört auch die transparente Darstellung der gewonnenen Perspektiven.

Es folgt der schwierigste Schritt jedes Entscheidungsprozesses: Die Akzeptanz der Entscheidung. Da dieses Verfahren nicht an Konsens gebunden ist, haben die Teammitglieder keine andere Wahl, als das Ergebnis zu akzeptieren. Da aber jedes Teammitglied beim nächsten Mal in der Rolle des Entscheiders sein könnte, und daher die Tragweiten dieser Verantwortung einschätzen können, ist die Schwelle der Akzeptanz deutlich niedriger. Die restlichen Teammitglieder wissen daher, dass es keine perfekte Entscheidung gibt, und sind eher bereit, eine unerwünschte Entscheidung zu „vergeben“.

Natürlich sollte auch am Ende des konsultativen Einzelentscheides reflektiert werden, wie dieser Prozess verbessert werden kann. Das gilt selbstverständlich auch für Konsent und Mehrheitsentscheid.

Zusammenfassung

Die hier vorgestellten Modelle sind Möglichkeiten, im Team frei von Hierarchien zu entscheiden. Der Konsent-Prozess setzt darauf, dass die gefundene Lösung von allen mitgetragen wird. Er eignet sich daher, Kompromisse zu finden, mit den damit verbundenen Vor- und Nachteilen. Der konsultative Einzelentscheid ist dagegen besser geeignet, um harte oder schnelle Entscheidungen zu fällen.

Es sollte bedacht werden, dass es keine allgemeingültige Lösung gibt, die in jedem Team funktioniert. Stattdessen muss jedes Team seinen eigenen Weg finden. Das bedeutet häufig sogar, dass situationsabhängig ein anderes Entscheidungsverfahren als üblich angewendet wird. Beispielsweise könnte ein Team, das normalerweise auf Konsent setzt, bei manchen Entscheidungen auch einfach per Mehrheit entscheiden, oder umgekehrt.