Forum der Produktteams des Unternehmens: Programm Product Day

Das Produktteam-Forum verbindet Portfolio, teamübergreifende Abhängigkeiten und Managemententscheidungen. Wir erläutern das Programm des Product Day, Rollen, die Vorbereitung von Materialien und die Arbeit nach der Veranstaltung.

Das Produktteam-Forum eines Unternehmens, oder der interne Product Day, ist für Fragen nötig, die nicht mehr in die Meetings eines einzelnen Teams passen. Dort erstellen die Teilnehmer ein Gesamtbild des Portfolios, finden teamübergreifende Abhängigkeiten, diskutieren Einschränkungen und halten Entscheidungen fest. Der Wert einer solchen Veranstaltung wird durch die Arbeitsergebnisse bestimmt: eine Portfolio-Karte, ein Abhängigkeitsregister, ein Entscheidungsjournal und eine klare Fortsetzung.

Wir bei Aventura sind für die eventbezogene Konstruktion des Forums verantwortlich: Programm, Szenario, Teilnehmerrouten, Location, technischer Rahmen und die Dokumentation der Ergebnisse. Die Produktdaten, Prioritäten und das Recht, Entscheidungen zu treffen, bleiben beim Auftraggeber. Diese Aufteilung muss vor der Auswahl von Referenten und Räumen festgelegt werden.

Wann braucht ein Unternehmen ein Forum für Produktteams?

Kurz gesagt: Ein Forum ist nötig, wenn mehrere Teams von gemeinsamen Plattformen, Daten, Kanälen, Expert:innen oder Managemententscheidungen abhängen. Ein gewöhnlicher Sync reicht nicht mehr aus: Jedes Team sieht nur seinen eigenen Bereich, und Konflikte um Prioritäten und Ressourcen bleiben zwischen den Abteilungen bestehen.

Das erste Anzeichen: Entscheidungen eines Teams haben Auswirkungen auf andere. Ein neues Release erfordert Anpassungen der Plattform, Zugriff auf Daten, juristische Freigabe, Vertriebsunterstützung oder eine Änderung des gemeinsamen Customer Journeys. Wenn diese Zusammenhänge in verschiedenen Kalendern besprochen werden, zerfällt das Gesamtbild.

Das zweite Anzeichen: Die Führung muss Initiativen nach einer Reihe einzelner Berichte abgleichen. Teams präsentieren ihre Roadmaps und Metriken, verwenden aber unterschiedliche Formate. Infolgedessen geht Zeit für die Übersetzung und Klärung der Ausgangsdaten verloren. Die Portfolioauswahl wird auf ein geschlossenes Meeting verschoben, dessen Logik die Teilnehmenden erst später erfahren.

Das dritte Anzeichen: Der Streit erfordert Entscheidungsbefugnisse auf übergeordneter Ebene. Ein Team kann eine Hypothese oder die Reihenfolge der Aufgaben selbst klären. Die Frage der Umverteilung gemeinsamer Ressourcen, der Einstellung einer Initiative oder der Änderung von Verpflichtungen muss von einer verantwortlichen Führungskraft entschieden werden. Die GOV.UK-Prinzipien für agile Delivery empfehlen, Entscheidungen rechtzeitig, auf der passenden Ebene und mit den richtigen Personen zu treffen. Für ein Forum ist das eine nützliche Grenze: In das Programm kommen Fragen, die nicht in einem normalen Teammeeting geklärt werden können.

Ein Forum ist verfrüht, wenn der Auftraggeber kein gemeinsames Ziel, keine Auswahlkriterien und keine Personen mit Entscheidungsbefugnis hat. Ein großer Saal wird unvorbereitete Daten nicht korrigieren. Zuerst müssen Widersprüche gesammelt und festgestellt werden, welche davon eine gemeinsame Arbeit erfordern.

Abgrenzung zu Demo Day, Hackathon und Strategiesitzung

Kern: Der Name der Veranstaltung bestimmt nicht das Format. Der Demo Day zeigt vorbereitete Ergebnisse, der Hackathon gibt Zeit für die Entwicklung einer Lösung, die Strategiesitzung wählt die Richtung, und das Forum verbindet das laufende Portfolio, Teams, Einschränkungen und nächste Schritte.

Ein Product Day kann eine Demo, eine Arbeitssitzung und einen Auftritt der Führungskraft umfassen. Der Schwerpunkt muss dennoch eindeutig sein. Andernfalls erhalten die Teilnehmer ein langes Programm mit unterschiedlichen Versprechen: Den einen wird vorgeschlagen, ihre Arbeit zu präsentieren, den anderen, etwas Neues zu entwickeln, den dritten, Ressourcen abzustimmen.

Im Scrum wird das Sprint Review als Arbeitssitzung beschrieben, um das Ergebnis zu überprüfen und die weitere Anpassung zu besprechen. Es wird nicht vorgeschlagen, es auf eine Präsentation zu beschränken. Dieses Prinzip ist auch für das Forum nützlich: Die Demo sollte Material für eine Frage oder Entscheidung liefern, sonst wird sie zur Bildschirmparade.

Wenn die Hauptaufgabe mit der Präsentation vorbereiteter Projekte und einer Entscheidung zu jedem einzelnen endet, sollte besser ein separater Unternehmens-Demo-Tag für Projekte genutzt werden. Für ein Fachpublikum, das Praktiken und Dokumente vergleicht, lohnt sich ein Blick darauf, wie ein Forum der Unternehmenstechnologen aufgebaut ist. Das Produktforum unterscheidet sich durch den Gegenstand der Arbeit: Es verbindet feste cross-funktionale Teams, Produktsignale, Roadmaps und gemeinsame Einschränkungen.

Entscheidungen, die bis zum Ende des Tages vorliegen müssen

Ergebnis: Vor der Zusammenstellung des Programms müssen die Entscheidungen festgehalten werden, für die die Teams zusammenkommen. Für jede Frage wird das erwartete Ergebnisniveau festgelegt: endgültige Entscheidung, Empfehlung, Liste fehlender Daten, zugewiesene Maßnahme oder Eskalation.

Der Ausdruck „Teams synchronisieren“ liefert dem Planer keine arbeitsfähige Aufgabe. Er sollte in konkrete Fragen zerlegt werden. Welche Initiativen erfordern eine gemeinsame Ressource? Wo haben zwei Teams unvereinbare Termine zugesagt? Welche Abhängigkeiten erzeugen ein kritisches Risiko? Zu welchen Themen muss die Führung die Auswahl bestätigen?

Wir beginnen mit einer Entscheidungskarte. Sie enthält den Gesprächsgegenstand, den Verantwortlichen für die Vorbereitung, die Teilnehmer, die Person mit Genehmigungsbefugnis und das akzeptable Ergebnis des Forums. Wenn eine Entscheidung nicht im Saal getroffen werden kann, muss ehrlich festgelegt werden, was das Forum für den nächsten Schritt vorbereitet.

Sinnvoll ist es, die Fragen in vier Gruppen aufzuteilen:

1. Das Team entscheidet selbst und teilt das Ergebnis den anderen mit.
2. Mehrere Teams stimmen eine gemeinsame Maßnahme ab.
3. Die Führungskraft bestätigt die Priorität oder löst den Konflikt auf.
4. Die Frage erfordert zusätzliche Daten und erhält einen Verantwortlichen für die Weiterverfolgung.

Nicht jede Debatte muss noch am selben Tag mit einer Antwort enden. Manchmal ist ein qualitativ hochwertiges Ergebnis, festzuhalten, welche Daten fehlen, wer sie sammelt und wann die Teilnehmer zur Auswahl zurückkehren. Das ist nützlicher als eine formale Abstimmung ohne Informationen über Kosten, Risiken und Verpflichtungen.

Im Atlassian-Material über Entscheidungsfindung wird das Problem wiederholter Diskussionen beschrieben, wenn die Rollen unklar bleiben. Für das Forum ist die Schlussfolgerung direkt: Die Teilnehmer müssen wissen, wo sie einen Beitrag leisten, wo sie eine Empfehlung erarbeiten und wer das Ergebnis genehmigt. Der Mechanismus der Abstimmung sammelt das Signal des Publikums, ersetzt aber nicht das Entscheidungsrecht.

Zusammensetzung der Teilnehmenden und Rollen

Kurz gesagt: Die Teilnehmenden werden nach ihrem Beitrag zur Entscheidung ausgewählt. Beim Forum braucht es Verantwortliche für Produktkontext, technische Rahmenbedingungen, Nutzerdaten, kommerzielle Verpflichtungen und gemeinsame Ressourcen sowie Führungskräfte, die den nächsten Schritt bestätigen können.

Ein Forum nur für Produktmanager ergibt kein vollständiges Bild. Ein Produktvorhaben kann von Architektur, Forschung, Analytics, Support, Vertrieb, Marketing, Operations, Finanzen oder rechtlichen Einschränkungen abhängen. Das GOV.UK Service Manual verbindet die Arbeit an einem digitalen Service mit einem interdisziplinären Team und der Beteiligung der Menschen, die tatsächlich Entscheidungen treffen.

Die Zusammensetzung hängt von der Agenda ab. Eine universelle Liste von Positionen gibt es nicht. Wir schlagen vor, jeden Block des Programms durchzugehen und drei Fragen zu beantworten: Wer bestätigt die Ausgangsdaten, wer sieht die Konsequenzen der Entscheidung und wer hat die Befugnis für den nächsten Schritt.

HR und interne Kommunikation helfen, das Publikum zusammenzubringen, das Ziel zu erklären und die Ergebnisse an die Teilnehmenden zurückzumelden. Sie sollten nicht die Verantwortlichen für Produktentscheidungen ersetzen. Auch das Event-Team legt keine Prioritäten für den CPO oder den Portfolio-Verantwortlichen fest.

Wir benennen separat den Verantwortlichen für jede Entscheidung und den Verantwortlichen für das Forum selbst. Ersterer ist für den Inhalt der Frage zuständig. Letzterer führt Programm, Materialversionen, Zugänge und Änderungen zusammen. Diese Trennung verringert das Risiko, dass organisatorische Aufgaben und Produkterkenntnisse in einer einzigen überlasteten Rolle landen.

Analysen von Programmen, Moderation und Produktionsentscheidungen veröffentlichen wir im Telegram-Kanal von Aventura.

Was man vor dem Forum von den Teams einholen sollte

Arbeitsprinzip: Jedes Team erstellt ein vergleichbares Pre-Read statt einer beliebigen Präsentation. Darin enthalten sein müssen: Problem oder Chance, Zielgruppe, Daten, erwartetes Ergebnis, Einschränkungen, Abhängigkeiten und eine konkrete Anfrage an andere Teams oder die Geschäftsleitung.

Die Materialien sollten vor der Inszenierungsprobe gesammelt werden. Wenn ein Team Metriken und Auswahloptionen mitbringt, das zweite eine Release-Historie und das dritte einen Werbespot, lassen sie sich nicht vergleichen. Redaktionelle Bearbeitung in der letzten Woche behebt nicht das Fehlen einer gemeinsamen Fragestellung.

Wir nehmen einen Team-Steckbrief auf einer oder mehreren kurzen Seiten auf:

• Produktziel oder Problem;
• Nutzer oder interner Auftraggeber;
• Signal: Metrik, Untersuchung, Feedback oder Verpflichtung;
• früher getroffene Entscheidung und geprüfte Alternativen;
• erwartetes Ergebnis;
• Risiko oder Unbekannte;
• Abhängigkeiten von Teams, Plattformen und gemeinsamen Funktionen;
• konkrete Anfrage an das Forum;
• zulässiger Grad der Offenlegung von Materialien.

Eine Roadmap in einem solchen Paket wird als Mittel benötigt, um Ziele, Initiativen und erwartete Ergebnisse zu verknüpfen. Product School und Aha! beschreiben die Roadmap als Möglichkeit, das Gesamtbild zu vermitteln und die Strategie mit der Arbeit zu verbinden. Für das Forum reicht ein Release-Kalender nicht aus. Die Teilnehmer müssen die Grundlage des Einsatzes, die erwartete Veränderung, die Einschränkung und den Entscheidungspunkt verstehen.

Faktenmaterial, das vorab gelesen werden kann, verlagern wir in das Pre-Read. Das öffentliche Handbook von GitLab beschreibt Live-Doc-Meetings und die Verbindung des synchronen Gesprächs mit der gemeinsamen Dokumentation. Wir schlagen nicht vor, den Prozess eines einzelnen Unternehmens zu kopieren. Der praktische Grundsatz ist nützlich: Die Zeit im Saal sollte besser für Fragen, Konflikte und die Überarbeitung der Lösung reserviert bleiben.

Die Liste der Materialien, Zielgruppen, Streams und Einschränkungen lässt sich praktischerweise in einer technischen Spezifikation für das Unternehmensforum festhalten. Auf dieser Grundlage kalkulieren wir Programm, Location, Ausstattung, Navigation und Teamzusammensetzung.

Architektur des Product-Day-Programms

Kurz: Das Programm bewegt sich von einem allgemeinen Rahmen zu Arbeitsbesprechungen und einer gemeinsamen Festlegung. Der Teilnehmer versteht zunächst die Ziele und Auswahlkriterien, arbeitet dann mit seinem Track und sieht anschließend Entscheidungen, Verantwortliche und die Fortsetzung.

Wir bei Aventura bauen die Organisation von Foren und Seminaren rund um die Aktivitäten der Teilnehmenden. Zuerst klären wir, wo Menschen den allgemeinen Kontext hören, Initiativen vergleichen, Abhängigkeiten besprechen, Demos ansehen und Entscheidungen treffen. Danach wählen wir Säle, Bühne, Bildschirme, Netzwerk und den Ablauf der Übergänge aus.

Der Arbeitsablauf kann so aussehen:

1. Allgemeiner Rahmen von der Leitung: Ziele, Auswahlkriterien, Einschränkungen und Tagesfragen.
2. Kurzer Portfolio-Überblick: eine gemeinsame Karte der Initiativen und Verbindungen.
3. Thematische Besprechungen: Produktwetten, Nutzersignale, technische Einschränkungen.
4. Dependency Clinic: Arbeit an kritischen teamübergreifenden Abhängigkeiten.
5. Demo zu den Fragen, bei denen eine Live-Vorführung die These belegt.
6. Geschlossenes Fenster für sensible Entscheidungen, falls erforderlich.
7. Gemeinsamer Entscheidungspunkt: was beschlossen wurde, was Daten erfordert, wer weiterarbeitet.

Die gemeinsame Bühne dient dem Kontext, den jeder gleichermaßen hören muss. Detailarbeit läuft besser in kleinen Räumen oder an Arbeitstischen. Das Finale versammelt die Teilnehmenden erneut, aber nicht, um alle Vorträge zu wiederholen. Die Moderation zeigt die Veränderungen im Gesamtbild und nennt die nächsten Schritte.

Parallele Ströme erfordern eine Route. Jeder Teilnehmer braucht eine klare Auswahllogik, und die Organisatoren brauchen Raumkapazitäten, Übergangszeiten und eine Möglichkeit, das Ergebnis in das gemeinsame Journal zurückzuführen. Wenn die Arbeit einer Gruppe nicht in die finale Festlegung einfließt, bleibt sie ein lokales Gespräch.

Für eine breite Business-Veranstaltung verbinden wir Inhalt, Logistik und technische Produktion in der Organisation von Geschäftsveranstaltungen. Der Auftraggeber behält dabei die inhaltliche Verantwortung für die Produktagenda und genehmigt alle Schlussfolgerungen.

Arbeitsformate statt einer Reihe von Vorträgen

Kurz: Ein Vortrag ist gerechtfertigt, wenn er schnell einen gemeinsamen Kontext schafft. Für den Vergleich, die Risikoanalyse und die Abstimmung von Maßnahmen braucht es Arbeitsformate: runder Tisch, clinic, Entscheidungsbesprechung, Portfolio-Karte, failure review oder gemeinsame Arbeit an einem Dokument.

Eine Reihe von Präsentationen ist praktisch für den Zeitplan, verändert aber die Arbeit der Teams kaum. Jeder Speaker zeigt seine eigene Geschichte, die Fragen werden kürzer, und die Verbindungen zwischen den Beiträgen bleiben in den Notizen der Zuhörer. Infolgedessen wirkt das Forum vollgepackt, obwohl die Entscheidungen erst nach der Veranstaltung entstehen.

Das Format wählen wir nach der gewünschten Aktion:

Die Fehleranalyse erfordert eine sichere Moderation. Wir besprechen die Entscheidung und die Bedingungen, betrachten getrennt das zum Zeitpunkt der Wahl Bekannte und das, was später klar wurde. Das Eingestehen eines Fehlers machen wir nicht zu einem Ranking der Abteilungen.

Für einen komplexen Fall erhält der Moderator vorab die Frage, die verfügbaren Daten und die Grenzen der Diskussion. Seine Aufgabe ist es, das Gespräch im Rahmen der Anfrage zu halten. Wenn die Teilnehmer auf Implementierungsdetails eingehen, bevor das Problem abgestimmt ist, bringt der Moderator sie zur ursprünglichen Entscheidung zurück.

Wie führt man ein Portfolio-Review durch?

Kurz: Das Portfolio-Review vergleicht Initiativen nach einer einheitlichen Vorlage. Das Team zeigt Ziel, erwartetes Ergebnis, Begründung, Einschränkungen, Abhängigkeiten und Entscheidungsbedarf. Die Schönheit der Slides und die Anzahl der veröffentlichten Funktionen dürfen nicht den Inhalt ersetzen.

Das Review beginnt mit einer Gesamtübersicht. Auf ihr sind Produktbereiche, Initiativen, gemeinsame Plattformen und große Abhängigkeiten sichtbar. Dann legen die Teams nur die Elemente offen, bei denen die Sicht anderer Beteiligter oder eine Managemententscheidung erforderlich ist.

Für jede Wette genügen sieben Felder:

1. Welches Problem oder welche Chance das Team betrachtet.
2. Für wen sie wichtig ist.
3. Welche Daten die Aktualität belegen.
4. Welches Ergebnis erwartet wird.
5. Welche Einschränkungen und Alternativen bereits bekannt sind.
6. Von wem der nächste Schritt abhängt.
7. Welche Entscheidung im Forum erforderlich ist.

Der Moderator bittet das Team nicht, die gesamte Roadmap zu verteidigen. Er stellt Fragen zum strittigen Bereich. Wenn ausreichend Daten vorliegen, bestätigt der benannte Leiter die Wahl. Wenn die Begründung schwach ist, erhält das Team eine Aufgabe zur Überprüfung. Wenn der Konflikt eine gemeinsame Ressource betrifft, geht die Frage in das Entscheidungsfenster mit dem Eigentümer dieser Ressource über.

Ein Antipattern dieses Blocks ist die Parade der grünen Status. Die Teilnehmer hören, dass alles nach Plan läuft, sehen aber keine gestoppten Hypothesen, die Kosten der Verzögerung und Anfragen an andere Teams. Wir schlagen vor, jedes Review mit einem der klaren Status zu beenden: fortsetzen, ändern, stoppen, Daten prüfen oder eskalieren.

Der Entscheidungssekretär notiert die Formulierung sofort auf dem Bildschirm oder in einem gemeinsamen Dokument. Die Teilnehmer sehen den Text und können die Mehrdeutigkeit korrigieren, bevor sie zum nächsten Punkt übergehen. Die endgültige Aufzeichnung muss für eine Person verständlich sein, die nicht im Raum anwesend war.

Dependency clinic und Karte der teamübergreifenden Verknüpfungen

Antwort: Eine Abhängigkeit wird für die Arbeit erst dann verständlich, wenn beide Seiten, der Verantwortliche, die erforderliche Aktion, die Folge einer Verzögerung und ein Kontrollpunkt angegeben sind. Eine Linie zwischen zwei Karten ohne diese Felder zeigt eine Verbindung, legt aber keine weitere Arbeit fest.

Atlassian schlägt in der Methodik des Dependency Mapping vor, Abhängigkeiten und Risiken frühzeitig zu erkennen, Verantwortliche zu benennen, die Risikominderung zu planen und den Rhythmus des Feedbacks festzulegen. Für das Forum ist dies die Grundlage einer eigenen Arbeitssitzung.

Vor der Veranstaltung tragen die Teams bekannte Verknüpfungen in ein gemeinsames Register ein. Auf dem Forum prüfen die Teilnehmenden kritische Abhängigkeiten, finden diejenigen, die in der Diskussion fehlen, und präzisieren die Aktion. Wir versprechen nicht, jede Blockade im Raum aufzulösen. Wenn keine Befugnisse oder Daten vorliegen, wird der Eskalationsweg zum Ergebnis.

Eine Abhängigkeitskarte umfasst:

Die Karte muss nach der Veranstaltung einen Verantwortlichen haben. Ein Foto der Wand ersetzt nicht das Register. Alle Karten werden in eine digitale Umgebung überführt, in der das Team bereits die Produktarbeit führt. Das Format des Tools wählt der Auftraggeber.

In der Sitzung selbst ist es sinnvoll, Menschen von beiden Seiten der Verknüpfung zusammenzubringen. Wenn eine Seite fehlt, wird die Diskussion schnell zu einer Vermutung über die Möglichkeiten anderer. Eine solche Frage wird als offen festgehalten und nicht als abgestimmter Plan ausgegeben.

Rolle der Führungsebene und geschlossene Sitzung

Orientierung: Führungskräfte werden in den Blöcken gebraucht, in denen ihre Befugnisse das Ergebnis verändern. Eine Begrüßung ersetzt nicht die Teilnahme an der Wahl von Prioritäten, Ressourcen und dem Eskalationsweg. Sensible Fragen können in einen geschlossenen Raum ausgelagert werden, aber die Entscheidungslogik muss in zulässigem Umfang an die Teams zurückfließen.

Vor dem Forum gleichen wir den Kalender der Entscheidungsträger mit dem Programm ab. Wenn CPO, CTO oder ein Business-Leiter nur bei der Eröffnung anwesend ist, gehen strittige Fragen erneut „zur Abstimmung“. Deshalb werden Entscheidungsfenster in bestätigter Zeit angesetzt und der Führungskraft im Voraus ein Pre-Read übergeben.

Ein breites Publikum kann Nutzersignale, Abhängigkeiten, Umsetzungsvarianten und Konsequenzen diskutieren. Fragen zu Personalien, vertraulichen Daten, Investitionslimits oder einer noch nicht angekündigten Strategie können einen geschlossenen Teilnehmerkreis erfordern. Die Grenze wird durch die Zugriffsmatrix festgelegt, die der Auftraggeber genehmigt.

Eine geschlossene Sitzung darf nicht das gesamte Forum zur Dekoration machen. Danach erhalten die Teams einen klaren Status: Entscheidung getroffen, Frage bis zu Daten zurückgestellt, ein separates Treffen angesetzt oder Priorität geändert. Details können beschränkt werden, aber die Teilnehmer müssen wissen, was als Nächstes zu tun ist.

Für jede Entscheidung ist es sinnvoll, die Begründung im zulässigen Umfang zu speichern. Der Satz „die Führung hat entschieden“ verliert schnell den Kontext. Der Eintrag „Priorität aufgrund einer gemeinsamen Verpflichtung bestätigt; Team A aktualisiert den Plan, Team B prüft die Abhängigkeit“ unterstützt die Umsetzung und reduziert wiederholte Diskussionen.

Wie plant man ein Hybridformat, eine Demo und ein technisches Backup?

Kurz gesagt: Remote-Teilnehmende müssen Fragen stellen, mit Dokumenten arbeiten und Entscheidungen beeinflussen können. Für jede Live-Demo braucht es ein abgestimmtes Backup, und die Regeln für Aufzeichnung, Präsentation von Roadmaps und Zugriff auf Materialien werden vor dem technischen Probelauf festgelegt.

Ein hybrides Product Day darf nicht als reine Bühnenübertragung mit passivem Chat konzipiert werden. Das W3C empfiehlt, die Bedürfnisse der Teilnehmenden, die Tonqualität, Untertitel oder Transkripte, die Beschreibung relevanter visueller Informationen und die Zugänglichkeit von Materialien von vornherein zu berücksichtigen. Fragen aus dem Saal müssen ins Mikrofon wiederholt werden, sonst verliert das Remote-Publikum einen Teil des Gesprächs.

Für verteilte Teams schaffen wir eine einzige digitale Quelle der Wahrheit. Dort liegen Pre-Reads, Arbeitsvorlagen, ein Entscheidungsprotokoll und freigegebene Materialien. In jedem Raum braucht es eine Person, die den Remote-Kanal im Blick behält und Fragen zurück in die Diskussion bringt.

Wenn ein Unternehmen eine vollwertige Organisation einer hybriden Veranstaltung benötigt, bauen wir getrennte Studio- und Vor-Ort-Routen auf: Anbindung, Ton, Bildschirmfreigaben, Abstimmungen, Gruppenarbeit und Ergebnisübergabe. Eine einzige Plattform löst diese Aufgabe nicht automatisch.

Die Live-Demo prüfen wir als Produktionskette: Zugang zur Umgebung, Produktversion, Benutzerkonto, Netzwerk, Kabel, Umschalten der Quellen, Skalierung der Benutzeroberfläche und Freigabe für die Anzeige von Daten. Als Backup eignen sich eine abgestimmte Aufzeichnung, Screenshots oder ein statischer Ablauf. Der Ersatz muss dieselbe Aussage belegen, um derentwillen die Demo ins Programm aufgenommen wurde.

Schnittstellen sollten in einer technischen Probe der Veranstaltung durchgespielt werden. Dabei werden die finalen Dateien, Übergänge zwischen Streams, Zugriffsrechte, Backup, Anzeige geschlossener Daten und die Übergabe von Entscheidungen ins gemeinsame Protokoll geprüft. Eine Probe des Auftritts ohne diese Schnittstellen zeigt nicht die Bereitschaft des Forums.

Die Aufzeichnungsregeln werden im Voraus festgelegt. Die Teilnehmenden werden über die Aufzeichnung informiert und die erforderliche Einwilligung wird gemäß den Vorgaben des Auftraggebers und dem anwendbaren Recht eingeholt. Der Auftraggeber legt außerdem Zugriff, Speicherfrist und zulässige Nutzung der Materialien fest. Eine Person muss das Vorgehen kennen, bevor ein sensibles Thema besprochen wird.

Artefakte, Metriken und der nächste Schritt

Kurz: Nach dem Forum bleiben Arbeitsdokumente und ein Kalender für die Fortsetzung. Bewertet werden sollte der Fortschritt der Entscheidungen: ob Verantwortliche benannt, Abhängigkeiten aktualisiert, fehlende Daten gesammelt wurden und ob die Teilnehmer zu den Kontrollpunkten zurückgekehrt sind. Der Eindruck der Gäste ergänzt dieses Bild, ersetzt es aber nicht.

Das Mindestpaket nach dem Product Day umfasst eine Portfolio-Karte, ein Abhängigkeitsregister, ein Entscheidungsjournal, eine Liste offener Fragen und freigegebene Materialien. Im Journal werden für jeden Eintrag Formulierung, Grundlage, Verantwortlichen, Teilnehmer der Fortsetzung, fehlende Daten, Zugriffsmodus und Kontrollpunkt angegeben.

Das Ergebnis hat vier Zustände:

1. Die Entscheidung ist festgehalten und von den Teilnehmern bestätigt.
2. Der Verantwortliche hat die nächste Aktion übernommen.
3. Die Aktion ist zum Kontrollpunkt ausgeführt oder aktualisiert.
4. Das Produkt- oder Geschäftsergebnis wurde vom Verantwortlichen innerhalb des Arbeitskontexts des Unternehmens überprüft.

Das Forum kann die ersten beiden Schritte qualitativ umsetzen. Die übrigen hängen von der regelmäßigen Steuerung nach der Veranstaltung ab. Daher darf man einem einzigen Tag weder die Beschleunigung der Produkteinführung noch den Anstieg einer Finanzkennzahl oder eine Steigerung des Engagements ohne Daten des Auftraggebers zuschreiben.

Nach der Veranstaltung ist es sinnvoll, organisatorische Kennzahlen zu prüfen: ob die Arbeitsgruppen das angegebene Ergebnis erreicht haben, ob die Zeit für Entscheidungen gereicht hat, ob die Materialien verfügbar waren und wo Probleme mit Ton, Übergängen oder Zugriff aufgetreten sind. Diese Beobachtungen helfen, den nächsten Zyklus zu verbessern, beweisen aber nicht den Produkteffekt.

Die Vorbereitung eines neuen Forums beginnen wir mit einem kurzen Briefing. Dafür brauchen wir die Aufgabe des Unternehmens, die Zusammensetzung der Teams, eine Karte der strittigen Fragen, Entscheidungsrechte, den Zugriffsmodus und das erwartete Dokumentenpaket. Danach stellen wir die Architektur des Programms, den Veranstaltungsort, den technischen Plan, die Rollen und das Budget zusammen.

Quellen

• Scrum Guides: offizieller Scrum-Leitfaden
• Atlassian Team Playbook: Abhängigkeiten abbilden
• Atlassian Team Playbook: Entscheidungsfindung und Rollen
• GOV.UK Service Manual: interdisziplinäres Team
• GOV.UK Service Manual: Governance-Prinzipien für agile Bereitstellung
• Product School: Produkt-Roadmap
• Aha!: Leitfaden für Produkt-Roadmaps
• W3C Web Accessibility Initiative: barrierefreie Veranstaltungen und Präsentationen
• GitLab Handbook: All-Remote-Meetings