Autonomie vs. Initiative

Um die Serie über Autonomie von Teams fortzusetzen, möchte ich nach Autonomie vs. Auftrag noch diesen wichtigen Aspekt zu dem Thema hinzufügen. Dabei handelt es sich darum, welche Auswirkungen große Initiativen mit vielen Teams in der Praxis haben.

Was ist eine Initiative?

Wenn ich “Initiative” sage, beziehe ich mich damit auf den Arbeitsaufwand für ein Produkt, bei dem viele Teams involviert sind. Das könnte z. B. etwas in der Art sein: die Überarbeitung der Benutzerfreundlichkeit einer Webseite, der Wechsel zum Responsive Design, eine Internationalisierung oder das Eindringen in bedeutende neue Märkte wie z. B. China. All das sind grundsätzlich recht wichtige Dinge, die aber normalerweise den gemeinsamen Arbeitsaufwand mehrerer – wenn nicht sogar aller – Ihrer Produktteams erfordern.

Prinzipiell ist die Umgestaltung einer Plattform wegen besserer Skalierbarkeit oder der Leistung – wie beispielsweise eine neue Architektur oder neue technologische Grundlagen – auch eine Art Initiative. Mit diesen technischen Schulden geht man allerdings anders um und daher werde ich in diesem Artikel nicht darauf eingehen.

Lassen wir einmal außen vor, ob es grundsätzlich eine gute oder eine schlechte Idee ist, eine bestimmte Initiative durchzuführen. Dieses Thema habe ich schon in einem anderen Artikel behandelt. Lassen Sie uns hier einfach davon ausgehen, dass die Initiative eine gute und wichtige Sache ist. Ich möchte die drei Möglichkeiten erläutern, wie Teams mit diesen großen und komplexen Initiativen umgehen können.

Es geht um Folgendes: Per Definition haben wir ein komplexes Projekt, um das wir uns kümmern müssen und bei dem viele Teams involviert sind. Jedes Team hat seine eigenen Details zu klären, aber die Frage ist, wer das alles leitet und wie. Wenn es bei der Initiative darum geht, das Produktangebot an den chinesischen Markt anzupassen, schicken wir dann jedes einzelne Team nach China, um herauszufinden, was getan werden muss? Das wäre nicht sehr sinnvoll und höchstwahrscheinlich würde jedes Team eine andere Lösung finden.

Strategie 1: Ein Führungsteam

In den meisten Fällen wird eines der Teams ausgesucht, das die Hauptrolle übernimmt und die Initiative leitet, also die Leitung von Discovery und Delivery übernimmt. Natürlich ist dieses Team auf die Arbeit von den anderen Teams angewiesen aber es leitet und koordiniert diese Arbeiten auch. Beispielsweise würde es eine Gruppe von Kunden identifizieren, um mit ihnen dann die nötigen Veränderungen am Produkt zu bestimmen, und danach dabei helfen, die nötigen Arbeiten (Discovery und Delivery) aufzuteilen und in Angriff zu nehmen.

Vorteile dieses Ansatzes sind der eindeutige Verantwortungsbereich bzw. Ownership. Natürlich sollte man versuchen, ein Führungsteam auszusuchen, auf das diese Arbeit einen starken Einfluss hat.

Es gibt aber auch einen Nachteil bei diesem Ansatz. Wenn das leitende Team nämlich nicht permanent die anderen Teams über neue Erkenntnisse und Entscheidungen informiert, werden sie diese Entscheidungen nicht verstehen können oder ihnen widersprechen, sobald es darum geht, die Arbeit aufzuteilen. Und an diesem Punkt wird die Autonomie dann wirklich zur Herausforderung.

Strategie 2: Ein vorübergehendes Team

Bei diesem Ansatz wird keines der bestehenden Teams mit der Leitung der Initiative beauftragt. Stattdessen wird extra (für die Dauer dieser Initiative) ein vorübergehendes Discovery Team gebildet, das sich dann zumindest um die Discovery Arbeiten kümmert. Normalerweise besteht ein solches Team aus einem Product Owner, einem leitenden UX Designer und mindestens einem leitenden Entwickler. Sobald diese Gruppe die nötigen Delivery Arbeiten identifiziert hat und Backlog Items erstellt hat, gehen die Mitglieder dieses vorübergehenden Teams zurück in ihre eigentlichen Teams.

Der Vorteil hierbei ist, dass man ein starkes Team mit engagierten Leuten hat, die sich auf diese Arbeit konzentrieren können. Der Nachteil ist, dass diese Leute relativ schnell wieder zurück in ihre eigenen Teams gehen. Das ist eigentlich etwas Gutes, weil sie ihren Teams dann mitteilen können, was sie erfahren und entschieden haben. Allerdings gibt es dann auch keine klaren Verantwortungsbereiche bzw. Ownership mehr. Und auch hier gibt es das Risiko, dass die anderen Teams nicht verstehen oder nicht damit einverstanden sind, was ihnen mitgeteilt wird. Ein weiterer Nachteil ist, dass man dadurch, dass Leute aus ihren Teams genommen werden, das Ziel der Beständigkeit von Teams untergräbt.

Strategie 3: Ein vereintes Team

Die dritte Möglichkeit, diese Initiativen anzugehen, ist etwas, das ich normalerweise nicht empfehle. Ich muss es aber erwähnen, weil es ab und zu vorkommt. Bei diesem Ansatz tun sich einige Teams (nicht notwendigerweise alle) zusammen, um die Discovery Arbeit gemeinsam durchzuführen.

Der große Vorteil davon ist, dass alle neuen Informationen geteilt werden und das ist von sehr großem Wert.

Der größte Nachteil ist jedoch, dass es viele Personen gibt, die an der Entscheidung beteiligt sind und zu viele Köche verderben bekanntlich den Brei.

Fazit zu Autonomie vs. Initiative

Wofür Sie sich auch entscheiden, Sie müssen eine Lösung für die Initiative finden und auch durchführen. Dies sind die drei Möglichkeiten, wie Teams damit umgehen können. Man kann schlecht sagen, dass eine davon im Hinblick auf Autonomie besser ist als die anderen, denn bei einer Initiative geht es schließlich darum, etwas Gutes für die Organisation zu tun, und nicht notwendigerweise darum, welche Entscheidungsfreiheit die einzelnen Teams haben. Vielleicht ist es treffender zu sagen, dass man sich einen dieser Ansätze aussuchen kann, um so das Gefühl von Autonomieverlust zu minimieren.

Denken Sie daran, dass diese Initiativen oft äußerst wertvoll für unsere Kunden und unser Unternehmen sind, also gibt es verdammt viel, worauf Sie stolz sein können, wenn Sie diese Initiative erfolgreich abschließen.

Dieser Text stammt aus dem Blog von Marty Cagan und wurde von uns ins Deutsche übersetzt.