# 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

# Vision to Act – Adaption im Dreamlight Valley Team (DVT)

# Vision to Act (VTA) – Adaption im Dreamlight Valley Team (DVT)

> **Kurz gesagt:** Das Vision-to-Act-Modell von Paula Ostmann strukturiert Arbeit in einer Pyramide aus vier aufeinander aufbauenden Ebenen – Mission (Warum), Ziele (Wohin), Roadmap (Wie) und Backlog (Was jetzt) –, die von oben nach unten abgeleitet werden. Die vom Dreamlight Valley Team (DVT) selbst erarbeitete Pyramide folgt dieser Grundstruktur, weicht in der konkreten Ausgestaltung aber bewusst vom ursprünglichen Modell ab. Diese Beschreibung hält fest, wo und warum das DVT angepasst hat, damit die Abweichungen nachvollziehbar bleiben und im Review bewusst reflektiert werden können.

## Inhalt dieses Kapitels

1. Ausgangslage: die umgesetzte Pyramide
2. Mission als Prinzipienbündel statt Einzelsatz
3. Ziele als Kombination aus Produkt- und Plattformzielen
4. Roadmap als wiederkehrende Praktiken statt terminierter Bausteine
5. Backlog: unterhalb der Pyramide
6. Gegenüberstellung: Referenzmodell vs. Adaption

---

## 1. Ausgangslage: die umgesetzte Pyramide

Grundlage dieser Beschreibung ist die vom DVT selbst erarbeitete VTA-Pyramide. Das Team übernimmt die vier Ebenen des Referenzmodells, füllt sie jedoch inhaltlich anders, als es das allgemeine Modell nahelegt. Die folgenden Abschnitte gehen die vier Ebenen einzeln durch und benennen jeweils, worin die Adaption gegenüber dem Grundmodell besteht.

Gehalten wird die Pyramide über einen täglichen Sync: Er findet einmal am Tag statt, ist in seiner Ausgestaltung frei und wird genutzt, wenn jemand ein Thema hat, das besprochen werden soll. Ergebnisse und allgemeine Themen werden auf dem gemeinsamen Whiteboard festgehalten – das Whiteboard ist damit der Single Point of Truth für den aktuellen Stand der Pyramide und der Projekte des DVT.

## 2. Mission als Prinzipienbündel statt Einzelsatz

Statt einer einzigen, scharf formulierten Identitätsaussage besteht die Mission-Ebene aus fünf gleichrangigen Leitprinzipien, die unterschiedliche Dimensionen der Teamarbeit abdecken:

- Vereinfachung von Management-Aufgaben
- Kontinuierliche persönliche Weiterentwicklung jedes Teammitglieds
- Wachstum individueller Skill-Sets
- Raum zum Ausprobieren neuer Techniken und Methoden
- Ausrichtung der Produkte an Qualität, unabhängig von äußerem Druck

Die Spitze der Pyramide wird damit nicht als einzelner Identitätssatz, sondern als Bündel von Leitprinzipien verstanden, das Individuum, Team und Produktqualität gleichrangig nebeneinanderstellt.

## 3. Ziele als Kombination aus Produkt- und Plattformzielen

Die Ziele-Ebene vereint drei Kategorien von Vorhaben:

- **Produkt-Releases:** u. a. Round Robin (vormals Daily Toast), DaySaber, NightSaber, Order67
- **Struktur- und Plattformziele:** Aufbau einer Infrastrukturplattform für Eigenentwicklung, mit klar definierten Schnittstellen unter dem Namen StarNet
- **StarNet-Fähigkeiten:** Aktuell verfügt StarNet über Fähigkeiten des Monitorings und stellt eine Plattform für die Kommunikation zwischen Projekten und für den Aufbau von Wissensdatenbanken zur Verfügung

Erfüllte Ziele werden auf dem Whiteboard farblich markiert, sodass der Fortschritt auf einen Blick erkennbar ist.

Die Ziele-Ebene wird damit bewusst breiter genutzt, als es das Referenzmodell mit seiner Empfehlung von fünf bis sechs fokussierten Zielen vorsieht – sie deckt sowohl produktbezogene Meilensteine als auch plattformweite Sichtbarkeits- und Vernetzungsziele ab.

## 4. Roadmap als wiederkehrende Praktiken statt terminierter Bausteine

Die Roadmap ist nicht als sequenzierter Zeitstrahl mit aufeinanderfolgenden Meilensteinen ausgestaltet, sondern als Satz von acht wiederkehrenden Arbeitsprinzipien, die auf dem Whiteboard von links nach rechts angeordnet sind:

- Kontinuierliche Abwägung neuer Entwicklungsvorhaben
- Qualitätsgeprüfte Entwicklungsphasen
- Beta-Phasen
- Überprüfung gegen den eigenen Anspruch
- Veröffentlichung von Produkten
- Dokumentation
- Aufbau einer Wissensdatenbank
- Vorstellung der Ergebnisse

Diese Praktiken werden für jedes Ziel bzw. jede Produktveröffentlichung gleichermaßen durchlaufen.

## 5. Backlog: unterhalb der Pyramide

Die Backlog-Ebene wird im gemeinsamen Pyramiden-Board geführt – räumlich unterhalb der Pyramide angeordnet. Sie wird täglich überarbeitet, und einmal im Quartal werden die Projektstände in einer größeren Session ausdefiniert.

## 6. Gegenüberstellung: Referenzmodell vs. Adaption

| Baustein | Referenzmodell (Vision to Act) | Unsere Adaption |
|---|---|---|
| Mission | Ein scharfer, einzelner Identitätssatz | Fünf gleichrangige Leitprinzipien |
| Ziele | 5–6 fokussierte Ziele mit Definition of Done | ~9 Ziele, Produkt- und Plattformziele gemischt |
| Roadmap | Sequenzierte Bausteine mit Zeitstrahl und Kapazitätsplanung | Acht wiederkehrende Praktiken, von links nach rechts angeordnet; Abbruch oder Rücksprung jederzeit möglich |
| Backlog | Kapazitäts-Tortendiagramm, aus der Roadmap abgeleitet | Im Board geführt, unterhalb der Pyramide; einmal pro Quartal ergänzt und evaluiert |

# Kapitel 3- Nutzer Befragungen

Befragungsleitfaden/ Interviewfragen

Ergebnisse der Befragung

# Fragenkatalog

# Vision to Act (VTA) – Fragenkatalog zur Nutzerbefragung im Dreamlight Valley Team (DVT) (Stand September 2026)

> **Kurz gesagt:** Dieser Fragenkatalog dient dazu, die von DVT gelebte VTA-Adaption (siehe „Vision to Act – Adaption im Dreamlight Valley Team (DVT)") strukturiert und wiederholbar zu evaluieren. Er wird als **leitfadengestütztes Interview** durchgeführt: Die Fragen werden namentlich zugeordnet erhoben, die Bewertung selbst erfolgt aber über standardisierte **5-stufige Likert-Skalen**, damit Ergebnisse über Personen und über mehrere Befragungsrunden hinweg vergleichbar und aggregierbar bleiben.

## Methodische Hinweise für die Durchführung

- **Skala:** Jedes Statement wird auf einer 5-stufigen Zustimmungsskala bewertet:
  `1 = stimme gar nicht zu · 2 = stimme eher nicht zu · 3 = teils/teils · 4 = stimme eher zu · 5 = stimme voll zu`
- **Aufbau:** Jede der fünf Pyramiden-Ebenen (Mission, Ziele, Roadmap, Backlog, Sync/Whiteboard) wird über dieselben fünf Sub-Dimensionen erfasst – **Klarheit/Verständlichkeit, Alltagsnutzen, Akzeptanz der Adaption gegenüber dem Referenzmodell, Vollständigkeit** und **Verbesserungsbedarf** –, jeweils mit zwei Items. Das macht die Ebenen untereinander vergleichbar (z. B. „ist Klarheit bei der Roadmap schwächer ausgeprägt als bei der Mission?").
- **Ein Aspekt pro Item:** Jedes Statement enthält bewusst nur eine Aussage, um eindeutige Antworten zu ermöglichen.
- **Invertierte Items:** Items, die mit *(invertiert)* markiert sind, formulieren die Aussage bewusst in die Gegenrichtung (z. B. pro Referenzmodell statt pro Adaption). Das reduziert Zustimmungstendenz (alles pauschal hoch bewerten) und muss bei der Auswertung **umgepolt** werden: Auswertungswert = 6 − erhobener Wert, bevor der Mittelwert je Sub-Dimension gebildet wird.
- **Nachfrage-Regel:** Bei Werten **≤ 2** oder **= 5** fragt die interviewende Person aktiv nach dem „Warum?" und hält die Antwort als Stichpunkt fest – das liefert die qualitative Tiefe, ohne die Skala selbst aufzuweichen.
- **Wiederholbarkeit:** Der identische Katalog sollte in regelmäßigem Abstand (z. B. pro Quartal, analog zur Backlog-Ausdefinition) erneut erhoben werden, um Veränderungen über Zeit sichtbar zu machen.
- **Auswertung:** Pro Sub-Dimension und pro Ebene wird der Mittelwert über alle befragten Personen gebildet (nach Umpolung der invertierten Items); auffällige Streuung zwischen Personen ist selbst ein Befund und sollte benannt werden.

---

## 0. Angaben zur Befragung

| Feld | Eintrag |
|---|---|
| Name |  |
| Rolle im DVT |  |
| Zeit im Team (ungefähr) |  |
| Datum des Interviews |  |
| Interviewer:in |  |

---

## 1. Mission (Leitprinzipien)

*Referenz: fünf gleichrangige Leitprinzipien statt eines einzelnen Identitätssatzes.*

**Klarheit/Verständlichkeit**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| M1 | Die fünf Leitprinzipien sind mir jederzeit präsent, ohne dass ich nachschauen muss. | | |
| M2 | Ich könnte die fünf Leitprinzipien aus dem Stegreif korrekt benennen. | | |

**Alltagsnutzen**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| M3 | Die Leitprinzipien beeinflussen konkret, wie ich meine tägliche Arbeit priorisiere. | | |
| M4 | Wenn ich unsicher bin, wie ich mich entscheiden soll, helfen mir die Leitprinzipien als Orientierung. | | |

**Akzeptanz der Adaption**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| M5 | Ich finde es sinnvoll, dass die Mission-Ebene mehrere gleichrangige Prinzipien statt eines einzelnen Satzes umfasst. | | |
| M6 | *(invertiert)* Ein einzelner, scharf formulierter Identitätssatz (wie im Referenzmodell) würde uns mehr Orientierung geben als die aktuellen fünf Prinzipien. | | |

**Vollständigkeit**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| M7 | Die fünf Prinzipien decken das ab, was für mich als Team-Identität wichtig ist – mir fehlt kein zentraler Aspekt. | | |
| M8 | Individuum, Team und Produktqualität sind in den Prinzipien gleichrangig und angemessen vertreten. | | |

**Verbesserungsbedarf**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| M9 | *(invertiert)* Es gibt einzelne Prinzipien, die in der Praxis kaum eine Rolle spielen. | | |
| M10 | Ich sehe aktuell keinen Änderungsbedarf an der Mission-Ebene. | | |

---

## 2. Ziele (Produkt- und Plattformziele)

*Referenz: Kombination aus Produkt-Releases, Struktur-/Plattformzielen und StarNet-Fähigkeiten – deutlich mehr als die im Referenzmodell empfohlenen 5–6 fokussierten Ziele.*

**Klarheit/Verständlichkeit**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| Z1 | Mir ist zu jedem Zeitpunkt klar, welche Ziele auf dem Whiteboard aktuell offen bzw. bereits erreicht sind. | | |
| Z2 | Mir ist bei jedem Ziel klar, wann es als „erreicht" gilt (Definition of Done). | | |

**Alltagsnutzen**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| Z3 | Die Ziele-Ebene hilft mir konkret bei der Priorisierung meiner täglichen Arbeit. | | |
| Z4 | Die farbliche Markierung erfüllter Ziele auf dem Whiteboard hilft mir, den Fortschritt einzuschätzen. | | |

**Akzeptanz der Adaption**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| Z5 | Die gemeinsame Führung von Produkt- und Plattformzielen auf einer Ebene erleichtert mir die Priorisierung. | | |
| Z6 | *(invertiert)* Eine kleinere Anzahl fokussierter Ziele (wie im Referenzmodell empfohlen: 5–6) wäre für unsere Arbeit besser geeignet als die aktuell rund neun Ziele. | | |

**Vollständigkeit**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| Z7 | Die aktuellen Ziele decken sowohl Produkt- als auch Plattform-/Infrastrukturarbeit angemessen ab. | | |
| Z8 | StarNet als Plattformziel ist für mich in seiner Bedeutung genauso greifbar wie ein Produkt-Release. | | |

**Verbesserungsbedarf**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| Z9 | *(invertiert)* Es gibt Ziele auf dem Whiteboard, die aus meiner Sicht überflüssig oder veraltet sind. | | |
| Z10 | Ich sehe aktuell keinen Änderungsbedarf an der Ziele-Ebene. | | |

---

## 3. Roadmap (wiederkehrende Praktiken)

*Referenz: acht wiederkehrende Arbeitsprinzipien statt sequenzierter Bausteine mit Zeitstrahl und Kapazitätsplanung.*

**Klarheit/Verständlichkeit**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| R1 | Die acht Praktiken (Abwägung, Qualitätsprüfung, Beta-Phase, Anspruchsprüfung, Veröffentlichung, Dokumentation, Wissensdatenbank, Vorstellung) sind mir für jedes Ziel klar nachvollziehbar. | | |
| R2 | Die Reihenfolge der acht Praktiken (links nach rechts) entspricht dem, wie Arbeit bei uns tatsächlich abläuft. | | |

**Alltagsnutzen**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| R3 | Die acht Praktiken geben mir im Arbeitsalltag eine verlässliche Orientierung, in welcher Phase sich ein Vorhaben befindet. | | |
| R4 | Die Möglichkeit, jederzeit abzubrechen oder zurückzuspringen, nutze ich als echten Vorteil in meiner Arbeit. | | |

**Akzeptanz der Adaption**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| R5 | Wiederkehrende Praktiken statt eines Zeitstrahls mit Meilensteinen passen besser zu unserer Arbeitsweise als ein klassischer Roadmap-Zeitstrahl. | | |
| R6 | *(invertiert)* Ein klassischer Zeitstrahl mit Terminen und Kapazitätsplanung (wie im Referenzmodell) würde mir mehr Sicherheit geben als die aktuellen acht Praktiken. | | |

**Vollständigkeit**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| R7 | Die acht Praktiken decken alle wesentlichen Schritte ab, die ein Vorhaben bei uns durchläuft. | | |
| R8 | Mir ist für jedes laufende Vorhaben klar, in welcher der acht Praktiken es sich aktuell befindet. | | |

**Verbesserungsbedarf**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| R9 | *(invertiert)* Mir fehlt eine Aussage darüber, wie viel Kapazität für die aktuellen Vorhaben zur Verfügung steht. | | |
| R10 | Ich sehe aktuell keinen Änderungsbedarf an der Roadmap-Ebene. | | |

---

## 4. Backlog (Board)

*Referenz: kein aus der Roadmap abgeleitetes Kapazitäts-Tortendiagramm, sondern ein Board unterhalb der Pyramide, täglich gepflegt, quartalsweise ausdefiniert.*

**Klarheit/Verständlichkeit**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| B1 | Ich weiß jederzeit, wo ich neue Aufgaben/Ideen im Backlog eintragen kann. | | |
| B2 | Mir ist klar, wie ein Eintrag vom Backlog in die Roadmap-Praktiken übergeht. | | |

**Alltagsnutzen**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| B3 | Die tägliche Überarbeitung des Backlogs hilft mir, meinen eigenen Arbeitsstand aktuell zu halten. | | |
| B4 | Ich finde im Backlog schnell, was aktuell priorisiert ist. | | |

**Akzeptanz der Adaption**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| B5 | Ein Backlog als Board unterhalb der Pyramide passt besser zu unserer Arbeitsweise als ein aus der Roadmap abgeleitetes Kapazitäts-Tortendiagramm. | | |
| B6 | *(invertiert)* Ein Kapazitäts-Tortendiagramm (wie im Referenzmodell) würde mir eine bessere Übersicht geben als das aktuelle Board. | | |

**Vollständigkeit**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| B7 | Der quartalsweise Rhythmus zur Ausdefinition der Projektstände ist für mich der richtige Takt. | | |
| B8 | Alle relevanten Aufgaben und Ideen des Teams finden sich zuverlässig im Backlog wieder. | | |

**Verbesserungsbedarf**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| B9 | *(invertiert)* Mir fehlt eine Übersicht darüber, wie viel Kapazität die Backlog-Einträge insgesamt binden. | | |
| B10 | Ich sehe aktuell keinen Änderungsbedarf an der Backlog-Ebene. | | |

---

## 5. Täglicher Sync & Whiteboard (Trägermechanismus)

*Referenz: freiformatiger täglicher Sync, Whiteboard als Single Point of Truth für Pyramide und Projektstände.*

**Klarheit/Verständlichkeit**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| S1 | Das Whiteboard gibt mir jederzeit ein verlässliches Bild vom aktuellen Stand der Pyramide. | | |
| S2 | Ich weiß immer, wo auf dem Whiteboard ich welche Information finde. | | |

**Alltagsnutzen**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| S3 | Der tägliche Sync hilft mir, offene Fragen zeitnah zu klären. | | |
| S4 | Ich bringe eigene Themen aktiv in den täglichen Sync ein, wenn ich welche habe. | | |

**Akzeptanz der Adaption**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| S5 | Die freie, ungeplante Ausgestaltung des täglichen Syncs funktioniert für die Themen, die ich einbringen möchte. | | |
| S6 | *(invertiert)* Ein fester, stärker strukturierter Sync-Ablauf (feste Agenda, feste Redezeiten) würde uns mehr bringen als das aktuelle freie Format. | | |

**Vollständigkeit**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| S7 | Alle für mich relevanten Informationen zur Pyramide finden sich zuverlässig auf dem Whiteboard wieder. | | |
| S8 | Das Whiteboard als „Single Point of Truth" wird von allen im Team gleich verstanden und genutzt. | | |

**Verbesserungsbedarf**

| # | Statement | 1–5 | Begründung (bei ≤2 oder =5) |
|---|---|---|---|
| S9 | *(invertiert)* Informationen vom Whiteboard gehen mir zwischen den Syncs verloren. | | |
| S10 | Ich sehe aktuell keinen Änderungsbedarf am täglichen Sync bzw. am Whiteboard. | | |

---

## 6. Gesamtreflexion (offen)

*Ergänzende offene Fragen zur Einordnung der quantitativen Ergebnisse – werden im Interview als Kernaussage protokolliert.*

1. Wo weicht die gelebte Praxis am stärksten vom ursprünglichen VTA-Referenzmodell ab – und ist diese Abweichung aus deiner Sicht gerechtfertigt?
2. Welche der vier Ebenen (Mission, Ziele, Roadmap, Backlog) bringt dir im Alltag den größten Nutzen?
3. Welche der vier Ebenen würdest du als erstes verändern, wenn du frei entscheiden könntest?
4. Gibt es einen Aspekt der Adaption, der im Fragenkatalog oben nicht abgedeckt wurde, dir aber wichtig ist?

---

## 7. Auswertungsraster (für die Zusammenfassung nach mehreren Interviews)

*Werte der invertierten Items vor Eintragung umpolen (6 − erhobener Wert).*

| Ebene | Klarheit Ø | Alltagsnutzen Ø | Akzeptanz Adaption Ø | Vollständigkeit Ø | Verbesserungsbedarf Ø | Gesamt-Ø |
|---|---|---|---|---|---|---|
| Mission (M1–M10) | | | | | | |
| Ziele (Z1–Z10) | | | | | | |
| Roadmap (R1–R10) | | | | | | |
| Backlog (B1–B10) | | | | | | |
| Sync/Whiteboard (S1–S10) | | | | | | |

# Umfrageergebnisse (September 2026)

# Vision to Act (VTA) – Umfrageergebnisse im Dreamlight Valley Team (DVT)

> **Vermerk:** Diese Auswertung basiert auf einer Erhebung, die im **September 2026** (11.–14.09.2026) stattfand.

> **Kurz gesagt:** Im September 2026 wurde die gelebte VTA-Adaption des DVT anhand eines standardisierten Fragenkatalogs (5-stufige Zustimmungsskala, fünf Ebenen × fünf Sub-Dimensionen) mit vier Teammitgliedern erhoben. Am positivsten bewertet das Team den **täglichen Sync & das Whiteboard** (4,50 von 5), gefolgt von **Backlog** (3,98) und **Roadmap** (3,80). Kritischer fallen **Mission** (3,55) und vor allem **Ziele** (3,29) aus – dort sehen mehrere Befragte konkreten Überarbeitungsbedarf, insbesondere weil einzelne Ziele veraltet sind.

---

## Inhalt dieses Kapitels

1. Methodik der Befragung
2. Gesamtbild: Bewertung je Ebene
3. Mission – Leitprinzipien
4. Ziele – Produkt- und Plattformziele
5. Roadmap – wiederkehrende Praktiken
6. Backlog – Board unterhalb der Pyramide
7. Täglicher Sync & Whiteboard
8. Offene Gesamtreflexion
9. Einordnung & nächste Schritte

---

## 1. Methodik der Befragung

Grundlage ist der **Fragenkatalog** (siehe „Vision to Act – Adaption im DVT" für die inhaltliche Referenz): Jede der fünf Pyramiden-Ebenen wird über dieselben fünf Sub-Dimensionen erfasst – **Klarheit/Verständlichkeit, Alltagsnutzen, Akzeptanz der Adaption gegenüber dem Referenzmodell, Vollständigkeit** und **Verbesserungsbedarf** –, jeweils mit zwei Statements auf einer 5-stufigen Skala (1 = stimme gar nicht zu … 5 = stimme voll zu). Statements, die bewusst in Gegenrichtung formuliert sind (*„invertiert"*), werden vor der Auswertung umgepolt (6 − erhobener Wert). Bei Werten **≤ 2** oder **= 5** wurde im Interview aktiv nach dem „Warum?" gefragt – diese Begründungen liefern die qualitative Tiefe hinter den Zahlen.

Befragt wurden vier Personen, geführt als leitfadengestütztes Interview durch Leander Eberwein:

| Name | Rolle im DVT | Zeit im Team | Datum |
|---|---|---|---|
| Befragte A | Ausbilder und Leiter | unterschiedlich lang | 11.09.2026 |
| Befragte B | Entwicklerin | unterschiedlich lang | 11.09.2026 |
| Befragte C | Entwickler | unterschiedlich lang | 14.09.2026 |
| Befragte D | Dev | unterschiedlich lang | 14.09.2026 |

Die Runde deckt damit bewusst eine breite Spanne an Team-Zugehörigkeit ab. Das ist bei der Einordnung der Ergebnisse zu berücksichtigen, insbesondere bei Befragte D: Die Antworten spiegeln einen ersten Eindruck wider, keine gewachsene Erfahrung mit der Pyramide.

---

## 2. Gesamtbild: Bewertung je Ebene

![Grafische Auswertung: KPI-Kacheln je Ebene, gruppiertes Balkendiagramm Ebene × Person und Heatmap Ebene × Dimension](https://book.star-nex.net/uploads/images/gallery/2026-09/scaled-1680-/Lr5tgOLA9qamIDvk-umfrage-auswertung-anon-raw.png)

| Ebene | Klarheit Ø | Alltagsnutzen Ø | Akzeptanz Adaption Ø | Vollständigkeit Ø | Verbesserungsbedarf Ø | Gesamt Ø |
|---|---|---|---|---|---|---|
| Mission | 3,38 | 3,25 | 3,88 | 3,88 | 3,38 | **3,55** |
| Ziele | 3,25 | 3,43 | 3,38 | 4,13 | 2,25 | **3,29** |
| Roadmap | 3,63 | 4,00 | 4,13 | 3,88 | 3,38 | **3,80** |
| Backlog | 4,63 | 3,63 | 4,50 | 3,50 | 3,63 | **3,98** |
| Sync & Whiteboard | 4,50 | 4,88 | 4,75 | 4,25 | 4,13 | **4,50** |

*(n = 4 je Ebene; Werte invertierter Items bereits umgepolt.)*

Zwei Muster fallen auf:

- **Je näher an der täglichen Arbeit, desto zustimmender die Bewertung.** Der Sync/Whiteboard-Mechanismus und der Backlog – die beiden Ebenen mit dem größten Bezug zum Tagesgeschäft – werden am klarsten und nützlichsten erlebt. Mission und Ziele, die abstrakteren oberen Ebenen, schneiden spürbar schwächer ab.
- **„Verbesserungsbedarf" ist bei den Zielen die Auffälligkeit der gesamten Erhebung** (2,25 – der niedrigste Einzelwert im gesamten Raster). Hier gibt es aus Sicht mehrerer Befragter konkreten, benennbaren Handlungsbedarf (siehe Abschnitt 4).

Auch zwischen den Personen streut die Bewertung teils deutlich:

| | Mission | Ziele | Roadmap | Backlog | Sync & Whiteboard |
|---|---|---|---|---|---|
| Befragte A | 3,9 | 3,2 | 4,0 | 3,7 | 4,2 |
| Befragte B | 3,8 | 4,0 | 3,8 | 4,0 | 4,7 |
| Befragte C | 4,1 | 2,7 | 3,6 | 3,8 | 4,8 |
| Befragte D | 2,4 | 3,2 | 3,8 | 4,4 | 4,3 |

Die niedrige Mission-Bewertung von Befragte D (2,4) erklärt sich vor allem durch fehlende Vertrautheit mit dem Team, nicht durch inhaltliche Kritik – die Begründungen zu M7/M8 (siehe Abschnitt 3) sind differenziert, nicht ablehnend. Der niedrige Ziele-Wert von Befragte C (2,7) deckt sich mit dem generellen Befund zu dieser Ebene.

---

## 3. Mission – Leitprinzipien

Gesamt Ø **3,55**. Klarheit und Alltagsnutzen (je um 3,3) sind schwächer als Akzeptanz und Vollständigkeit (je 3,88) – die fünf Leitprinzipien werden inhaltlich mitgetragen, sind im Kopf aber weniger präsent als die konkreteren unteren Ebenen.

- Zur bewussten Entscheidung für **fünf gleichrangige Prinzipien statt eines Einzelsatzes** gibt es klare Zustimmung: *„für unser Team wäre nur eine Mission ungenau"* (Befragte B, 5/5 zu M5); *„bewusst auf unsere Teamkonstellation angepasst"* (Befragte A).
- Kritischer wird die **Vollständigkeit** einzelner Prinzipien gesehen: *„Team-Identität find ich hier etwas schwierig … unsere ‚Team-Identität' per se ist nicht zurückzuführen auf die Ziele"* (Befragte C zu M7); *„Es geht eher ums Team, um das Produkt und die Qualität, aber weniger um Individuum"* (Befragte D zu M8).
- Beim **Änderungsbedarf** gehen die Meinungen auseinander: Befragte A sieht ihn konkret bevorstehen (*„es kommen immer wieder Zeitpunkte, wo überlegt wird, etwas zu ändern"*), Befragte C hält die Priorisierung der Prinzipien dagegen für stimmig.

---

## 4. Ziele – Produkt- und Plattformziele

Gesamt Ø **3,29** – die am kritischsten bewertete Ebene, mit dem klarsten Handlungsauftrag der gesamten Befragung: **Verbesserungsbedarf 2,25**.

- Der Kern des Befunds ist **Aktualität**: *„die Themen, die durch sind, müssten durch neue Themen ersetzt werden – Order67 und Peakfit haben das Team verlassen und Daily Toast heißt mittlerweile Round Robin"* (Befragte A). Die Ziele-Ebene ist an dieser Stelle nicht mehr deckungsgleich mit der aktuellen Team-Realität.
- Auch die **Abdeckung von Plattform-/Infrastrukturarbeit** wird als ausbaufähig genannt: *„Ich glaube, es fehlt noch Genauigkeit … vor allem bei Infrastrukturarbeit"* (Befragte C); *„wir könnten noch konkreter werden"* (Befragte A).
- Ein wiederkehrender Verbesserungsvorschlag betrifft die **Struktur der Ziele-Ebene selbst**: Befragte D schlägt vor, *„gemeinsame Plattformziele"* und *„pro Produkt separate Ziele"* zu unterscheiden (zwei Zielebenen in der Pyramide), *„dadurch verhindert man auch, dass Ziele veraltet sind"*.
- Gegenläufig dazu steht vereinzelte Zufriedenheit mit der Zahl der Ziele: Befragte B hält an neun statt der referenzmodell-typischen 5–6 Ziele fest, *„wir arbeiten an zu vielen Dingen für nur 5 Ziele"*.

> **Ableitung:** Die Ziele-Ebene ist die naheliegendste Kandidatin für die nächste Überarbeitung der Pyramide (siehe Abschnitt 9).

---

## 5. Roadmap – wiederkehrende Praktiken

Gesamt Ø **3,80**, die zweitbeste Bewertung nach Sync & Whiteboard. Akzeptanz der Adaption (4,13) und Alltagsnutzen (4,00) fallen besonders positiv aus – die acht wiederkehrenden Praktiken statt eines klassischen Zeitstrahls werden als passender empfunden.

- Die Flexibilität wird explizit geschätzt: *„ein klassischer Zeitstrahl ist nicht flexibel und unsere Roadmap schon – du kannst von links nach rechts springen, weißt, wo du dich befindest"* (Befragte D); *„passt so wie es ist für mich … er dient eher als Vorlage"* (Befragte C, 5/5 zu „kein Änderungsbedarf").
- Einzelne Praktiken werden unterschiedlich genutzt: Befragte B nutzt die Möglichkeit zum Zurückspringen kaum (*„ich gehe erst einen Schritt weiter, wenn der bisherige abgeschlossen ist"*), während sie für andere ein echter Vorteil ist.
- Die **Kapazitätsfrage** (R9, invertiert) wird uneinheitlich beantwortet – von *„kenne meine eigene Kapazität"* (Befragte B) bis *„die einzelnen Projekte sind ungleich groß und benötigen dementsprechend andere Kapazitäten"* (Befragte A). Ein expliziter Kapazitätsüberblick fehlt aktuell, wird aber nicht einheitlich vermisst.
- Kleinere Kritik an der Reihenfolge der acht Praktiken: *„Punkt 2 ist quasi eine Mission als Roadmap-Item umformuliert"* (Befragte D).

---

## 6. Backlog – Board unterhalb der Pyramide

Gesamt Ø **3,98**, die zweitbeste Ebene nach Sync & Whiteboard – bei gleichzeitig größter Bandbreite zwischen den Sub-Dimensionen (Klarheit 4,63 vs. Vollständigkeit 3,50).

- Die Entscheidung **gegen** das referenzmodell-typische Kapazitäts-Tortendiagramm und **für** ein Board wird klar geteilt: *„Tortendiagramm finde ich total ungenau"* (Befragte B, 5/5 zu B5); *„ist flexibler, und man hat seine Missionen immer klar dabei und kann abwägen"* (Befragte D).
- Die **tägliche Pflege** wird nicht von allen gleich gelebt: *„Nicht jedes Produkt hat ein Backlog, manchmal eine Spec und manchmal nur Anforderungen"* (Befragte C, 1/5 zu B3); *„ich überarbeite unregelmäßig – muss ich verbessern"* (Befragte B).
- Der **quartalsweise Rhythmus** zur Ausdefinition wird teils als zu selten empfunden: *„brauch es mittlerweile häufiger"* (Befragte A); *„öfter wäre besser"* (Befragte D) – gleichzeitig sagt Befragte C *„lieber öfter als weniger oft"* bei voller Zustimmung (5/5).
- Vereinzelter Hinweis auf Pflegequalität: *„Manche Nutzer:innen müssten ihr Board mehr pflegen und aktuell halten"* (Befragte D).

---

## 7. Täglicher Sync & Whiteboard

Gesamt Ø **4,50** – die mit Abstand am positivsten bewertete Ebene, in allen fünf Sub-Dimensionen über 4,1.

- Das **freie, ungeplante Format** wird explizit gegenüber einem festen Ablauf bevorzugt – bei allen vier Befragten mit voller Ablehnung eines festen Formats (S6, invertiert, durchgehend 1/5): *„Jeder hat in seinen eigenen Projekten unterschiedliche Baustellen, die auch unterschiedlich Zeit in Anspruch nehmen … gleiche Redezeiten sind dumm"* (Befragte D); *„wenn ich was Geplantes brauche, erstelle ich einen separaten Termin"* (Befragte B).
- Einziger genannter Verbesserungspunkt betrifft **asynchrone Information**: Kommentarfunktionen und eine Benachrichtigung, falls jemand etwas auf dem Board notiert hat, würden helfen, damit Informationen zwischen den Syncs nicht verloren gehen (Befragte D).
- Die Whiteboard-Nutzung als *„Single Point of Truth"* wird nicht von allen gleich aktiv gepflegt: *„kommt auf die individuelle Boardnutzung an"* (Befragte D); *„den Begriff kannte ich vorher nicht, aber er ergibt für mich Sinn"* (Befragte B).

---

## 8. Offene Gesamtreflexion

Vier ergänzende offene Fragen wurden am Ende jedes Interviews gestellt.

**Wo weicht die gelebte Praxis am stärksten vom Referenzmodell ab – und ist das gerechtfertigt?** Alle vier Befragten bestätigen die Abweichung als bewusst und richtig, verorten den größten Abstand aber unterschiedlich: Befragte A und Befragte B sehen ihn vor allem in **Roadmap/Backlog**-Struktur, Befragte C in der **projektindividuellen Backlog-Führung**, Befragte D generell im **individuellen Zuschnitt von Backlog und Zielen** auf das Team. Übereinstimmend wird das nicht als Schwäche, sondern als Stärke der VTA-Adaption gesehen: *„das macht die VTA aus, da sie an Teambedürfnisse angepasst werden kann"* (Befragte D).

**Welche Ebene bringt im Alltag den größten Nutzen?** Uneinheitlich: Mission (Befragte D, Befragte C), Ziele (Befragte A), bzw. situativ Mission/Backlog/Roadmap je nach Entscheidung (Befragte B). Bemerkenswert: Trotz der kritischsten quantitativen Bewertung wird die Ziele-Ebene von niemandem als nutzlos beschrieben.

**Welche Ebene würdest du zuerst verändern?** Hier zeigt sich der stärkste Konsens der gesamten Befragung: **drei von vier Personen nennen die Ziele-Ebene** (Befragte D: zwei Zielarten trennen; Befragte B: Ziele und Backlog genauer führen) bzw. mit Backlog/Roadmap verwandte Punkte (Befragte C: Backlog; Befragte A: Roadmap). Das deckt sich mit dem quantitativen Befund aus Abschnitt 4.

**Fehlt ein Aspekt, der nicht abgedeckt wurde?** Keine der vier Personen nennt einen fehlenden Aspekt.

---

## 9. Einordnung & nächste Schritte

Das Gesamtbild ist positiv: Alle fünf Ebenen liegen über dem neutralen Skalenmittelwert von 3, der tragende Mechanismus (täglicher Sync & Whiteboard) wird nahezu einhellig als starke Grundlage erlebt. Der klarste, von den offenen Antworten und den quantitativen Werten übereinstimmend getragene Befund ist:

> **Die Ziele-Ebene ist reif für eine Überarbeitung.** Konkret benannt wurden: veraltete/verlassene Ziele bereinigen (Order67, Peakfit, Umbenennung Daily Toast → Round Robin), die Abdeckung von Plattform-/Infrastrukturarbeit schärfen, und – als strukturellere Änderung – eine Trennung in Team-/Plattformziele einerseits und Projekt-/Produktziele andererseits zu prüfen.

Als naheliegende weitere Ansatzpunkte, in geringerer Priorität:

- **Backlog:** quartalsweisen Rhythmus zur Ausdefinition ggf. verkürzen; einheitlichere Pflegequalität zwischen den Board-Nutzer:innen anstreben.
- **Sync/Whiteboard:** asynchrone Informationswege ergänzen (z. B. Kommentarfunktion, Benachrichtigung bei Board-Änderungen), ohne das bewusst freie Format anzutasten.
- **Mission:** kein akuter Änderungsbedarf, aber im nächsten turnusmäßigen Review (siehe Erklärungskapitel, Review-Rhythmen) gezielt prüfen, ob alle fünf Prinzipien noch gleichrangig zutreffen.

Diese Befragung sollte – wie im Fragenkatalog vorgesehen – **wiederholt** werden, um Veränderungen über die Zeit sichtbar zu machen, idealerweise nach der nächsten Überarbeitung der Ziele-Ebene.

> **Nächste Erhebung:** Die nächste Befragung ist für **Dezember 2026** vorgesehen.