Agilität

Das Cynefin-Modell

Veröffentlicht am
Geschätzte Lesezeit: 9 Minuten.

Im Projektmanagement stolpert man immer mal wieder über Begriffe wie kompliziert, chaotisch oder komplex. Meistens wird dies verbunden mit einer Begründung, warum die eine oder andere Methode besser geeignet sei. Dieser Artikel will das dahinterstehende Cynefin-Modell vorstellen.

Einleitung

Das Cynefin-Modell wurde von David J. Snowden entwickelt[1]. Es teilt Projekte, Aufgaben, oder allgemein alle Probleme in verschiedene Bereiche auf. Zuerst wird unterschieden zwischen dem geordneten und dem ungeordneten Bereich[2].

Der geordnete Bereich bedeutet, dass Ursache und Wirkung erkannt werden können. Dies führt dazu, dass die richtige Antwort auf Basis von Fakten ermittelt werden kann. Diese Ermittlung kann einfach oder kompliziert sein, dementsprechend wird der Bereich in Einfach und Kompliziert unterteilt.

Im ungeordneten Bereich können Ursache und Wirkung nicht erkannt oder unterschieden werden. Stattdessen muss hier mit Mustern gearbeitet werden. Der Bereich wird in Komplex und Chaotisch unterteilt. Komplex bedeutet, dass man im Nachhinein Ursache und Wirkung erkennen kann, bei Chaotisch geht dies nicht.

Außerdem gibt es noch den Bereich Unklar, der dazwischen liegt. In diesem Bereich ist zu wenig über die Aufgaben oder Probleme bekannt, um sie einem der anderen Bereiche zuzuordnen.

Einfach: Best Practice

Der einfache Bereich zeichnet sich durch Stabilität aus. Hier ist einfach zu erkennen, welche Ursache zu welcher Wirkung führt, sodass die richtige Antwort naheliegend ist und nicht bezweifelt wird.

Dementsprechend einfach ist das Vorgehen in den drei Schritten Erkennen – Kategorisieren – Reagieren. Zuerst wird erkannt, also möglichst viele Fakten gesammelt. Anschließend wird die Situation kategorisiert, also zum Beispiel einem der vielen Fälle zugeordnet, für die es definierte Prozesse gibt, und dann wird reagiert, also dem Prozess gefolgt.

In diesem Bereich sind viele Dinge tatsächlich so einfach, wie sie klingen. Es gibt oft definierte Prozesse, es gibt etablierte Best Practices, dementsprechend muss wenig kommuniziert werden, und es kann gleichzeitig viel delegiert werden. Als Management-Stil eignet sich hier Command & Control.

Schwierig wird es, wenn Probleme unbedingt in diesen einfachen Lösungsraum gezwungen werden sollen. Reduktion von Komplexität ist zwar grundsätzlich wünschenswert, allerdings führt dies manchmal dazu, dass Probleme zu sehr vereinfacht werden. Dies kann den Blick auf die Dinge verschleiern, man wird bequem, und man übersieht etwas. Üblicherweise kippt ein solches System dann in das Chaos ab. Leider gibt es keinen einfachen Weg vom Chaos zur Einfachheit, da die vorigen Prozesse ersetzt und neue Prozesse entwickelt werden müssen. Der Weg vom Chaos zu Einfach führt über die Schritte Komplex und Kompliziert.

Kompliziert: Experten gefordert

Wie im einfachen Bereich gibt es eine richtige Antwort, die auf Basis von Fakten gefunden werden kann. Allerdings ist es schwierig, die richtige Antwort zu finden, oder die dafür nötigen Fakten zu sammeln. Hier sind Experten nötig.

Das Vorgehen unterscheidet sich leicht vom Bereich Einfach, da der zweite Schritt nicht mehr Kategorisieren, sondern Analysieren ist. Für diese Analyse ist normalerweise Expertenwissen nötig, denn hier müssen mehrere Handlungsoptionen, die möglicherweise alle sehr gut sind, im Detail verstanden und beurteilt werden. Dies führt auch dazu, dass der Begriff der Best Practice durch den Begriff der Good Practice ersetzt wird.

Die Vorteile des Expertenwissens führen leider auch zu Nachteilen. Die Entscheidung muss von den Experten getroffen werden. Manchmal werden dadurch bessere, aber unkonventionelle oder kreative Vorschläge von Nicht-Experten nicht ernst genommen oder übersehen. Außerdem kann Expertenwissen schnell veralten, wenn sich der Kontext ändert.
Zusätzlich kann Über-Analyse zu Problemen führen, die die Entscheidungsfindung blockieren. Experten sind detailverliebt und wollen alles ganz genau analysieren, aber manchmal ist der Detailgrad gar nicht nötig. Hier gibt es einen Punkt, ab dem die Entscheidung getroffen werden muss, ohne die richtige Antwort bis in das letzte Detail zu analysieren.

Komplex: Mustererkennung

Im Gegensatz zu den vorherigen Fällen ist die richtige Lösung hier nicht mehr im Voraus ableitbar. Dies ist die häufigste Situation, die in der Wissens- und Kreativitätsarbeit auftritt.

Ursache und Wirkung sind nur noch im Nachhinein erkennbar. Allerdings ist es möglich, Muster zu erkennen, sodass kleine Experimente angebracht sind, die keinen größeren Schaden verursachen können. Daher wird hier Ausprobieren – Erkennen – Reagieren benötigt.
Diese Methode führt dazu, dass die richtige Lösung nach und nach in kleinen, iterativen Schritten entwickelt wird, ohne dass vorher klar ist, wohin genau die Reise führen wird. Das klingt nach Scrum, und tatsächlich ist dies die Umgebung, in der Agilität den größten Mehrwert liefern kann.

Muster aus den einfachen oder komplizierten Umgebungen funktionieren hier nicht. Hier kann weder mit Command & Control gearbeitet werden, noch können hier vorher definierte Ergebnisse garantiert werden. Besonders schwierig wird es, wenn das experimentelle Vorgehen nicht wirklich akzeptiert wird. Dies kann zu Ungeduld führen, besonders wenn eine Lösung, die man gerne hätte, nicht funktioniert. Auch werden Fehler, die zwangsläufig zu experimentellem Lernen gehören, nicht immer toleriert. Zu enge Kontrolle kann hier das Experimentieren ersticken, und so die Entstehung von Lösungen durch Innovation und Kreativität verhindern.

Chaos: Hauptsache Handeln

Im chaotischen Umfeld sind Ursache und Wirkung auch nicht im Nachhinein zu erkennen. Hier gibt es keine Muster, an denen man sich festhalten könnte. Die Suche nach der richtigen Antwort wäre hier nur Zeitverschwendung. Stattdessen muss gehandelt werden.

Die empfohlene Reihenfolge ist hier Handeln – Erkennen – Reagieren. Zuerst muss gehandelt werden, zuerst muss etwas unternommen werden, um das größte Problem zu beseitigen. Anschließend muss erkannt werden, in welchen Bereichen durch die Handlung Stabilität eingekehrt ist, und dann muss reagiert werden, mit dem Ziel, das Chaos zu beenden und die Situation in eine komplexe Situation zu überführen.

Chaos hat Nachteile, das sollte wenig überraschend sein. Einer der Nachteile ist, dass keine Zeit für Input von anderen ist. Hier ist keine Zeit für Demokratie, für Mitbestimmung, hier muss vor allem gehandelt und kommuniziert werden. Der Top-Down-Ansatz funktioniert tatsächlich am besten. Leider ist der Top-Down-Ansatz in den anderen Bereichen, insbesondere im komplexen Bereich, genau der falsche Ansatz. Es wird also erwartet, mit Top-Down die Situation von Chaos in Komplex zu überführen, um dann im komplexen Bereich sofort mit dem bisher erfolgreichen Top-Down aufzuhören. Das ist nicht gerade leicht zu erreichen.

Chaos hat aber auch einen Vorteil: Im Chaos werden neue, innovative Lösungswege am besten akzeptiert. Das Chaos ist der beste Bereich für Kreativität. Daher gibt es Empfehlungen, im Falle von Chaos zwei Teams zu benennen: Eines zur Krisenbekämpfung, und eines, das sich um die Chancen für Innovation kümmert.

Anforderungen an Führung

Es dürfte mittlerweile klar geworden sein, dass das Bild des Cynefin-Modells keine typische Vier-Felder-Matrix darstellt, obwohl es so aussieht. Der wichtigste Unterschied ist, dass keine Achsen vorhanden sind, sondern nur eine grobe Unterteilung in geordneten und ungeordneten Bereich.

Für Führungskräfte ist es daher nicht unbedingt simpel zu erkennen, in welcher Umgebung man sich gerade befindet. Gleichzeitig ist es aber fundamental wichtig, genau das zu erkennen, um das richtige Verhalten auszuwählen. Daher muss auch das Unternehmen darauf vorbereitet werden, dass es diese Situationen gibt, und wie damit umgegangen wird.

Eine weitere Schwierigkeit des Modells ist, dass die Übergänge zwischen den Bereichen nicht alle gleich sind[3]. Zwar kann von Einfach zu Kompliziert, von Kompliziert zu Komplex, und von Komplex zum Chaos in beide Richtungen gewechselt werden. Der Übergang von Einfach zu Chaos funktioniert aber nur in diese Richtung, anders herum muss der lange Weg von Chaos über Komplex und Kompliziert zu Einfach gewählt werden.

Literatur

[1] D. J. Snowden, M. E. Boone, A Leader’s Framework for Decision Making, Harvard Business Review 2007, 11, 69–76.
[2] Seite „Cynefin-Framework“. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 28. September 2018, 09:55 UTC. URL: https://de.wikipedia.org/w/index.php?title=Cynefin-Framework&oldid=181296399 (Abgerufen: 14. Oktober 2018, 12:09 UTC)
[3] http://www.lean-agility.de/2015/04/cynefin-framework.html

Agilität

Marketingmanagement IX: Agile Perspektive

Veröffentlicht am
This entry is part 9 of 9 in the series Marketingmanagement
Geschätzte Lesezeit: 7 Minuten.

Nachdem ich acht Teile über einen Rahmen zum Marketingmanagement geschrieben habe, ist es an der Zeit, diese Theorie aus einer agilen Perspektive zu beleuchten. Dieser Beitrag ist daher der neunte und letzte Teil der Serie, zum Teil I geht es hier.

Kundenfokus

Bevor ich mich mit den in den vorigen Teilen dargestellten Konzepten des Marketingmanagements auseinandergesetzt hatte, hatte ich eine relativ negative Meinung zu Marketing. Ich glaubte, bei Marketing ginge es darum, ein Produkt gut zu vermarkten, um eventuelle Schwächen des Produktes zu kompensieren. Marketing war für mich also eine Form des Verwirrens des Kunden, der aufgrund von Marktschreiern plötzlich nicht mehr die für ihn optimale Entscheidung trifft. Ganz übertrieben gesagt war Marketing für mich eine Form des Lügens.

Ich weiß nicht, wie dieses Bild in meinem Kopf entstanden war. Vielleicht bin ich althergebrachten Vorurteilen auf den Leim gegangen. Ganz sicher wusste ich es nicht besser. Vermutlich habe ich Marketing auf den einen Punkt reduziert, der mir begegnet, nämlich die Kommunikation als Teil der vier Ps (siehe Teil I, Bereich Handlung). Mittlerweile muss ich meine Meinung revidieren, denn mir ist klar geworden, dass Marketingmanagement deutlich mehr umfasst.

Besonders deutlich ist, dass der Kunde den Mittelpunkt aller Aktivitäten darstellen muss. Dies ist eine Gemeinsamkeit mit der agilen Perspektive, die ebenfalls einen radikalen Kundenfokus fordert. Dieses Grundkonzept des Marketingmanagements hat mir daher sehr gut gefallen.

Allerdings sollte nicht vergessen werden, dass die Beeinflussung des Kunden trotzdem eine Rolle spielt. In Teil II wird dies diskutiert, hier werden Kaufentscheidungsprozesse und Einflussmöglichkeiten diskutiert.

Feedbackschleifen

Ein zentraler Gedanke agiler Praxis ist die der Feedbackschleife. Je nach Geschmack wird dies mit inspect & adapt (deutsch: Beobachten und Anpassen) bezeichnet, oder über einen der Punkte des agilen Manifestes beschrieben: Responding to change over following a plan (deutsch: Reagieren auf Veränderung ist wichtiger als stur einem Plan zu folgen).

Die dahintersteckende Idee ist, dass es in einer komplexen Welt im Allgemeinen, und in komplexen Produktentwicklungen im Besonderen, nur selten möglich ist, Dinge weit im Voraus exakt zu planen. Bei Innovationsprozessen ist es dagegen sehr häufig so, dass der dritte Schritt extrem von den Ergebnissen des ersten und zweiten Schrittes abhängig ist. Diese Abhängigkeit bezieht sich sowohl auf eine inhaltliche als auch auf eine zeitliche, personelle und organisatorische Abhängigkeit. Das bedeutet, es ist weder klar, was getan werden muss, noch wann, noch von wem, noch ob die vorhandene Struktur dies überhaupt erlaubt.

Das klingt nach Chaos? Leider ist dieser Vorwurf nicht komplett von der Hand zu weisen. Allerdings ist dies eine Frage der Perspektive. Wenn die Perspektive ist, dass alles, das weniger als zu 100% in Voraus exakt planbar ist, Chaos bedeutet, dann stimmt dieser Vorwurf. Wenn Chaos bedeutet, dass im Voraus unbekannt ist, welches der beste Weg zu einem Ziel ist, auch dann stimmt dieser Vorwurf. Wenn Chaos bedeutet, dass niemand weiß, was er machen soll, und alle plötzlich wie kopflose Hühner durch die Gegend laufen, dann stimmt dieser Vorwurf nicht. Die mittlere Beschreibung trifft es am besten: Allen ist das Ziel bekannt, aber der beste Weg dorthin muss erst noch gefunden werden. Ist das Chaos? Meiner Meinung nach: Nein.

Wenn das Ziel bekannt ist, aber der Weg noch nicht, dann funktioniert Agilität am besten. Diese Beschreibung entspricht dem Horizont 2 im Drei-Horizonte-Modell für Innovationen, darauf möchte ich an dieser Stelle nicht weiter eingehen. Daher nur kurz der wichtigste Unterschied zum ersten Horizont: Der erste Horizont entspricht im Prinzip der Serienfertigung. Am Fließband weiß jeder genau, was wann wie zu tun ist, um das beste Produkt zu liefern. Dies ist im Detail im Voraus planbar, und hier ist Agilität nicht nötig, aber so funktioniert Innovation ja nicht. Innovative Produktentwicklung beinhaltet immer Unplanbarkeit, die das Reagieren auf Veränderung erfordert.

Dieser Kerngedanke der Unplanbarkeit wird in vielen agilen Frameworks, zum Beispiel Scrum, so interpretiert, dass bewusst nicht langfristig exakt geplant wird, sondern nur kurzfristig. Die langfristige Planung wird dagegen durch Ziele, Visionen und Leitplanken sichergestellt. Gleichzeitig wird durch Feedbackschleifen sichergestellt, dass die kurzfristige Planung und die Ergebnisse dieser kürzeren Entwicklungsschritte auch tatsächlich den erhofften Mehrwert liefern.

In den vorgestellten Modellen des Marketingmanagements scheint die Philosophie eine andere zu sein. Es scheint so, als wäre dies auf eine langfristige Planung ausgelegt, als könne man die einzelnen Schritte einfach in der richtigen Reihenfolge durchlaufen, und dann sei alles gut. Der Kunde spielt zwar eine Rolle, aber er wird nur ganz am Anfang intensiv analysiert. Danach wird der Markt segmentiert, ein Produkt entwickelt, auf den Markt gebracht und beworben. Aber was ist, wenn dieser Prozess so lange dauert, dass sich die Kundenbedürfnisse verändert haben? Darauf gibt es keine vernünftige Antwort. In der agilen Welt kann dies nicht passieren, da durch kurze Feedbackschleifen ständig geprüft wird, ob der Entwicklungsstand noch zu den Kundenbedürfnissen passt.

Ganz plakativ formuliert könnten die beiden Philosophien wie folgt beschrieben werden: Entweder glaubt man daran, dass durch hartes Nachdenken die perfekte Lösung gefunden werden kann, oder man überprüft die eigenen Hypothesen regelmäßig. Die zweite Variante wird oft als iterativ beschrieben, manchmal auch als empirisch. Empirisch klingt sehr wissenschaftlich, und Harald Lesch, Astrophysiker und Fernsehmoderator, hat einmal gesagt: „In den Naturwissenschaften irren wir uns empor.“ Das Zitat ist nicht wörtlich wiedergegeben, aber im Kern geht es darum, dass durch die regelmäßige Überprüfung der Hypothesen durch kurze Feedbackschleifen am Ende eine bessere Lösung entsteht.

Zusammenfassung

Obwohl das Marketing-Framework klar tayloristisch geprägt ist, sind viele der zentralen Gedanken problemlos in der agilen Welt anwendbar. Besonders der Fokus auf die Kundenbedürfnisse hat mir sehr gut gefallen. Gleichzeitig finde ich es gut, dass das Marketing-Framework nicht nur auf die Produktentwicklung reduziert ist, sondern umfassender angelegt ist. Mir persönlich hat die Beschäftigung mit dieser Materie daher deutlich weitergeholfen.

Dies ist das Ende dieser Serie zu Marketingmanagement. Daher folgt nun ein kleiner Teaser zur nächsten Serie. Deren Arbeitstitel lautet: Führung und Einfluss.

Agilität

Agile Teams III: Entscheidungen in agilen Teams

Veröffentlicht am
This entry is part 3 of 3 in the series Agile Teams
Geschätzte Lesezeit: 8 Minuten.

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[1].

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.

Literatur

[1] 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.

Agilität

Agile Teams II: Zusammenstellung agiler Teams

Veröffentlicht am
This entry is part 2 of 3 in the series Agile Teams
Geschätzte Lesezeit: 6 Minuten.

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.

Agilität

Agile Teams I: Aufgaben und Autonomie agiler Teams

Veröffentlicht am
This entry is part 1 of 3 in the series Agile Teams
Geschätzte Lesezeit: 10 Minuten.

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[1] 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[2] 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[3] beschrieben. Typisch für solche managergeführten Teams sind die folgenden Ausprägungen[3]:

  • 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.

Literatur

[1] J. R. Hackman, Leading Teams: Setting the Stage for Great Performances, 1. Aufl., Harvard Business Review Press, Brighton, 2002.
[2] 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.
[3] 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).