Autonomie vs. Auftrag

In meinem letzten Artikel habe ich über die Kompromisse zwischen den unterschiedlichen Zielen der Autonomie und der Fremdbestimmung bei Teams geschrieben. Ich habe einige Zuschriften bekommen, in denen stand, dass dies ein großes Thema in den Unternehmen sei und einige Personen wollten etwas mehr zu diesem Thema wissen – aber eher aus einer Produkt- und Design-Perspektive als aus Entwicklungssicht. Das Thema ist sehr vielfältig und daher dachte ich, dass es sich lohnt, es weiter auszuführen.

Hier sind einige Fragestellungen, auf die ich eingehen möchte:

• Was ist, wenn ein Team eine noch bessere Gelegenheit sieht und entschließt, sich auf einen anderen Kundentyp zu konzentrieren?
• Was ist, wenn ein Team nicht die Arbeit ausführen will, die eine große Unternehmensinitiative unterstützen soll (z. B. Internationalisierung des Produkts)?
• Was, wenn ein Team davon überzeugt ist, den Kurs ändern zu müssen, um die Chancen auf dem Mobilmarkt nutzen zu können, obwohl das Team nur für einen Teil des Gesamten zuständig ist?
• Was, wenn ein Team davon überzeugt ist, zu einem anderen User Experience Design wechseln zu müssen, obwohl es sich dann von dem der anderen Teams unterscheiden würde?

In jedem dieser Fälle haben Team und Management wahrscheinlich ganz unterschiedliche Sichtweisen. Viele Teams behaupten, dass sie – wenn sie wirklich eigenverantwortlich arbeiten dürfen – solche Entscheidungen treffen können.

Die Problematik

In gesunden Teams und Organisationen kommt man normalerweise zu einem Kompromiss zwischen diesen beiden Ansichten, indem man der Führungsebene die Kontrolle über zwei wichtige Punkte im Entscheidungsprozess gibt. Der erste ist die Gesamtvision über das Produkt und der zweite sind die spezifischen Unternehmensziele, die jedem Team vorgegeben werden.

Es kann jedoch zu Problemen kommen, wenn das Management diese beiden wichtigen Punkte nicht klar genug formuliert, denn dann entsteht eine Grauzone und es ist nicht mehr eindeutig, was das Team selbst entscheiden kann und was nicht.

Die Produktvision beschreibt das Gesamtbild der Zielkunden und die Dienste, die man jedem einzelnen Kundentyp bieten will. Diese Produktvision soll die Unternehmensstrategie unterstützen. Wenn Sie beispielsweise eine Unternehmensstrategie haben, die auf einem Low-Touch Vertriebsmodell (wenig persönlicher Kundenkontakt) basiert, fördert das eine ganz bestimmte Art von Produktvision. Wenn ein Team nun ein Produkt entwickeln möchte, das von der Vision und diesem Modell abweicht, wird es ziemlich schwer sein, das Produkt zu vermarkten.

Die spezifischen Unternehmensziele werden den Teams entweder in Form von priorisierten KPI (Key Performance Indicators – dt.: Leistungskennzahlen) – auch Product Scorecards genannt – oder in Form von OKR (Objectives and Key Results) dargelegt, die ebenso auf verschiedene KPI hinauslaufen. Wenn das Unternehmensziel zum Beispiel ist, die Abwanderungsquote der Kunden erheblich zu senken, ist das der Auftrag für das Team.

Die Teams bekommen die Produktvision und die KPI zwar von der Führungsebene mitgeteilt, es wird aber nicht gesagt, wie sie diese realisieren sollen. Das ist der Punkt, an dem das Team autonom und flexibel arbeiten kann. Ich beschreibe starke Produktteams gerne als Arbeitsgemeinschaft zur Lösung schwieriger Probleme. Die Abwanderungsquote zu senken, kann definitiv eine große Herausforderung darstellen und es gibt wohl unzählige Möglichkeiten, dieses Ziel zu erreichen. Das Gleiche gilt für die Anhebung des “Customer Lifetime Value” (Wert, den ein Kunde über seine gesamte Geschäftsbeziehung für das Unternehmen hat) oder die Senkung der Kundengewinnungskosten usw.

Werden Produktvision und KPI vorgegeben, ist der Unterschied zwischen autonomen Teams und allen anderen, ob es eine Roadmap für das Unternehmen gibt oder nicht. Wenn das Management oder die Stakeholder dem Team eine Liste mit verbindlichen Features vorlegen, mit denen die Kunden und Stakeholder bereits fest rechnen, hat das Team wenig Spielraum, um die beste Lösungsmöglichkeit für die zugrunde liegenden Unternehmensfragen zu finden (ganz zu schweigen von wirklich grundlegenden Themen).

Und genau deshalb bin ich so froh über das Wiederaufleben der OKR. Wenn sie richtig angewendet werden, helfen sie nämlich dabei, diese Situation vom Output (Features auf den Roadmaps) bis hin zum Outcome (Geschäftsergebnisse) neu auszurichten.

2 Sonderfälle

Es gibt zwei Sonderfälle, die es sich lohnt, zu erwähnen, weil sie sehr häufig für Stress im Unternehmen sorgen.

Der erste Sonderfall hat mit Design zu tun. Es gibt keinen Zweifel daran, dass es ein großer Gewinn für ein Team und die Kunden ist, einen Designer in jedem Team zu haben (der kundenorientierte Funktionen übernimmt). Diese Designer gehen eine wirklich enge Verbindung mit ihrem Produkt und den Entwicklern ein und sind erstklassige Teammitglieder. Außerdem versuchen sie nicht, nach einem Modell zu arbeiten, das einer internen Designagentur ähnelt. Wie kann man aber sicherstellen, dass die Designer das Erlebnis für alle Nutzer verbessern wollen und nicht nur für die Ziele des eigenen Teams? Den Nutzern ist Ihre Teamstruktur egal. Wie fördert man aber die Eigenständigkeit und sorgt gleichzeitig für Einheitlichkeit?

Dafür gibt es verschiedene Methoden – vom Einsetzen eines “Design Managers” (bzw. Senior Designers), der die Arbeit aller Designer überprüft und absegnet, bis hin zu einer größtmöglichen Automatisierung mit “Pattern Libraries”, “Style Guides” und “Stylesheets”.

Mit Hinblick auf Selbstständigkeit und Schnelligkeit bevorzuge ich die Automatisierung, weil das Team damit relativ einfach und gut das Design (Interaction und Visual) hinbekommt. Natürlich gibt es gelegentlich auch “Design Debt”, d.h. wir stellen fest, dass das Design überarbeitet werden muss, und das macht man, sobald man das Problem gesichtet hat. Ich mag diesen Ansatz, weil der Design Manager zwar immer noch eine Gruppe guter Designer zusammenstellt aber nicht mehr für jede Kleinigkeit beim Review dabei sein muss (das verlangsamt alles und untergräbt die Autonomie).

Der zweite Sonderfall sind Unternehmensinitiativen. Das sind die Projekte, die immer mehrere Teams umfassen. Ein recht häufiger Fall ist die Internationalisierung. Ein anderer ist das sogenannte “Responsive Design”. Ein weiterer ist, den Mobilmarkt ernst zu nehmen. Ich denke, Sie verstehen, was ich meine. Im besten Fall passen diese Initiativen gut zu den priorisierten KPI jedes Teams und oft gibt es ein konkretes OKR-Ziel für diese Initiative. Man sollte sich aber bewusst sein, dass eine wichtige Initiative nicht immer auch ein eindeutiger Gewinn für jedes einzelne Team ist. Trotzdem muss jedes Team seine Aufgabe erfüllen, weil die Initiative sonst fehlschlägt. Ich sage den Teams dann immer, dass man manchmal einfach seine Aufgabe als Teil des Ganzen erfüllen muss. Das Gute daran ist, dass diese Initiativen wirklich großartig für das Produkt und den Kunden sind, also können wir immerhin damit zufrieden sein.

Fazit zur Autonomie vs. Auftrag

Wenn Ihre Teams also nicht das Gefühl haben, ausreichend Eigenverantwortung zu haben, dann müssen Sie jedem Team eine eindeutige Produktvision und unmissverständliche und priorisierte Geschäftsziele vorgeben. Der darin enthaltene Kontext ist der Auftrag des Teams. Sorgen Sie dafür, dass die Teams diesen Auftrag verstehen und geben Sie ihnen so viel Spielraum wie möglich, um ihren Auftrag erfüllen zu können.

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

Produktvision erstellen

=> Product Vision Canvas - Die Anleitung zur Produktvision.

Certified Scrum Master Training

=> Werde zertifizierter Scrum Master bei der Agile Academy!

Agile Metriken richtig nutzen

=> Welche Kennzahlen solltest du als scrum Master kennen?