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