Zusammenfassung:
Die Release-Demonstration (in SCRUM "Sprint-Demo/Sprint Review") ist ein Format zur Vorstellung der umgesetzten Entwicklungspakete. In einem definierten Release Zeitraum können so ein oder mehrere Entwicklungspakete zu einem Release Paket zusammengefasst werden. Die Projektbeteiligten werden zur Vorführung des funktionsfähigen Softwarestandes ggf. inklusive Hardwarestandes eingeladen. Diese Demonstration umfasst hauptsächlich die Darstellung der Entwicklung aus Sicht der Kunden über den verbesserten Nutzen / Wert des Produkts [(User-)Business-Value]. Beispielsweise wäre dies die Vorführung von praktischen Anwendungsbeispielen, angelehnt an die umgesetzten User Stories. |
Struktur / Ablauf:
Als Veranstaltungsort sollte ein geeigneter Raum in Bezug auf die Größe, Bestuhlung und Präsentationsmöglichkeiten gewählt werden.
Der Product Owner bildet zusammen mit dem SCRUM-Master ein Organisationsteam. Während der Product Owner verstärkt auf die Inhalte fokussiert bleibt, richtet der SCRUM-Master seinen Blick auf den Rahmen der Veranstaltung.
Allgemeiner Ablauf:
- Begrüßung
- Agenda mit Fokus für den Zeitraum nach der letzten Release-Demonstration
- Einzelvorträge oder Gesamtvortrag über die neuen Funktionalitäten mit paralleler Vorführung
- ggf. nachgelagerte Vorführung
Abschluss mit Dank an die Beteiligten und besonderen Dank an besonders herausragende Leistungen
- Kleinen Ausblick (Roadmap) über den weiteren Fokus ggf. mit kleiner Statistik über den Entwicklungsprozess (behobene Fehler und durchgeführte Verbesserungen, Releaseinformationen, Prozessveränderungen etc.)
Zur Verbesserung der Vortragstechnik und des Formats kann zu Studienzwecken die Demonstration gefilmt werden. Ebenso nützlich können sich die Aufnahmen als Grundlage zu Schulungsunterlagen oder zusätzlichen Dokumentationen herausstellen. Aus "Compliancegründen" wird es notwendig sein, dass das Einverständnis der Teilnehmer/-innen und des jeweiligen Vortragenden vorab eingeholt werden. |
Teilnehmer/-innen:
- Alle Beteiligten am Projektgeschehen und Besucher/-innen aus anderen Abteilungen im Unternehmen
- Stake Holder
Sinnvolle Fragestellungen zur Vorbereitung:
- Was ist der Schwerpunkt der Präsentation?
- Wer kann / möchte welche Themen präsentieren?
- Wie kann ich die Leistungen der Entwicklung entsprechend präsentieren (z.B.: Statistik)
- Welche Stake Holder sind für die jeweilige Präsentation besonders wichtig?
Ziel / Ergebnis des Meetings:
- Darstellung und Reflexion der erbrachten Leistung
- Update der beteiligten Projektrollen (Stake Holder, Team, Manager/-in)
- Präsentation eines fertigen Softwarestandes
- Synchronisationspunkt mit anderen agilen Projekten
Was das Meeting nicht ist:
- Eine Plattform zur ausführlichen Diskussion zwischen Stake Holdern, warum "jetzt" eine Lösung so umgesetzt wurde oder ggf. eben nicht
- Eine Plattform, um eine Unzufriedenheit, entstehend aus dem Eindruck eines nicht "zufriedenstellenden Entwicklungsfortschritts" öffentlich anzuprangern. Diese Form der Eskalation ist äußerst unprofessionell und dient meist nur egozentrischen Zielen
- Eine "Was-wäre-wenn-Veranstaltung" - kurze und prägnante Ideen und Änderungswünsche sind durchaus erwünscht und können für zukünftige Entwicklungen eingebracht werden. Diese werden vom Product Owner vermerkt und in einem Folgetreffen (Grooming) ggf. weiter vertieft. NICHT aber im Rahmen der Release-Demonstration