Bist du schon mehr als drei Jahre Scrum Master? Dann kommt dir dieser Dialog bestimmt bekannt vor:
Du: „Hey, Team. Seit dem letzten Scrum-Guide-Update brauchen Scrum Teams ein Produkt-Ziel. Wir haben noch keines. Wollen wir es definieren?“ Team: „Nein, danke. Wir haben bereits genügend Ziele.“
Es gibt eine einfache Erklärung, warum dieses Vorgehen nicht funktioniert. Es hat etwas mit Spaghetti zu tun.
Vor einiger Zeit waren meine Frau und ich beim Italiener essen. Wir saßen am Fenster und hatten gleichzeitig einen guten Blick auf den Steinofen in der Mitte des Restaurants. Von meinem Platz aus konnte ich den Pizzabäckern bei der Arbeit zusehen, was mich bereuen ließ, Spaghetti gewählt zu haben. Plötzlich riss mich meine Frau aus meinen Tagträumen. Sie deutete auf mein Kinn und sagte: „Schatz, du hast da was. Mach es weg.“ Da ich nichts sehen konnte, stand ich auf und ging zur Toilette. Als ich die verirrte Tomatensoße auf meinem Kinn im Spiegel sah, wusste ich, was sie gemeint hatte, und griff zu den Papiertüchern.
Dies bringt uns zurück zur eigentlichen Frage: Wie kannst du deinem Team helfen, ein Produkt-Ziel einzuführen? Wie bringst du sie dazu, zu beurteilen, ob sie die richtigen Arten von Zielen im Unternehmen haben? Wie findet ihr heraus, ob es Schwachstellen in der Verbindung von Unternehmens- und Teamzielen gibt?
Konzentriere dich auf die Probleme, die alle sehen können.
Ich entfernte die Soße erst, als ich sie selbst sah, und nicht als meine Frau mich darauf hinwies. Was bedeutet das? Wenn du Produkt-Ziele einführen willst, dann musst du jedem im Team helfen zu sehen, was du siehst. Dinge, die andere Menschen nicht sehen, werden sie nicht verändern.
Willst du Veränderung, dann musst du ihr Spiegel sein!
Möchtest du einem Team helfen, Löcher in der Ziellandschaft zu entdecken, dann habe ich einen Spiegel für dich. Ich nenne ihn die Ziele-Portfolio-Analyse.
Diese Analyse besteht aus der Aufteilung der Ziele in zwei Kategorien, und am Ende entsteht eine Tabelle, die das Portfolio der Ziele im Unternehmen sichtbar macht. Ich habe dieses Werkzeug schon bei vielen Teams und Unternehmen verwendet und da es universell funktioniert, erkläre ich es auch den Teilnehmern meines „PAL-EBM“-Trainings.
Kategorie 1: Der Grad der Unsicherheit bestimmt das Ziel
Wir können Ziele anhand des Grades der Unsicherheit, ob und wann wir sie erreichen werden, in drei Gruppen einteilen:
- Strategische Ziele: Diese Ziele beschreiben etwas Wichtiges, das das Unternehmen erreichen möchte. Sie sind ambitioniert und weit entfernt. Bis strategische Ziele erreicht werden, gibt es noch viele Unsicherheiten zu überwinden.
- Da strategische Ziele ehrgeizig und der Weg dorthin unsicher sind, benötigt das Unternehmen eine Reihe von praktikablen Zielen. Es handelt sich hierbei um Zwischenziele. Werden sie erreicht, erhält das Unternehmen eine Rückmeldung, dass es sich dem strategischen Ziel nähert.
- Der Weg zum mittelfristigen Ziel ist immer noch nicht komplett bekannt. Deshalb benötigt man auch noch unmittelbare Ziele. Es handelt sich hierbei um zeitnahe Ziele, auf die ein Team hinarbeitet. Werden sie erreicht, hat das Team Fortschritte zum Zwischenziel gemacht.
Kategorie 2: Die Art des Ziels bestimmt die Autonomie des Teams
Die zweite Kategorie beschreibt nicht den Grad der Unsicherheit oder den zeitlichen Horizont, sondern die Autonomie, die sie dem Team ermöglicht.
Betrachten wir dazu das „Program Logic Model“ der W. K. Kellogg Foundation. Es handelt sich hierbei um eine einfache und weitverbreitete Form eines grafischen Wirkungsmodells. Es veranschaulicht die Wirkungsweise einer Dienstleistung oder eines Projekts als linearen Zusammenhang von Ursache und Wirkung.
Das Grundgerüst besteht aus fünf Elementen:
- Ressourcen und Inputs: Die Dinge, in die das Unternehmen investiert.
- Aktivitäten: Hierbei handelt es sich um Dinge, die Menschen in der Organisation tun.
- Outputs: Das sind die Dinge, welche die Organisation produziert.
- Outcomes: Dies sind Verbesserungen, die der Nutzer der Dienstleistung oder des Produkts erfährt.
- Impacts: Ein Impact drückt aus, welche Auswirkungen die Verbesserungen für Nutzer und Kunden auf das Unternehmen haben.
Die letzten vier Elemente des Modells helfen uns, Ziele zu beschreiben. Ein Ziel kann beschreiben, was Menschen tun sollen, was produziert werden soll, welche Verbesserung der Nutzer erfahren soll oder welches Ergebnis für das Unternehmen eintreten soll.
Damit können wir sehen, wie die unterschiedlichen Ziele einen unterschiedlichen Grad an Autonomie zulassen. Ein Ziel, das eine Aktivität beschreibt, gibt den Entwicklern keinen Handlungsspielraum, außer diese Aktivität zu tun. Ein Ziel, das hingegen einen Output beschreibt, gibt dem Team die Möglichkeit zu wählen, welche Aktivitäten diesen Output ermöglichen. Ein Ziel, das einen Outcome beschreibt, lässt die freie Wahl, welcher Output durch welche Aktivität produziert werden soll. Schlussendlich lässt ein Impact-Ziel die Wahl, welche Kombination aus Outcome, Output und Aktivität diesen Impact erzielt.
Werkzeug: Ziele-Portfolio-Analyse
Mit diesen beiden Kategorien lässt sich eine Ziele-Portfolio-Analyse erstellen.
Die vertikale Achse beschreibt die Autonomie, die ein Ziel ermöglicht. Also Aktivität, Output, Outcome oder Impact. Die horizontale Achse beschreibt den Grad der Unsicherheit, der bei der Erreichung des Ziels herrscht. Also strategisches Ziel, Zwischenziel und unmittelbares Ziel.
Es ergibt sich folgende Matrix:
Wenn du auf dieser Matrix die Team- und Unternehmensziele einträgst, erhältst du einen Spiegel, der das Ziele-Portfolio des Unternehmens widerspiegelt.
Damit lassen sich Schwachstellen in den Unternehmenszielen aufdecken. Betrachten wir etwa diese Situation:
Hieraus können wir schließen, dass ein Zwischenziel fehlt, um zu bewerten, ob Fortschritte bei der Erreichung des strategischen Ziels gemacht werden. In Scrum nennen wir ein solches Zwischenziel ein Produkt-Ziel. Es sollte einen Outcome beschreiben, um dem Team genug Autonomie zu geben, herauszufinden, wie es das strategische Ziel beeinflussen kann.