Warum braucht es Ziele und Zielsysteme? Wo liegen die Ursprünge? Und was wollen wir im Agilen Kontext nutzen? Dieser Talk schaut sich an, was es neben OKR denn noch so an agilen Zielsystemen gibt und zeigt auf, auf was du alles achten solltest.

1. Alles OK(R) oder was?
Zielsysteme im Agilen
Björn Scho+e, MAYFLOWER GmbH
Willkommen zur Zielsystem- und OKR-Selbsthilfe-Gruppe. :-)

2. WIR FÜHREN UNTERNEHMEN IN DIE ZUKUNFT - MIT
MODERNEN TECHNOLOGIEN UND AGILER ORGANISATION
AGIL SEIT 15JAHREN
SOFTWARE-
DEVELOPMENT
TECH-CONSULTING
AGILE BERATUNG,
COACHING & TRAINING
CLOUD
Ich bin Gründer und Geschäftsführer bei MAYFLOWER. Unsere Vision ist, Unternehmen in die (digitale) Zukunft zu führen. Das tun wir, indem wir moderne Technologien
und Agile Organisation einsetzen. Damit unsere Kunden in ihren dynamischen Märkten innovativer sein können, dank zuverlässiger und maßgeschneiderter Software.
Wir sind seit 15 Jahren Agil, und lernen immer noch. Unser Kerngeschäft bilden Software-Entwicklung in agilen, echt crossfunktionalen Teams, Technologie-Consulting/
Architektur, Agile (Management) Beratung sowie Cloud-Infrastrukturen.
Warum lernen wir immer noch? Nun, 2004 dachten wir: Wenn wir 14 Leute auf eine Scrum Master Schulung schicken, dann werden unsere Projekte mit unseren Kunden
viel viel besser laufen. ;-) Im Laufe der Zeit merkten wir natürlich, dass das zu kurz gesprungen ist. Und so sammeln wir viel Erfahrung und geben diese auch in Form von
Beratungen weiter.

3. AGENDA
• Ursprünge von Zielsystemen
• Wozu Ziele und Zielsysteme?
• Ziele im Agilen: Warum und Wozu
• Ziele und Zielsysteme: Beispiele
• Fazit
Ich möchte mich nicht nur auf OKR beschränken. Auch wenn OKR gerade einen großen Hype erlebt. Übrigens, wir nutzen OKR ebenfalls - und lernen immer noch. ;-)
Im Verlauf der Slides wirst Du einige Elemente vorfinden, von denen Du bestimmt denkst: „Was soll das? Das sind doch Basics!“ - Jedoch: Auch in diesen Basics kann
man Ziele und ein Zielsystem entdecken.
Auf diese Entdeckungsreise möchte ich Dich nun mitnehmen. Und Hinweise geben, wie Du Denk-Fallen umschiffen kannst.

4. URSPRÜNGE DER
ZIELSYSTEME
Wo kommen Ziele und Zielsysteme im Wirtschaftsleben denn eigentlich her? Dazu möchte ich Dir zwei Menschen vorstellen.

5. „Plans are worthless, but planning is
everything.“ - Dwight D. Eisenhower
Dwight D. Eisenhower ist der Erste. Von ihm ist der oben stehende Satz überliefert.
Pläne überleben also nur bis zum ersten Kontakt der Realität. Und dennoch ist Planung sehr wichtig.
Mit dem ersten Kontakt der Realität ist in unserem Kontext gemeint: Bis zur Auslieferung des Features an den Anwender. Deswegen ist es so wichtig, möglichst schnell
eine Funktion an den Anwender auszuliefern, gerne auch in einer niedrigen Ausprägung, damit wir unsere Annahmen validieren können.

6. Management by ObjecXves
Peter Drucker kennen sicherlich viele. Von ihm stammt das Konzept Management by Objectives, das ich im Folgenden kurz vorstellen.

7. MbO: Grundprinzip
• Strategische Ziele des Unternehmens und der
Mitarbeiter umzusetzen
• SUM(Einzelziele) = GesamtzieleUnternehmen
• Dient der Mitarbeiterbeurteilung
Das Grundprinzip von MbO ist schnell erklärt: Es soll dazu dienen, strategische Ziele des Unternehmers und der Mitarbeiter umzusetzen. Dabei ergibt die Summe der
Einzelziele die Gesamtziele des Unternehmens. Zudem dient es der Mitarbeiterbeurteilung durch Vorgesetzte.
Ihr merkt schon, da steckt eine ganze Menge Sprengstoff im Kontext Agiler Organisation drin.

8. MbO: Schwierigkeiten (I)
• Enorm aufwändig, Ziele zu durchdenken/
diskuNeren/planen/abzuschätzen/präzisieren, bis sie
realisNsch und umsetzbar sind
• An sich einfaches führt zu komplexem Programm mit
hohem Zeit-/Verwaltungsaufwand für FKs
• Zu viele Ziele vereinbart; das wirklich WichNge gerät
aus dem Fokus
Eine der Schwierigkeiten bei MbO ist der enorme Aufwand, mit dem Ziele so erdacht und ausgestaltet werden, dass sie realistisch und umsetzbar sind. Was also als an
sich einfaches Verfahren gedacht war, gestaltet sich in der Praxis oft sehr komplex und führt zu einem hohen Zeit- und Verwaltungsaufwand nicht nur für die
Führungskraft (FK), sondern auch für den betroffenen Mitarbeiter. „Und das soll ich jetzt auch noch neben meinem Tagesgeschäft machen?“, hört man häufig die Leute
stöhnen. Nicht zuletzt, weil auch viel zu viele Ziele vereinbart worden sind, womit das wirklich Wichtige aus dem Fokus gerät.

9. MbO: Schwierigkeiten (II)
• Ziele werden autoritär aufgeprägt
• Ziele dienen nicht als MiUel der Selbst-Steuerung,
sondern als MiUel der Kontrolle durch den
Vorgesetzten
• Häufig verknüpX mit (individuellen) monetären Boni
Weiter werden Zielvereinbarungen bei MbO autoritär aufgeprägt. Eine zumindest teilweise Partizipation (und damit den Betroffenen zum Akteur zu machen) fehlt häufig.
Ziele werden also nicht als Selbststeuerungs-Instrument verstanden, sondern als Mittel der Kontrolle durch den Vorgesetzten.
Zudem gibt es die Eigenart, dass dies häufig mit (individuellen) monetären Boni verknüpft ist. In Folge davon optimiert der Mitarbeiter auf seinen Bonus - selbst wenn das
vereinbarte Ziel in der Zwischenzeit gar nicht mehr sinnvoll für das Unternehmen ist - und nicht mehr auf das, was für das Unternehmen wichtig ist.
Liebe OKR-Enthusiasten: Wenn Ihr an all diese Schwierigkeiten bei MbO denkt, dann vermeidet bitte Ähnliches beim Einsatz von OKR. ;-)

10. WOZU ZIELE &
ZIELSYSTEME
Bevor wir uns dem Thema Ziele & Zielsysteme im Agilen nähern, möchte ich kurz darstellen, was denn aus meiner Sicht die wichtigsten Aspekte für Zielsetzungen und
Zielsysteme sind.

11. Komplexität & Dynamik
Wer von Euch plant in 3-, 5- oder 10-Jahres-Schritten in der Organisation? Richtig, zunehmende Komplexität sowie Dynamik an den Märkten (zB mangelnde
Vorhersagbarkeit des Kundenverhaltens und damit direkte Auswirkung auf die Bottom Line der Organisation) machen es notwendig, dass mehr Dezentrales Verhalten &
Entscheidungen praktiziert wird.
Gleichzeitig ist es allerdings wichtig, eine gemeinsame Ausrichtung zu erreichen (dazu in einer späteren Folie mehr). Was wie eine Unvereinbarkeit erscheint, ist in
Wirklichkeit nicht unvereinbar.
Denn durch die Gestaltung eines cleveren Zielsystems, das Top-Down-Ansätze mit Bottom-Up-Ansätzen kombiniert, kann Flexibilität & Schnelligkeit durch Dezentralität
bei gleichzeitiger Richtungslenkung zu den gemeinsamen Zielen erreicht werden.
Wer plant schon noch in 5- oder 10-Jahres-Scheiben, im Glauben, dass das alles so eintreten wird?

12. Fokussierung auf das
Wesentliche
Ein weiterer Grund ist, sich auf das Wesentliche fokussieren zu können. Was sind die wirklich wichtigen Dinge, die wir erreichen wollen? Was schafft Wert? Welchen
Impact wird das, was wir bearbeiten wollen, haben (kurz-/mittel-/langfristig)?
Das Setzen von Zielen und das Ausgestalten cleverer Zielsysteme hilft uns, auf unterschiedlichen Ebenen (man selbst, ein Team, eine Organisationseinheit, die gesamte
Organisation) diese Fragen zu beantworten.

13. Ausrichtung
In Organisationsbereichen und der Gesamtorganisation ist es wichtig, eine gemeinsame Ausrichtung zu erreichen, um einen höheren Impact zu erzeugen. Das
ermöglichen wir mit cleveren Zielsystemen.
Wichtig ist dabei das „Schneiden“ in den Zielstrukturen. Das muss jede Organisation für sich herausfinden & erlernen. Deswegen ist es wichtig, dass Zielsysteme über
geeignete und regelmäßige Reflexionsmechanismen verfügen, anhand derer man die eigene Ausrichtung überprüfen und ggf. abwandeln kann.
Vorbei sind also die Zeiten von 5- und 10-Jahresplänen. ;-)

14. Klärung:
Warum und Wozu machen wir X?
Etwas, das immer gilt, ist: Sich Gedanken darüber machen, Warum und Wozu wir etwas nutzen wollen.
Wenn bei Euch also der OKR-Hype durch das Unternehmen stiefelt: Warum und Wozu wollt Ihr das einsetzen? Gibt es vielleicht etwas Besseres, was mehr zu Euch
passt? Warum und Wozu wollt Ihr X machen?
Das ist eine wichtige Leitfrage, die beantwortet werden sollte. Es ist dabei nicht so wichtig, ob Ihr mit der Antwort „richtig“ liegt. Viel wichtiger ist nämlich, dass damit ein
Dialog ermöglicht wird, der Euch hilft gemeinsam zu vereinbaren, was Ihr nutzen wollt und wie Ihr es nutzen wollt.

15. ZIELE IM AGILEN
Wie steht es denn nun um Ziele & Zielsystemen in einem Agilen Kontext? Dazu vielleicht noch eine wichtige Frage: Was ist denn ein Agiler Kontext?
Nun, im Wesentlichen geht es darum, dass Du und Dein Unternehmen in komplexen Systemwelten operieren. Wenige Sachen sind vorhersagbar. Man sagt auch: Der
Zusammenhang zwischen Ursache und Wirkung sind aufgehoben.
Daher benötigen wir Handlungsrahmen und Werkzeuge, die uns einen Umgang in diesen Welten ermöglichen. Meist sind es empirische Ansätze: Wir machen also Etwas,
und dann schauen wir kurz danach mal rein, was ist denn eigentlich alles so passiert. Ziehen Rückschlüsse daraus (neue Hypothesen/Wetten, Erkenntnisse, …) und
passen so unser nächstes Handeln an. Salopp gesagt: Wir nehmen uns Etwas (kleines) vor, probieren das aus („verproben es“), schauen uns das Ergebnis an und gucken
mal, was wir anpassen müssen - für das, was wir Erreichen wollen.
Darüber hinaus kann es passieren, dass das, was wir Erreichen wollen, sich auf dem Weg dahin verändert. Vielleicht weil unsere Kunden sich verändern. Oder weil wir
(auf dem Weg!) feststellen, dass das Ziel, das wir uns zuvor ausgedacht haben, gar nicht mehr so statthaft ist. Und wir unser Ziel abändern müssen.
Scrum ist zum Beispiel ein Rahmenwerk, das solch ein Handeln ermöglicht. Und Zielsetzungen und Zielsysteme müssen ebenfalls auf diese Form von Umwelt und das
darin stattfindende Handeln passen. Das ist auch der Grund, warum MbO in der klassischen Form nicht (mehr) funktioniert. Also, schauen wir doch mal rein, was wir im
agilen Kontext so brauchen.

16. Eine Frage der Haltung.
Zunächst einmal ist das eine Haltungsfrage. Ich meine das wirklich so. Wenn wir daran glauben, dass das Denken die Richtung bestimmt, dann ist es wichtig, mit welcher
Denk-Haltung wir an die ganze Sache heran gehen.

17. Wir wollen was erreichen. Nicht schlimm,
wenn wir #failen. Wir lernen dazu. Um zu
adapXeren und uns neu auszurichten.
Natürlich ist es so, dass wir Etwas erreichen wollen. Ziele und Zielsysteme sind per se sinnvoll. Ich hatte es unter den Aspekten von Fokus und Ausrichtung sowie
steigender Komplexität und Dynamik ja bereits im Kern begründet.
Gleichzeitig ist es so, dass wir mit der Haltung herangehen sollten, dass es nicht total schlimm ist, wenn wir die Ziele nicht erreichen. Denn es geht darum, etwas zu
Lernen. Damit wir uns adaptieren und uns neu ausrichten können.
Der Unternehmer in mir möchte noch ergänzen: Und natürlich wäre es total wichtig, schon auf dem Weg zum Ziel zu erkennen, dass wir das Ziel möglicherweise nicht
erreichen. Und dann zu adaptieren und sich neu auszurichten - und nicht erst am Ende der eingeplanten Zeit ;-)
Daher machen 3-, 5- oder 10-Jahres-Pläne ja auch keinen Sinn mehr.

18. FailenLernen, um sich zu verbessern.
Um Geilere Produkte zu bauen.
Wir wollen also Lernen, um uns zu verbessern.
Warum eigentlich? Wir bauen zB digitale Produkte. Und die sollen „geiler“ werden. Und zwar nicht, weil der Ingenieur in uns das so möchte, sondern damit unsere
Produkte die Probleme unserer Kunden besser lösen. Wer mehr dazu wissen möchte: Jobs-to-be-Done ist eine Möglichkeit, unser Denken in diese problemlösende
Richtung zu denken.

19. Ohne individuelle Boni oder harte
Constraints in Mitarbeiterbeurteilung
Was wir auf keinen Fall benötigen, sind Ziele mit individuellen Boni. Teamziele können Sinn machen. Monetäre Boni, die den Unternehmenserfolg beinhalten:
Einverstanden. Doch bitte keine individuellen Boni. Die verführen meist dazu, dass der Mitarbeiter auf den Bonus optimiert - und nicht auf das, was Sinnvoll wäre.
Auch das Eins-zu-Eins Beurteilen von Zielen im Kontext einer Mitarbeiterbeurteilung: Lasst das sein. Viel wichtiger ist die Frage: „Ok, das Ziel haben wir nicht erreicht /
werden wir nicht erreichen. Was lernen wir daraus und was machen wir jetzt anders?“ - incentiviert (nicht monetär!) lieber diese Form von Fragestellungen / Outcomes.

20. BEISPIELE FÜR
ZIELE & ZIELSYSTEME
Im Folgenden stelle ich einige Beispiele für Ziele und ihre Zielsysteme vor.

21. Vision / Nordstern

22. Vision: Grundprinzip
• „Wir führen Unternehmen in die ZukunX - mit
modernen Technologien und Agiler OrganisaNon“
• Wie ein Nordstern: LangfrisNges Streben danach
• Prägnant, und mit weiteren Texten erläuternd
• Antwort auf „Warum bin ich hier?“, „Wozu dient die
OrganisaNon?“, „Was macht die OrganisaNon?“
Das Grundprinzip einer (Unternehmens-)Vision / Nordstern ist, dass sie ein langfristiges Streben danach ermöglicht. Sie ist kurz und prägnant, und wird durch weitere
Erläuterungen „angefüttert“. Sie beantwortet Fragen wie „Warum bin ich hier?“, „Wozu dient die Organisation?“, aber auch „Was macht die Organisation?“.
Ein Beispiel aus der 2019er Mayflower-Edition habe ich oben stehen. Wir verstehen uns als Bergführer und Lotsen. Denn wir wollen Unternehmen in die (digitale) Zukunft
führen. Das machen wir mit modernen Technologien und Agiler Organisation (und dem Wissen um den Umgang in unsicheren Zeiten). Wir realisieren also Software /
(neue) digitale Geschäftsmodelle und bewegen somit die Unternehmen.
Das ist ein Langfrist-Spiel, denn die Unternehmen müssen dazu auch umdenken. Wir helfen ihnen dabei, auch durch die Software-Entwicklung, aber mit noch viel mehr
drum herum - Bergführer & Lotse eben.
Das erreichen wir also nicht sofort.

23. Vision: Vorteile
• SNXet IdenNtät
• Bietet eine Ausrichtung
• Ermöglicht Fokus: Warum & Wozu machen wir Was,
und Was machen wir gerade nicht?
Die Vision stiftet also eine Identität für diejenigen, die in der Organisation mit-arbeiten und der für sie relevanten Umwelt (Kunden/Partner/Lieferanten). Und bietet damit
auch eine Ausrichtung. Gleichzeitig ermöglicht sie einen Fokus: Warum & Wozu sind wir da / machen wir Was? Und Was machen wir gerade nicht?

24. Vision: Obacht!
• Kann ein langer Prozess sein
• Sollte parNzipaNv entwickelt werden
• Sollte in größeren Abständen (2-3 Jahre) einem
Review unterliegen - Inspect & Adapt
• „Wir machen die Welt besser“: GeneraNon-Z-Falle
Worauf solltest du bei einer Visionsbildung im Agilen Kontext achten?
Die Vision sollte partizipativ entwickelt werden. Das bedeutet nicht, dass du - wenn du zB Eigentümer bist - da nicht deine Note mit reinbringst. Mindestens solltest du
dich von deiner Mannschaft beraten lassen, wie dein Visionsvorschlag aufgenommen wird. So kannst du Veränderungen einbauen. Gleichzeitig wird klar, wie hoch die
Chance ist, dass eine Vision auch gelebt werden kann.
Die Vision sollte in größeren Abständen - mehrere Jahre - auf den Prüfstand gestellt werden. Ist das noch das, wonach wir streben wollen oder müssen? Oder hat sich
unser Markt so sehr verändert, dass wir uns neu erfinden müssen?
Wenn du nicht Google, Amazon oder Facebook hast, dann noch meine persönliche Meinung zu „Wir machen die Welt besser“: Das stiftet einerseits für die heutige
sogenannte „Generation Z“ einen hohen Wert. Aber wie hoch ist tatsächlich dein Impact auf die gesamte Welt? Vorsicht also vor Visionszielen, die möglicherweise
schneller von der Realität eingeholt werden, als uns lieb ist. ;-)

25. OKR
Wenden wir uns also dem aktuellen OKR-Hype zu …

26. OKR: Grundprinzip
• ObjecNves + Key Results = OKR
• Company ObjecNves, Team ObjecNves. Alle transparent
• IdenNfikaNon von strategischen Handlungen, operaNve
Ableitung
• IteraNv-adapNver Prozess, zB quartalsweise
• Rituale, um sich gegenseiNg über strategische Absichten zu
informieren, zu challengen und zu vereinbaren, sowie die
abgelaufene IteraNon retrospekNv zu betrachten und
Verbesserungen abzuleiten
… und keine Sorge, ich erkläre dir hier nicht OKR. Dafür gibt es viele Bücher & Blogartikel. Ich beschränke mich auf die Essenz von OKR, die OKR meiner Ansicht nach
darstellt.
OKR besteht aus Objectives und sogenannten Key Results, also die Resultate, anhand derer man sehen kann, ob ein Objective „erfüllt“ wird oder nicht.
OKRs bieten die Identifikation von strategischen Handlungen und ihren daraus abgeleiteten operativen Handlungen.
OKRs unterliegen einem iterativ-adaptiven Prozess, ähnlich wie beim Rahmenwerk Scrum. Es gibt eine Reihe von Ritualen, die dazu dienen
- sich gegenseitig über die strategischen Absichten zu informieren & zu challengen („ist dein Objective wirklich im Sinne der Firmenziele? Wenn du das so-und-so
anpasst, würdest du viel besser darauf einzahlen“)
- sich nach der gegenseitigen Information und dem Austausch/Challenging darüber zu vereinbaren
- Synergieeffekte zu entdecken und darauf einzuzahlen (also zu kooperieren, zB „Hey, du hast Ziel X, das auf das Company-Objective einzahlt. Wir helfen dir dabei mit
unserem neuen Ziel Y, weil wir dann mehr Impact für die Company erzeugen“)
- in kleinen Iterationen (meist 3 Monate, und nicht Jahre) zu denken, zu retrospektieren und Verbesserungen abzuleiten
Soviel zum Grundsatz.

27. OKR: Einsatz/Vorteile
• Dient nicht der Mitarbeiterbeurteilung
• Team ObjecNves können, aber müssen nicht auf
Company ObjecNves einzahlen
• ObjecNves/KRs sind Moonshots: Wir wissen, dass wir
sie nicht alle vollständig erreichen. Denn wir wollen
gemeinsam lernen
• Ideal für Silo-OrganisaNonen, um einzelne Abteilungen
auf eine Richtung, zB für das Produkt, zu fokussieren
Die wesentlichen Vorteile von OKR als Zielsystem sind schnell benannt.
Die Moonshots scheinen mir noch gesondert erwähnenswert: OKRs sollten so definiert sein, dass klar ist, dass das nur sehr schwer erreichbare Ziele/Resultate sind. Und
es ist völlig okay, wenn ein Key Result nur zu 40 oder 50 Prozent erreicht wurde. Denn da wart Ihr schon ziemlich gut! (Böse Zungen würden jetzt behaupten, dass die
KRs dann ja nur Karotten seien, die man den Mitarbeitern hin hängt ;-) )
Durch die Verkettung auf allen Ebenen - TopDown wie BottomUp sowie „seitlich“ - eignet sich OKR besonders gut für Produkt-Organisationen, die typischerweise als
Matrix-Organisation mit entsprechenden Silos (zB Marketing, Vertrieb, Produktmanagement, Entwicklung, …) ausgelegt sind. Denn dadurch wird eine Ausrichtung auf
das Produkt fokussiert, indem die eigenen Ziele auf das gemeinsame Produkt (und damit auf das Objective des zB Geschäftsbereichs) ausgerichtet werden. Ohne
Vorgaben von oben, sondern im Sinne eines Schulterschlusses zwischen den einzelnen Abteilungen.

28. OKR: Obacht!
• Nicht zu viele ObjecNves/Key Results
• Keine Leistungsshow daraus machen
• Warum & Wozu des OKR-Einsatz klären
• Effizient & EffekNv darüber reden ;-)
• Alle OKRs für Alle sichtbar machen! (Dialog)
• Nicht in Hierarchien denken
Worauf solltest du bei OKRs Acht geben?
Macht nicht zuviel. Macht keine Leistungsshow daraus. Findet zusammen heraus, warum Ihr OKRs nutzen wollt. Gestaltet die Rituale so, dass Ihr effizient und effektiv
über die Inhalte sprecht.
Aber das Wichtigste: Macht alle OKRs auf allen Ebenen sichtbar, zB im Wiki! Denn OKRs leben davon, dass es eine Transparenz über die Ziele von Allen gibt. Nur so wird
ein Dialog möglich.

29. Gehng Things Done
Flughöhen
Kommen wir zu Getting Things Done (von David Allen), und zwar zum Aspekt der Flughöhen, die im GTD-Modell eine Rolle spielen.

30. GTD: Grundprinzip
• GTD kennt das Flughöhenprinzip
• Schao Fokussierung auf verschiedenen Ebenen (zB
mein Leben, mein Beruf, meine Ziele in x Jahren, …)
• Daraus leiten sich GTD-Projekte und -Next AcNons
ab
Ich werde GTD nicht grundsätzlich erklären. Du findest viele Bücher und Blogbeiträge, die dies tun.
GTD kennt das sogenannte Flughöhenprinzip (5.000 Meilen, 10.000 Meilen, …), um auf verschiedene Aspekte des eigenen Lebens, Berufs, persönliche/berufliche Ziele
und ähnliches zu blicken. Dies geschieht natürlich iterativ, dh. in regelmäßigen Abständen.
Im Rahmen dieses Perspektivenwechsels ergeben sich somit eigene GTD-Projekte sowie Next Actions. Diese passen sich also der Zielrichtung, die sich auf Basis der
Flughöhen-Betrachtung ableiten, entsprechend an.

31. GTD: Einsatz/Vorteile
• „Mind like water“ + „Building a trusted system“
• Verwendung der Flughöhen zwingt dich zum
PerspekNvenwechsel
• PerspekNvenwechsel ermöglicht dir, neue Aspekte
für dein Handeln zu entdecken

32. GTD: Obacht!
• Vorsicht vor zuviel kleinteiliger Aufgaben-Planung
• Flughöhen regelmäßig reflekNeren: Wissen, dass der
persönliche 5- oder 10-Jahres-Plan sich schneller
ändern kann, als einem vermeintlich lieb ist
Worauf du achten solltest: Gleite nicht in eine zu kleinteilige Planung ab. Agile GTD Practitioner kombinieren hier GTD-Vorgehen zusammen mit (Personal) Kanban.
Flughöhen sollten regelmäßig reflektiert werden. Denn deine Langfrist-Pläne können sich natürlich auch schon mal ändern. Und dennoch ist es gut, eine Vorstellung auf
lange Sicht zu haben - in dem Wissen, dass diese sich ändern können.

33. Product Vision
Die Agile Product Vision ist ebenfalls ein Zielsystem. Lass uns da mal reinschauen.

34. Product Vision
• Klarheit: Was ist unser Produkt? Für wen? Was ist es
nicht? Was sind unsere USPs?
• LeichtgewichNg aufgeschrieben. Wenige Zeilen.
Hier habe ich ein Beispiel eines Produkts - unserer Veranstaltung https://productowner.camp/ - aufgeführt (einer ältere Variante der Product Vision).
Die Product Vision ist einfach aufgebaut. Sie schafft Klarheit in wesentlichen Fragen der Zielgruppe, des Mitbewerbs, des eigenen USPs. Sie hilft uns, unser Produkt (in
diesem Fall eine Veranstaltung) gut verorten zu können.
Du findest viele Quellen zum Aufbau einer Agile Vision. Im Blog von Roman Pichler findet sich eine andere Variante davon. Egal, welche Du nimmst: Allen ist gemein, dass
sie prägnant und knapp formuliert sind.
Denn, Du hast es schon geahnt: Auch Product Visions können sich ändern und sollten regelmäßig angepasst werden.

35. Product Vision: Einsatz/
Vorteile
• HilX, den Kern des Produkts herauszuarbeiten
• Ist leichtgewichNg und anpassbar
• Enthält alles, was es für das Flughöhen-Verständnis des
Produkts braucht
• SNXet IdenNfikaNon für Alle an der Produktentwicklung
beteiligten
• Das Produkt kann auch zB eine Veranstaltung, eine
Website, … sein
Bei der Product Vision handelt es sich um ein Flughöhen-Verständnis Deines Produkts.
Es stiftet Identifikation für Alle an der Produktentwicklung beteiligten Personen.
Wichtig ist, dass das gesamte Produktentwicklungsteam (inkl. Software-Entwickler) an der Erstellung der Product Vision beteiligt sind. Das schafft Identifikation im
gesamten Team, und jeder weiß, Warum und Wozu das Produkt entwickelt wird.

36. Product Vision: Obacht!
• ParNzipaNv entwickeln & reviewen
• Product Vision regelmäßig reviewen und anpassen
• Keine ellenlangen USP-Listen
• Keine seitenlangen MarkeNng-Personas
• Länger als eine „halbe Wiki-Seite“? Weg damit!
Hier findest du einige Punkte, auf die Du Acht geben solltest, wenn Du eine Product Vision entwickelst. Kleine Faustregel: Ist sie länger als eine „halbe Wiki-Seite“ (oder
ein halber Laptop Screen ;) ), dann hast Du möglicherweise schon zuviel aufgeschrieben.
Natürlich gibt es noch alternative Werkzeuge, die Du nutzen kannst. Wenn du in das Feld von Lean Canvas & Co. schaust, findest Du ebenfalls schlanke, schnelle
Werkzeuge, um eine Zielrichtung für ein Produkt oder Geschäftsmodell zu finden.

37. Sprint-Ziel
Hey, auch Sprint-Ziele können ein Zielsystem sein. ;-) Lass uns mal reinschauen.

38. Sprint Ziel: Grundprinzip
• Was wollen wir im kommenden Sprint (14 Tage)
erreichen?
• Fokussierung für Product Owner & Team für die
Auswahl der zu realisierenden User Stories
Mehr ist nicht zu sagen. Die Grundidee ist, sich zu überlegen, was in der kommenden Iteration erreicht werden soll. Das dient der Fokussierung des gesamten Teams und
hilft bei der Auswahl der zu realisierenden User Stories bzw. Sprint Backlog Items.

39. Sprint Ziel: Einsatz/Vorteile
• Ermöglicht einen Dialog zwischen PO und
Stakeholdern (Anwender, Team, interne Abteilungen)
über die Ausrichtung der kommenden Wochen
• Prüfen: Habe ich das RichNge ausgewählt?
Mit dem Sprint-Ziel lässt sich vorab prüfen, ob die „richtigen“ Backlog Items für den Sprint ausgewählt wurden.
Gleichzeitig ermöglicht es einen Dialog mit den Stakeholdern über die Ausrichtung der kommenden 1-2 Sprints.

40. Sprint Ziel: Obacht!
• Maintenance / „TagesgeschäX“ in der Entwicklung kann
das Formulieren griffiger Sprint-Ziele stören
• Keine zu großen Ziele definieren -> erzeugt
Erwartungshaltung („Warum habt Ihr das nicht
geschao? 111Doof!“)
• ParNzipaNon mit dem Team: Das Team einbinden
• Sprint-Ziel als Selbstkontroll-Instrument für das Team
• In RetrospekNven reflekNeren
Worauf solltest du achten? Halte die Sprint-Ziele oder das jeweilige Sprint-Ziel nicht zu Groß.
Wenn das Team sowohl „Tagesgeschäft“-Items als auch Neuentwicklung von Features macht, kann das die Formulierung von Sprint-Zielen erschweren.
Hilfreich ist es, das Sprint-Ziel vorab zu definieren, bevor Backlog Items ausgewählt werden.
Gleichzeitig ist das Sprint-Ziel ein gutes Selbstkontroll-Instrument für das Team und kann in Retrospektiven reflektiert werden („Warum haben wir ein Sprint-Ziel nicht
erreicht? Hat die ‚Mischung‘ der Backlog Items gestimmt? Zeigt das Sprint-Ziel auf, dass wir Value liefern?“).

41. User Story
Tja. Auch eine User Story enthält Ziele. :) Lass uns das mal näher betrachten.

42. User Story: Grundprinzip
• „As <…> I want <…> so that <…>“
• Ziel: Wert für den Anwender schaffen
• Werterzeugung ist explizit enthalten
In der griffigen Formulierung einer User Story ist ein Ziel - die Wertschöpfung - enthalten. Sie findet sich im Teil „… so that <…>“ wieder.
Die Werterzeugung ist explizit in der Formulierung der User Story enthalten. Und damit auch die Zielrichtung.

43. User Story: Einsatz/Vorteile
• Fokussiert auf die Werterzeugung
• Zu bauende FunkNonalität ist „means to an end“
• Knapp und präzise formuliert
• 3C - Card, ConversaNon, ConfirmaNon
Die User Story fokussiert somit. Das, was gebaut werden soll, ist damit „means to an end“.
Gleichzeitig ist sie knapp und präzise formuliert.
Es gilt 3C - sie soll auf eine Karte passen. Sie soll einen Dialog aller Beteiligten ermöglichen, um sich auszutauschen. Um dann eine gemeinsame Sicht (Confirmation) zu
haben, Was Wozu realisiert werden soll.

44. User Story: Obacht!
• Die User Story ist kein Vertrag od. seitenlanges
Requirements-Dokument
• Kleine Einheit, schnell Formulieren, Fehler in Kauf
nehmen
• Der Plan überlebt nur bis zum Kontakt mit der Realität
(Endanwender)
• Hilfreich: Hypothesen hinzufügen und diese mit Going-
Live validieren. x mal am Tag. (ConNnuous Delivery?)
Worauf sollte geachtet werden?
Insbesondere im Management entstehen viele Mißverständnisse: Die User Story ist kein Vertrag oder seitenlanges Requirements-Dokument.
Sie soll klein sein, schnell formuliert werden. Gleichzeitig sollen Fehlannahmen in Kauf genommen werden, denn das Lernen passiert durch den Aufprall mit der Realität:
Dem Kontakt mit dem Endanwender, der letztlich aufzeigt, ob es einen Value bringt oder nicht.
Hilfreich ist es hierbei, hypothesengetrieben zu arbeiten. Dies unterstützt eine Lern-basierte Denke.

45. Daily

46. Daily: Grundprinzip
• KoordinaNons-Treffen des Produktentwicklungs-
Teams
• Austausch der Pläne/Absichten des heuNgen Tages,
KoordinaNon untereinander, gegenseiNge
Unterstützung, Aufdecken von Hindernissen
Zum Daily gibt es nicht viel zu sagen. Es ist ein Koordinations-Treffen des Produktentwicklungs-Teams. Dort werden die Pläne/Absichten des heutigen Tages
ausgetauscht. Es dient der Koordination untereinander, der gegenseitigen Unterstützung und dem Aufdecken von Hindernissen.

47. Daily: Einsatz/Vorteile
• Das Entwicklungsteam richtet seine individuellen KräXe
auf das, was im Team zu tun ist, aus
• Anstehende Arbeiten werden untereinander koordiniert
• Hindernisse werden transparent gemacht
• Das Treffen ist fokussiert und effizient (15 Minuten)
• Es fällt auf, wenn Vorhaben nicht realisiert werden
können - das Team kann sich untereinander helfen oder
die „Reissleine“ ziehen
Das Daily hilft, eine gemeinsame Ausrichtung der individuellen Kräfte auf das, was zu tun ist, zu erreichen. Es ist fokussiert und effizient - und dauert maximal 15 Minuten.
Es wird transparent - „es fällt auf“ - wenn Vorhaben nicht realisiert werden können. Idealerweise kann sich das Team untereinander helfen, oder die „Reissleine“ ziehen.
Es werden also Ziele für den Tag geplant, und somit eine Struktur geschaffen.

48. Daily: Obacht!
• Daily ist kein Vorgesetzten-ReporNng
• „Walk the board“ hilX, sich auf die Work Items zu
konzentrieren. Vermeidet Laber-Runden sowie
ReporNng-Gefühl
Das Daily ist kein Vorgesetzten-Reporting. Gleichzeitig sollte es für Alle offen sein.
Das bekannte „Walk the board“ hilft, sich auf die Work Items zu konzentrieren. Du vermeidest damit Laber-Runden oder das Entstehen eines Reporting-Gefühls.

49. Spikes

50. Spikes: Grundprinzip
• Aus dem eXtreme Programming (MiUe der 90er-
Jahre)
• Zeitlich gedeckeltes Work Item:
• Was will ich lernen? (zB „Wie können wir das JS-
Framework auf die neueste Version in unserer
Plazorm updaten?“)
• Wieviel Zeit möchte ich dafür maximal
invesNeren?
Spikes sind eine schon sehr lange verfügbare Technik aus der Software-Entwicklung.
Ganz konkret sind es Lerneinheiten. Damit wird ein Ziel verfolgt:
- Was möchte ich/wir lernen?
- Wieviel Zeit wollen wir dafür investieren?
Die Ergebnisse des Lernens fliessen in spätere Backlog Items ein.

51. Spikes: Einsatz/Vorteile
• Unklare Stories? Vorher Spiken
• Solange spiken, bis genügend gemeinsames Wissen
vorhanden, um eine User Story gut formulieren zu
können
• Zahlt auf hohe SoXware-Qualität und Erreichung der
Ziele ein
Spikes werden häufig dazu genutzt, um unklare Stories zu verfeinern. Meist geht das ja durch direktes Prototyping viel besser als durch langes, theoretisches
(Architektur-)Design.
Es können auch mehrere Spikes hintereinander ausgeführt werden, die eine User Story (die dann erst einige Sprints später kommt) dann schärfen.
Ein Spike zahlt auf hohe Software-Qualität und Erreichen der Ziele ein. Unklarheiten können dadurch frühzeitig erkannt und ggf. beseitigt werden.

52. Spikes: Obacht!
• Nicht zu große Spikes definieren
• Je nach Komplexität der Lern-Aufgabe Teile des
Teams oder das gesamte Team drauf setzen
• Gut kombinierbar mit Mob Programming Sessions
zur Wissensverteilung
Worauf Du Acht geben solltest: Definiere einen Spike nicht zu groß. Setze also zB nur Teile des Teams darauf - es sei denn, Du willst wirklich Wissensverteilung im
gesamten Team erreichen. Dann bietet sich evtl. auch Mob Programming ein.

53. RetrospekXven

54. RetrospekXven:
Grundprinzip
• Set the stage, Gather Data, Generate Insights,
Decide What to do, Closing
• RetrospekNve kann und sollte ein Oberthema haben
Das Grundprinzip der Retrospektive sind die 5 Phasen. Ideen dafür findest Du auf dem bekannten https://retromat.org/de/
Eine Retrospektive kann und sollte ein Oberthema haben. Denn das ist somit ein Ziel.

55. RetrospekXven: Einsatz/
Vorteile
• RetrospekNven finden immer zuverlässig alle 14
Tage staU
• KonNnuierlicher Verbesserungsprozess, eingebaut im
Agilen Rahmenwerk
• Oberthema in der Retro hilX dem Team, sich auf
besNmmte Aspekte der (Zusammen-)Arbeit zu
fokussieren
Retrospektiven sind das Schmieröl für eine kontinuierliche Verbesserung.
Mit einer Zielsetzung - also dem Oberthema - hilfst Du dem Team, sich zu fokussieren.

56. RetrospekXven: Obacht!
• Keine Laber- oder Jammer-Runden durch fehlendes/
mangelndes Fokusthema erzeugen
• Auf gar keinen Fall weglassen (Ihr beraubt dem Team
elementare Verbesserungsmöglichkeiten)
• Nur wenige AcNons als Outcome erzeugen, um die
Erfolgswahrscheinlichkeit der AcNons zu erhöhen
Hast Du keine Fokussierung, dann kann eine Retrospektive schnell in Laber- oder Jammer-Runden ausarten.

57. Weitere Ziele/Zielsysteme:
Fokuszeit im Team, 3 Horizon Modell,
Kanban Flight Levels, Lean Canvas, …
Es gibt noch eine ganze Reihe weiterer Zielsysteme, auf die ich hier noch nicht eingehen konnte. Ich habe Sie hier aufgelistet.

58. FAZIT
Was ist also das Fazit, das ich aus diesem Vortrag ziehen möchte?

59. Haltung, Werte, Prinzipien
Es kommt im Agilen ganz häufig auf die eigene Haltung an. Agile Werte und Prinzipien geleiten uns in unserer täglichen Arbeit. Dieser Dreiklang trägt zum Gelingen bei,
und ist wichtig bei der Nutzung von Zielsystemen.

60. ParXzipaXve Ziel-Erstellung
Suche Dir Zielsysteme aus, die eine partizipative Ziel-Erstellung ermöglichen. Es muss nicht immer gleich ein hoher Delegation-Level sein.

61. Ziele setzen, um zu Lernen
Ziele sollten wir uns setzen, um zu Lernen. Denn wir haben es in der komplexen, hochdynamischen Welt oftmals mit Unknown Unknowns zu tun. Such dir also
Zielsysteme, die insbesondere iterativ-adaptiv angelegt sind.

62. Fragen, KriXk?
Her damit!
Björn SchoUe
bjoern.schoUe@mayflower.de
twiUer @BjoernSchoUe
Xing/LinkedIn
Telefon: +49-931-466216-15
Du bist nicht einverstanden mit dem, was ich gesagt habe? Prima!
Du hast noch weitere Fragen oder möchtest wissen, was Du bei Dir in Deinen Teams und im Management tun kannst, um Agiler zu werden? Sehr gerne!
Ich freue mich, wenn Du Dich bei mir meldest.

63. Bildnachweis
• hUps://unsplash.com/photos/8yCmQODY2SY
• hUps://unsplash.com/photos/cX0Yxw38cx8
• hUps://unsplash.com/photos/xyD55EZC6X8
• hUps://unsplash.com/photos/8xAA0f9yQnE
• hUps://unsplash.com/photos/DcKtooTyuuQ