Scrum-Ereignisse im Alltag bei der Intersim AG

Scrum-Einführung

Nach Scrum zu arbeiten kling spannend, klingt gut, klingt vielsprechend. Doch nach Scrum zu arbeiten bedeutet auch eine neue Herausforderung, bedeutet sich umzustellen, bedeutet neue Prinzipien zu verstehen und danach zu leben.

Scrum ist in der Softwareentwicklung aktuell in aller Munde. Oder besser gesagt, es ist schon eine Weile in aller Munde und hat sich in den letzten Jahren an vielen Orten etabliert. Damit ihr euch vorstellen könnt, was es für die tägliche Arbeit bedeutet nach Scrum zu arbeiten, möchte ich euch näherbringen, wie wir bei uns die Scrum-Ereignisse durchführen.

Übrigens, wem Scrum als agile Produktmanagementmethode nichts sagt, findet im WWW unzählige Informationen. Als Quelle für verlässliche Informationen kann ich insbesondere scrum.org empfehlen. Hier habe ich auch meine Zertifizierung zum Professional Scrum Master gemacht. Als Grundlage für die Intersim gilt: ein Sprint dauert 2 Wochen. Das heisst, innerhalb des Projektteams werden alle zwei Wochen die Arbeiten der nächsten zwei Wochen geplant und die Arbeiten der letzten zwei Wochen Revue passiert.

Scrum-Ereignisse

Refinement

Wir besprechen rund eine Woche vor dem nächsten Sprint, was der Inhalt des selbigen sein könnte und klären insbesondere folgende Fragen:
Ist bezüglich den geplanten Arbeitspaketen (User Stories) alles klar oder gibt es Fragen?

• Gibt es User Stories mit Abhängigkeiten zueinander?
• Gibt es User Stories welche wir noch nicht umsetzen können?
• Zudem werden nach dem Refinement von den Entwicklern die User Stories so gestückelt, dass sich daraus mehrere Tasks ergeben, welche dann während eines Sprints abgearbeitet werden können.

Planning

Zu Beginn des Sprints, planen wir was wir effektiv im neuen Sprint umsetzen. Im Normallfall sind dies User Stories, welche bereits im Refinement diskutiert wurden. Im Ausnahmefall können User Stories auch noch ersetzt werden oder es werden Arbeiten geplant, welche im letzten Sprint nicht erledigt werden konnten. Im Planning wird zwar immer darauf geschaut, dass nur eingeplant wird was wir als Team zu leisten vermögen Dennoch kann es durch Krankheiten oder anderen unvorhergesehenen Ereignissen dazu kommen, dass zu viel Workload zugemutet wird. Die User Stories werden ausserdem bereits fix untereinander aufgeteilt. In der Theorie von Scrum wäre es eigentlich so, dass erst während des Sprints die Software-Entwickler untereinander schauen wer was macht. Bei uns ist dies aber aufgrund der klaren Verteilung von Kompetenzen (Backend/Frontend) bereits vorher gegeben.

Daily

Während des Sprints tauschen wir uns jeden Morgen kurz aus damit jeder im Bilde ist was die anderen beschäftigt und ob es irgendwo spezielle Herausforderungen gibt. Das Daily ist nur eine kurze Angelegenheit. Allfällige längere Diskussionen werden separat mit den betroffenen Personen im Anschluss ans Daily geführt.

Retrospektive & Review

Im Normalfall sind Retrospektive und Review zwei separate Ereignisse. Bei uns hat es sich jedoch etabliert, dass wir dies zusammen machen. Zum Abschluss des Sprints setzten wir uns somit zusammen und unterhalten uns über den vergangenen Sprint. Zuerst präsentieren alle ihre erledigten User Stories (Review) und danach diskutieren wir folgende Punkte (Retro):

• Was war gut?
• Was können wir besser machen?
• Konnten wir alles erledigen was wir uns vorgenommen haben?

Die Erkenntnisse aus der Retrospektive fliessen dann jeweils direkt in die tägliche Arbeit ein.

Learnings

Als Projektleiter habe ich in Bezug auf die Scrum-Ereignisse bisher einiges gelernt und auch Punkte identifiziert, wo wir uns noch verbessern müssen:

• Durch Homeoffice ergeben sich weniger spontane Gespräche. Das Daily ersetzt diese Gespräche nicht. Es ist wichtig, nebst dem Daily, ständig im Team in Kontakt zu bleiben.
• Alle im Team müssen den Sinn eines Scrum-Ereignisses verstehen. Scrum-Ereignisse nach Handbuch durchzuführen aber das Ziel nicht zu kennen, ist schwierig.
• Bei kleinen Projekten dürfen die ScrumEreignisse kleiner und kürzer gehalten werden als bei grossen Projekten. Durch den spontanen Austausch wird bereits sehr viel nebenher erledigt.
• Die Einführung eines fixen Scrum Masters je Projektteam ist unausweichlich. Wenn der Projektleiter die Moderation von ScrumEreignissen übernimmt, fehlt die Aussensicht und der Workload für den Projektleiter wird zu gross.
• Innerhalb des Unternehmens müssen Leitlinien gesetzt werden damit alle Teams im ähnlichen Rahmen arbeiten. So können Teamwechsel von SoftwareEntwicklern leichter fallen.

Mein vorläufiges Fazit ist somit, dass wir uns in Bezug auf die Scrum-Ereignisse unbedingt weiterentwickeln müssen und auch wollen. Allgemein erfordert die Einführung von Scrum in einem Unternehmen viel Geduld, Leidenschaft und alle müssen am gleichen Strick ziehen.

PS: Natürlich gibt nebst den Scrum-Ereignissen viele weitere wichtige Aspekte des Arbeitens nach Scrum. Doch dazu vielleicht ein anderes Mal mehr.

Verwandte Themen

Weiterführende Projekte und Inhalte zum Thema