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

Die Kernidee: „No Awards for being the busiest"
Die Pyramide – die vier Bausteine
Warum eine Pyramide und kein Trapez? (Fokus & „Nein sagen")
Mission vs. Ziele
Roadmap & Backlog
Kohärenz und die drei Regeln
Review-Rhythmen: das Modell lebendig halten
Ebenen: Individuum, Team, Firma – Alignment vs. Kohärenz
Einordnung: OKR, Frameworks & Messbarkeit
Agilität im VTA-Modell
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.

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 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 Teamzusammensetzung 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.

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:

Strukturelle Kohärenz – die Ebenen bauen inhaltlich aufeinander auf (von oben nach unten abgeleitet). Dafür sorgt vor allem Regel 1.
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.