Ein Projekttag
Bei NewVOSTRA haben wir zwei Projekttage (Mittwoch und Donnerstag). An diesen beiden Tagen arbeiten alle für das Projekt und es finden auch die meisten Besprechungen statt. Jeden zweiten Mittwoch ist zudem Sprintwechsel (= Abschluss einer zweiwöchigen Projektphase und Start einer neuen). Die folgende Grafik stellt exemplarisch einen solchen Sprintwechsel dar und zeigt auf, welche Zeremonien nacheinander stattfinden.
Der gemeinsame Projekttag startet um 08.45 Uhr mit einem Check-in. Beim Check-in stimmen wir uns gemeinsam auf den Projekttag ein und informieren uns über Besonderheiten zum Tag oder zum Projekt. Die Mitarbeiterinnen und Mitarbeiter haben beim Check-in die Plattform Themen anzusprechen, die sie beschäftigen. So können sowohl arbeitsbezogene als auch persönliche Hürden thematisiert werden.
Die Unconference folgt unmittelbar auf das Check-in. Diese Zeremonie gilt nicht als "Scrum-Zeremonie". Bei NewVOSTRA wurde die Unconference eingeführt, um den Tag zu planen. Im Backlog können die Mitarbeiterinnen und Mitarbeiter zu besprechende Themen eintragen. Im Gesamtteam wird dann während der Unconference diskutiert, welche dieser Themen priorisiert werden und demnach in die Tagesplanung einfliessen sollen. Werden nicht die gleichen Personen benötigt, können Themen auch zeitgleich besprochen werden. Je nachdem werden einzelne zugunsten anderer dringenderer Themen zurückgestellt und für einen anderen Projekttag eingeplant.
Im Review zeigen die Teammitglieder einander, was im letzten Sprint gemeinsam erreicht wurde. Das Team gibt Feedback und hat die Möglichkeit Fragen zu stellen, wenn etwas unklar ist. Ebenfalls bewertet der Product Owner, ob die Sprintziele erreicht wurden und das Gezeigte den Anforderungen entspricht.
Im Planning werden gemeinsam die Ziele für den nächsten Sprint besprochen und das Team verpflichtet sich, dass die Umsetzung dieser Ziele realistisch und machbar ist. Zum Planning gehört ebenfalls die Bug Triage. Dort werden die neu aufgetretenen Bugs (= Fehler), die beim Testen bemerkt wurden, nach ihrem jeweiligen Aufwand zum Beheben geschätzt und auf die Entwickler verteilt.
Bei der Retrospektive (kurz Retro) wird auf den vergangenen Sprint zurückgeblickt. Dabei werden Ereignisse und Bemerkungen in folgende drei Kategorien aufgeteilt: "I wish", "I like" und "Massnahmen". Die Retro findet in einem ersten Schritt innerhalb des Delivery-Teams statt. Im kleinen Rahmen lassen sich Themen ansprechen, die nicht unbedingt mit dem ganzen Projektteam geteilt werden müssen.
In einem zweiten Schritt werden die im Delivery-Team besprochenen Punkte mit dem gesamten Team geteilt. Dabei kommen auch virtuelle Boards und Collaboration-Tools zum Einsatz. Bei der Retro geht es uns darum, die Arbeit des gesamten Teams kritisch zu reflektieren und allenfalls Massnahmen zu formulieren. Dabei nehmen wir auch immer kritisch Bezug auf unsere Erfolgsfaktoren und passen diese, wenn nötig, an. Unsere Erfolgsfaktoren sind die folgenden:
- Vorbereitung
- Stückelung
- Code-Qualität (Dev-Sicht)
- Produkt-Qualität (User-Sicht)
- Disziplin
- Infrastruktur
- Arbeitsklima & Kommunikation
Wichtig ist hierbei, nicht nur Negatives verbessern, sondern auch die positiven Punkte beibehalten zu wollen. Die Retro ist dazu da, sich als Team zu verbessern. Es geht nicht darum, einzelne Personen blosszustellen oder anzuschuldigen.
Beim Check-out lassen wir als Team den Tag zusammen ausklingen. Dabei werden gewonnene Erkenntnisse geteilt und eventuelle Spannungen des Tages aus dem Weg geschaffen. Das Check-out schweisst uns als Team zusammen und darf auch ab und zu etwas humorvoll verlaufen.
Weitere Zeremonien
Nebst den oben genannten Zeremonien, die mindestens jede zweite Woche beim Sprintwechsel stattfinden, kommen noch weitere Zeremonien zum Einsatz.
Scrum basiert auf Sprints. Ein Sprint ist ein vorgegebener Zeitzyklus, in dem sich die Arbeiten und Zeremonien wiederholen. Bei uns im Projekt NewVOSTRA dauern Sprints jeweils zwei Wochen.
Das Weekly ist eine einmal wöchentlich stattfindende Besprechung im Team. Diese wird in den einzelnen Delivery-Teams durchgeführt. Dabei wird über die laufenden Arbeiten informiert, allfällige Probleme und Fragen besprochen sowie geschaut, ob der Zeitplan eingehalten werden kann und gegebenenfalls Massnahmen getroffen.
Jeden dritten Monat, jeweils vor einem Release-Wechsel, findet das Release Planning statt. Dabei bestimmen die Delivery-Teams zusammen mit dem Product Owner die Ziele für den nächsten Release basierend auf den bereits geleisteten Entwicklungsarbeiten und der Roadmap. Die definierten Ziele basieren auf einer detaillierten Beschreibung der Epics, die in Stories ausgedrückt werden. Die von den Delivery-Teams ausgewählten Stories werden via Refinement und nach einer genaueren Aufwandschätzung zweiwöchigen Sprints zugeordnet.
Letzte Änderung 21.09.2021
