# Vision to Act # Kapitel 1- Die Methodik Die Methodik: Vision to Act # Die Methodik: Vision to Act # Vision to Act (VTA) – Die Methodik > **Kurz gesagt:** *Vision to Act* (kurz **VTA**, auch „Vision to Act Model") ist ein einfaches Modell, um als Team – oder als Einzelperson bzw. ganze Firma – Klarheit und Struktur in zu viel Arbeit zu bringen. Es hilft, sich durch das Rauschen zu schneiden und **im richtigen Moment das Richtige zu tun**, statt möglichst viel gleichzeitig zu tun. Das Modell stammt von **Paula Ostmann** (Engineering Managerin bei Elevate, Dresden) und wurde erstmals ausführlich im Deep-Dive der **programmier.bar** vorgestellt (Vortragstitel: *„No Awards for being the busiest"*). Diese Erklärung fasst das Modell zusammen. --- ## Inhalt dieses Kapitels 1. Die Kernidee: „No Awards for being the busiest" 2. Die Pyramide – die vier Bausteine 3. Warum eine Pyramide und kein Trapez? (Fokus & „Nein sagen") 4. Mission vs. Ziele 5. Roadmap & Backlog 6. Kohärenz und die drei Regeln 7. Review-Rhythmen: das Modell lebendig halten 8. Ebenen: Individuum, Team, Firma – Alignment vs. Kohärenz 9. Einordnung: OKR, Frameworks & Messbarkeit 10. Agilität im VTA-Modell 11. Nutzen, Grenzen und die Kernbotschaft --- ## 1. Die Kernidee: „No Awards for being the busiest" Die Ausgangsbeobachtung ist banal und trotzdem allgegenwärtig: **Wir haben fast immer zu viel Arbeit.** Auf dem Tisch liegt der Stapel „muss jetzt gemacht werden" – und daneben der Stapel „würde ich gerne mal machen" (all die Fähigkeiten, die man gerne lernen würde). Den meisten Teams geht es genauso: Sie sind überschwemmt. Es gibt **keine Methode, die dafür sorgt, dass man alles schafft.** Aber es gibt Wege, sich durchzuschneiden und die Dinge zu tun, auf die es ankommt. Der Titel des zugrundeliegenden Vortrags bringt die Haltung auf den Punkt: > **„No Awards for being the busiest."** – Es gibt keinen Preis dafür, am beschäftigtsten zu sein. Der eigentliche „Award" sind nicht viele abgearbeitete Tickets, sondern **gute Go-Lives, fertige Projekte, echte Team-Erfolge**. Zeit ist dabei das ultimative Asset – das Knappste und Wertvollste. VTA ist der Versuch, diese Zeit auf das Richtige zu lenken. Ein wichtiger, oft überraschender Nebengedanke: > **Viel zu tun ≠ gute Leistung.** Wer viel Nutzloses tut, ist nicht produktiver. Menschen, die klare Grenzen ziehen, „Nein" sagen und auf ihre Ressourcen achten, sind häufig genau die, die man als *High Performer* bezeichnet – nicht die, die zu allem „Ja" sagen und alles wegarbeiten. --- ## 2. Die Pyramide – die vier Bausteine Das Herzstück von VTA ist eine **Pyramide aus vier Bausteinen**. Man liest sie von oben nach unten und leitet jede Ebene aus der darüberliegenden ab. ![Die VTA-Pyramide mit den vier Bausteinen Mission, Ziele, Roadmap und Backlog, von oben nach unten abgeleitet](https://book.star-nex.net/uploads/images/gallery/2026-08/scaled-1680-/pyramide.png) | Baustein | Frage | Beschreibung | |---|---|---| | **Mission** | *Warum?* | Das „Warum" und die Identität: Warum gibt es uns / mich? Wofür stehen wir? Am abstraktesten, am langlebigsten. | | **Ziele** | *Wohin?* | Der „Award", den wir erreichen wollen. Direkt aus der Mission abgeleitet. Erreichbar, mit einer *Definition of Done*. | | **Roadmap** | *Wie?* | Der Weg zu den Zielen: Welche Bausteine brauchen wir, in welcher Reihenfolge? Zugleich ein starkes Kommunikationsmittel. | | **Backlog** | *Was jetzt?* | Das tägliche Tun. Aus der Roadmap abgeleitet. | Das entscheidende Prinzip ist die **Ableitung von oben nach unten**: Man beginnt immer bei der Mission, leitet daraus die Ziele ab, daraus die Roadmap und daraus das Backlog. So entsteht ein zusammenhängendes (kohärentes) Ganzes statt vier lose nebeneinanderstehender Listen. --- ## 3. Warum eine Pyramide und kein Trapez? (Fokus & „Nein sagen") Es ist bewusst eine **Pyramide** – kein Trapez. Sie läuft nach oben **spitz** zu, weil Mission und Ziele **Fokus und Klarheit** verlangen. Sie müssen: - Die **Mission** muss sehr scharf sein. - Die **Ziele** ebenso – und es sollten **nicht zu viele** sein. *Fünf bis sechs Ziele sind zu viel*; das schafft man nicht. Der Grund ist statisch gedacht: Wird die Spitze zu breit, wird auch der **untere Teil der Pyramide breiter und dünner**. Das Fundament wird brüchig – und ein brüchiges Fundament kann den Rest nicht tragen. **Ein stabiles Fundament setzt eine scharfe Spitze voraus.** ### Das Bild vom Rechteck der unendlichen Möglichkeiten Ein hilfreiches Bild aus dem Gespräch: Man stelle sich die Pyramide **eingebettet in ein Rechteck** vor – das Rechteck steht für die unendlich vielen Möglichkeiten, die es links und rechts gäbe. ![Die Pyramide eingebettet in ein Rechteck der Möglichkeiten: bewusst „Ja" zur schmalen Spitze, „Nein" zu allem, was links und rechts liegt](https://book.star-nex.net/uploads/images/gallery/2026-08/scaled-1680-/rechteck-nein.png) Die Pyramidenform sagt **aktiv „Nein"** zu allem, was links und rechts liegt. Eine gute Mission und gute Ziele zu finden heißt deshalb vor allem: **sehr viel „Nein" sagen**. Das ist der schwierige Teil – es sind harte Entscheidungen, oft auch gegen Dinge, die „eigentlich auch wichtig" wären. Genau dieses fehlende „Nein" ist der Grund, warum Backlogs sonst unkontrolliert anwachsen. --- ## 4. Mission vs. Ziele Mission und Ziele werden in der Praxis leicht vermischt, weil beide abstrakt sind: Die Mission betrifft die schwer greifbare **Identität**, die Ziele reichen in die ebenso abstrakte **Zukunft**. Das klassische Hobby-Beispiel macht den Unterschied greifbar: | | Marathon-Beispiel | |---|---| | **Ziel** (der „Award") | *„Ich laufe meinen ersten Marathon."* – konkret, erreichbar, mit Ziellinie / *Definition of Done*. | | **Mission** (das „Warum") | *„Ich will eine richtig gute Langstreckenläuferin sein."* (oder auch: *„Ich will meine Midlife-Crisis gut bewältigen."*) – Identität, langlebig. | Der Kern des Unterschieds ist die **Langlebigkeit**: - Das **Ziel** ist erreicht, wenn der Marathon gelaufen ist. Danach ist es „fertig". - Die **Mission** bleibt: Man ist *auch nach* dem Marathon noch eine gute Langstreckenläuferin. Die Mission **trägt das nächste Ziel** (zweiter Marathon, schnellere Zeit …). Deshalb steht die Mission oben und ist stabil; die Ziele darunter sind erreichbar, endlich und werden ersetzt, sobald sie erreicht sind. ### Mission & Ziele gut aufsetzen Diesen oberen Teil der Pyramide **ordentlich hinzusetzen**, wird häufig übersprungen – und das ist ein Fehler. Empfehlungen: - **Nimm dir Zeit.** Wenn möglich, blocke als Team **ein bis zwei Tage** (idealerweise offsite), besonders beim ersten Mal. Mindestens **einen Tag**. Es ist die Zeit wert – man kommt gut durch und findet Mission, Ziele und oft schon erste Roadmap-Ideen. - **Bereite es gut vor.** Es gibt Unmengen an Literatur und Formaten. Entscheidend ist nicht das Format, sondern die **richtigen Fragen** zu finden. - **Destillieren statt erfinden.** Mission und Ziele **stecken schon im Team** – man muss sie nur herausdestillieren. - **Red Flag:** Gelingt das nicht, stimmt etwas anderes nicht – z. B. die Team­zusammensetzung oder das **Alignment** (unterschiedliche Vorstellungen davon, wo es hingehen soll). --- ## 5. Roadmap & Backlog So wie Mission und Ziele zusammengehören, bilden **Roadmap und Backlog** ein Paar – und werden ebenfalls gern vermischt (Dinge, die in die Roadmap gehören, landen im Backlog). ### Die Roadmap – der Weg Die Roadmap beschreibt, **wie** man die Ziele erreicht: Welche Bausteine braucht es, und in welcher **Reihenfolge**? Zwei Punkte sind zentral: - **Roadmap = Kommunikationsmittel.** Die Bausteine zu finden ist das eine; sie auf einem Zeitstrahl zu **priorisieren**, ist das andere. Dafür muss man mit anderen Menschen in der Firma / mit Stakeholdern in Interaktion treten. - **Kapazität von Anfang an mitdenken.** Man hat nur begrenzte Zeit, und die teilt sich in Fragmente auf. Beispiel: Ein **DevOps-Team** muss Zeit für Support reservieren – wenn eine Pipeline steht, muss es wie die Feuerwehr einspringen. Solche Teams dürfen **nicht bis oben hin ausgeplant** sein. Das muss man **hineindesignen**, denn es nimmt dem Backlog Raum. > Als Bild: Auf der **Vertikalen** steht die maximale zeitliche Auslastung/Kapazität, auf der **Horizontalen** die Reihenfolge – *was wann kommt*. ### Der Backlog – als Tortendiagramm, nicht als endlose Liste Der wichtigste Perspektivwechsel: **Denke den Backlog nicht als lineare Liste (wie das Backlog-Board in Azure DevOps), sondern als Tortendiagramm.** Überlege zuerst, wie viel Zeit du für bestimmte Dinge brauchst – jeder Posten schneidet ein Stück aus der Torte. **Was übrig bleibt, ist die echte Kapazität für Mission und Ziele.** Mehr passt nicht hinein. ![Der Backlog als Tortendiagramm: fixe Anteile für Support, Bugfixes und Lernen/Refactoring; was übrig bleibt, ist die echte Kapazität für Mission & Ziele](https://book.star-nex.net/uploads/images/gallery/2026-08/scaled-1680-/backlog-torte.png) Weitere Leitplanken: - **Wie viele Epics / parallele Arbeitsstränge** kann das Team **gleichzeitig** bearbeiten? Danach richtet sich, was gleichzeitig offen sein darf. - **Nicht verhandelbare Anteile** bewusst reservieren (Support, Bugfixes). **Wunsch-Ideal:** auch Weiterbildung und Refactoring nicht verhandelbar machen – das sind die Dinge, die sonst immer als Erstes hinten runterfallen. - **Ein voller Backlog ist kein guter Backlog.** Er soll nicht voll, sondern **gut strukturiert** sein und nur ausgewählte Dinge enthalten, die man wirklich demnächst angeht. --- ## 6. Kohärenz und die drei Regeln Damit die Pyramide trägt, muss sie **kohärent** bleiben – die Ebenen müssen zueinander passen, und das dauerhaft. Das ist keine Selbstverständlichkeit: Der Backlog ändert sich ohnehin ständig, Ziele und Roadmap können sich verschieben, und **externe Kräfte** wirken permanent ein, sodass Dinge nicht so laufen wie geplant. Damit das Modell trotzdem zusammenhält, gehören **drei Regeln** dazu: > **Regel 1 – Von oben ableiten.** Jede Ebene leitet sich aus der darüberliegenden ab (Mission → Ziele → Roadmap → Backlog). > > **Regel 2 – Regelmäßig reviewen.** Prüfe in sinnvollen Abständen, ob noch alles zusammenpasst. Nicht täglich – aber auch nicht erst nach einem Jahr. > > **Regel 3 – Veränderungen nach oben prüfen.** Ändert sich etwas in einem Baustein, prüfe, ob es noch zur Ebene **darüber** passt. Passt es nicht, ziehe entweder die obere Ebene nach – oder mache ein **Review der gesamten Pyramide**. Konkret: Kommt z. B. über die Roadmap ein neuer Kunde mit ganz neuen Anforderungen hinein, fragt man: *Passt das noch zu unseren Zielen?* Wenn ja – super. Wenn nein und man es nicht ablehnen kann, muss man die **Ziele anpassen** (reviewen und neu formulieren) und anschließend prüfen, ob die neue Lage noch zur **Mission** passt – die sich im Extremfall ebenfalls geändert haben kann. ### Zwei Arten von Kohärenz Zusammengenommen sichern die drei Regeln **zwei Arten von Kohärenz**: 1. **Strukturelle Kohärenz** – die Ebenen bauen inhaltlich aufeinander auf (von oben nach unten abgeleitet). Dafür sorgt vor allem Regel 1. 2. **Zeitliche Kohärenz** – die Pyramide bleibt auch über die Zeit stimmig, obwohl sich Bausteine ändern und externe Kräfte einwirken. Dafür sorgen die Regeln 2 und 3. --- ## 7. Review-Rhythmen: das Modell lebendig halten VTA ist **kein statisches Konstrukt**. Man setzt es einmal auf (das schafft Struktur und senkt die mentale Last), muss es dann aber in passenden Abständen überprüfen. Faustregeln: | Baustein | Typischer Review-Rhythmus | Leitfrage | |---|---|---| | **Backlog** | ~ alle 2 Wochen (Sprint-Takt) | Stimmt die Dynamik? Arbeiten wir das Richtige ab? | | **Roadmap** | ~ alle 3 Monate (bei stabilem Team) | Passt der Weg noch? Hat sich Grundlegendes geändert? | | **Ziele** | ~ alle 6 Monate | Spiegeln die Ziele die aktuelle Situation noch wider? | | **Mission** | mindestens 1× pro Jahr | Stimmt unsere Identität noch? | Wichtige Nuancen: - **Die Mission sollte sich *nicht* ständig ändern.** Häufige Änderungen sind eine **Red Flag** – dann liegt vermutlich etwas anderes im Argen. - **Nicht erst nach einem Jahr das erste Mal hinschauen** – bis dahin ist man garantiert vom Weg abgekommen. - **Natürliche Zyklen nutzen:** Wer in Sprints arbeitet, schaut ohnehin alle zwei Wochen in den Backlog – dabei gleich reviewen. - **Ein echtes Review braucht Raum.** Man kann nicht „mal eben in einer Stunde" fragen: *„Lies mal die Mission und sag, ob sie noch stimmt."* Es braucht **Zeit, Inspiration und Reflexionsmöglichkeit**. - **Mentale Entlastung als Zweck:** Es soll präsent und klar sein (im Idealfall die Mission gerahmt im Büro), aber einen **nicht permanent beschäftigen**. --- ## 8. Ebenen: Individuum, Team, Firma – Alignment vs. Kohärenz Das Modell funktioniert auf **jeder Ebene** – für dich selbst, für dein Team oder für die ganze Firma. Man kann die Pyramiden sogar **stapeln** und miteinander **verlinken**. - **Auf Firmenebene** gibt es Mission, Ziele und Unterziele (das ist oft die Roadmap-Ebene). Die **Backlog-Ebene wird dünn**, weil es auf Organisationsebene selten echte Arbeitspakete gibt. - **Verlinken schafft Alignment:** Wenn alle Team-Pyramiden auf **dieselbe obere (Firmen-)Pyramide** verweisen, entsteht **Alignment**. ### Der feine Unterschied: Alignment vs. Kohärenz | Begriff | Bedeutung im VTA-Kontext | |---|---| | **Alignment** | Wird **hergestellt**: Teams werden bewusst auf dieselbe übergeordnete Pyramide ausgerichtet (Kopplung von oben). | | **Kohärenz** | Ist **verteilt** und entsteht **aus den Teams selbst heraus**, wenn Mission und Ziele der Organisation verstanden sind. | Beide gehören zusammen: **Alignment** stellt man aktiv her, indem alle Team-Pyramiden auf dieselbe übergeordnete Pyramide verweisen. **Kohärenz** entsteht darüber hinaus aus den Teams selbst, sobald Mission und Ziele der Organisation verstanden sind – ein Team sollte dafür aber nie **losgelöst** von der Organisation arbeiten; Rahmen und Input von außen bleiben legitim und nötig. --- ## 9. Einordnung: OKR, Frameworks & Messbarkeit VTA sagt bewusst **nicht**, *wie* du Mission und Ziele findest oder ausgestaltest – es gibt nur die **Struktur** vor. Für die einzelnen Ebenen kannst du daher andere Methoden einsetzen. **Verhältnis zu OKR.** VTA konkurriert nicht mit OKR, beides lässt sich kombinieren. *OKR (Objectives & Key Results)* ist eine Methode, um Ziele zu formulieren: Man setzt ein qualitatives **Objective** („Wo wollen wir hin?") und hängt einige messbare **Key Results** daran, an denen man den Fortschritt abliest. Genau so etwas kann in VTA die **Ziel-Ebene** ausfüllen. **Frameworks nicht blind übernehmen.** Eine fertige Schablone über ein Team zu stülpen und zu hoffen, dass die Menschen hineinpassen, erzeugt meist **Reibung**. Besser **maßschneidern**: *Was macht dieses Framework – und was brauche ich davon wirklich?* Dazu passt VTA, weil es nur einen minimalen Rahmen vorgibt und den Rest offenlässt. **Muss alles messbar sein? Nein.** VTA erzwingt keine messbaren Ziele. Für die Ziel-Ebene gibt es zwei Spielarten: - **SMART Goals** – stark **messbare** Ziele. - **Directional Priorities** – geben eher eine **Richtung** vor; dafür braucht es ein gemeinsames Verständnis der **Definition of Done** (*Wann ist das Ziel erreicht? Wann machen wir ein neues daraus?*). Wichtig ist die Balance: Alles auf eine einzige Zahl zu reduzieren verliert viel von dem, was zählt – **gar nichts** zu messen ist aber ebenso schlecht. --- ## 10. Agilität im VTA-Modell „Agil" ist ein erstaunlich schwammiger Begriff: Fragt man zehn Leute, was er bedeutet, bekommt man fünfzehn Meinungen. Viele sagen, sie seien agil oder arbeiteten agil – ohne den konkreten Nutzen benennen zu können. Genau deshalb haben wir **VTA ausprobiert**: Wir wollten ein verlässliches Framework, das unsere Arbeit strukturiert, **ohne von Grund auf „agil" sein zu müssen**. Was von „agil" trotzdem hilfreich ist, steckt ohnehin schon in VTA: ein **klarer, aber minimaler Rahmen**, den man einmal setzt und in dem man sich frei bewegt – kombiniert mit **Feedbackzyklen** (den Reviews), über die man ihn in sinnvollen Abständen verbessert, statt ihn ständig umzuwerfen. *So viel Struktur wie nötig, so wenig wie möglich.* --- ## 11. Nutzen, Grenzen und die Kernbotschaft ### Nutzen - **Klarheit & Struktur bei Überlastung** – gemeinsam als Team erarbeitet, sodass man einen roten Faden hat und nicht nach einem halben oder ganzen Jahr wieder fragt: *„Warum haben wir unsere Ziele schon wieder nicht erreicht?"* - **Weniger mentale Last.** Wir können nur wenige Dinge gleichzeitig im Kopf behalten. Einmal aufschreiben und sich als Team darauf verständigen **schafft Platz** – man kann sich auf den nächsten Schritt konzentrieren, statt ständig an alles zu denken. - **Starkes Kommunikationsmittel nach außen.** Kommt eine Anfrage „Baut ihr mal schnell X ein?", kann man sagen: *„Das zahlt nicht auf unsere Ziele ein – warum sollten wir es priorisieren?"* Man zieht **Grenzen** und beruft sich auf das gemeinsam Vereinbarte. Muss sich wirklich etwas ändern, wird eben **neu verhandelt**. ### Grenzen / wann *nicht* - **Läuft es gut, wirble keinen Staub auf.** Ist das Team zufrieden und alles sortiert, muss man nicht alles neu aufwühlen. Man macht nur, **was gerade gebraucht wird** (Einfachheit). - **Junge Teams können oft noch schlecht „Nein" sagen** – ihnen fehlt der gemeinsame Bezugspunkt, an dem sie Anfragen messen könnten. Genau den liefert VTA: erst Mission und Ziele klären, dann lässt sich begründet abgrenzen. ### Die eine Kernbotschaft Der eigentliche Wert von VTA zeigt sich in Momenten der Unklarheit: Das Modell gibt dir einen festen Punkt, an den du immer zurückkehren kannst. Statt im Rauschen zu versinken, arbeitest du dich von oben nach unten durch und gewinnst so (hoffentlich) wieder Klarheit. > **Wenn alles zu viel ist und du nicht weißt, wo du anfangen sollst – fang immer wieder ganz oben an: bei der Mission und den Zielen.** > *Wer sind wir, und wo wollen wir hin?* Von dort hangelst du dich nach unten und priorisierst, was gemacht werden muss – und was nicht. # Kapitel 2- Änderungen/Changelog Änderungen und warum sie vorgenommen wurden # Kapitel 3- Nutzer Befragungen Befragungsleitfaden/ Interviewfragen Ergebnisse der Befragung