SCRUM – Wie verbessert Droptica kontinuierlich seine Arbeit?

Wir haben kürzlich darüber geschrieben, warum SCRUM die Qualität der Softwareentwicklung verbessert und warum Remote Scrum-Teams oft eine gute Wahl sind. 

Heute werden wir über einen sehr wichtigen, oft vernachlässigten Teil von Scrum sprechen, der zu verminderter Leistung, Verzögerungen und Fehlern führt - Sprint Retrospektive. 

Was ist eine Sprint Retrospektive?

Dies ist eines der Meetings in der SCRUM-Methodik. Das Meeting findet regelmäßig am Ende jedes Sprints statt. In unserer Drupal-Entwicklungsagentur halten wir alle zwei Wochen ein Meeting ab. Während des Meetings analysiert das Entwicklungsteam die vorherigen Sprints und überlegt, was noch verbessert werden kann – wie man Fehler und Blockaden beseitigt und die Arbeit beschleunigt.

Wie profitiert der Kunde davon?

Das Meeting dauert in der Regel nicht länger als 15-60 Minuten. Eine Sprint Retrospektive hat normalerweise drei bis sechs Teilnehmer, je nach Größe des Teams, das das jeweilige Projekt durchführt. Andere Unternehmen könnten diesen Prozess anders umsetzen. Es ist leicht zu berechnen, dass dieses Meeting den Kunden mindestens mehrere Mannstunden kosten kann. Lohnt es sich? 

Ja – ohne Frage! Während jedes Meetings schlägt das Team Verbesserungen vor und stimmt zu, einige davon im nächsten Sprint umzusetzen. In vielen Fällen verkürzen diese Verbesserungen die Durchlaufzeit. Das Änderungsmeeting findet einmal statt, und die Verbesserung wird kontinuierlich in den nachfolgenden Sprints angewendet. Nach einer Anzahl von Sprints können wir beträchtliche Zeit- und Kosteneinsparungen erzielen.

Wie führen wir bei Droptica die Sprint Retrospektive durch?

Zu diesem Zweck verwenden wir ein Google Docs – Tabellenblatt. Das Dokument hat fünf Spalten:

1. Datum;
2. DROP – was wir aufhören sollten zu tun;
3. KEEP – was wir weiterhin tun sollten;
4. IMPROVE – was verbessert werden muss;
5. ADD – was hinzugefügt werden muss.

Während des Meetings schlägt jede Person aus dem Entwicklungsteam verschiedene Verbesserungen vor, die sie gerne sehen würden, und schlägt vor, was entfernt, korrigiert, hinzugefügt werden sollte usw. Nachdem alle gesprochen haben, wählt das Team aus, welche der Vorschläge sie im nächsten Sprint umsetzen möchten. Wir versuchen, 1-3 Vorschläge umzusetzen, um zu vermeiden, dass zu große Änderungen vorgenommen werden. Wir identifizieren auch den Verantwortlichen für die Änderung, der für die Umsetzung der spezifischen Änderung verantwortlich ist. 

Beispiele für Verbesserungen in der Softwareentwicklung und DevOps

Nachfolgend finden Sie eine Liste ausgewählter Verbesserungen, die in mehreren unserer Projekte vorgeschlagen wurden. 

• Wir führen automatische Tests häufiger durch, um alle Bugs schneller zu beheben. Dies ermöglicht es uns, unangenehme Überraschungen kurz vor dem Deployment zu vermeiden;
• Wir werden die Geschwindigkeit beim Aufbau einer neuen Version der Website auf dem Testserver verbessern, indem wir die Datenbankgröße um etwa 90 % reduzieren;
• Bevor wir mit der Arbeit an einer Aufgabe beginnen, sprechen wir sowohl über die Geschäftsziele als auch die Durchführung der Aufgaben aus der Sicht der Softwareentwicklung, um die Konsistenz der gesamten Anwendung zu wahren und Lösungen zu wählen, die optimal für das Projekt sind;
• Code-Reviews sollten von mindestens zwei Personen durchgeführt werden;
• Wir verwenden git-flow und jede Aufgabe wird auf ihrem eigenen Branch durchgeführt. Alle Tests und Code-Reviews werden auf diesem Branch durchgeführt. Wenn diese durchgeführt sind, fügen wir den Branch mit dem Hauptentwicklungszweig zusammen; 

Beispiele für Verbesserungen in der Arbeitsorganisation

• Wir senden täglich eine kurze Nachricht an den Kunden (Product Owner) über Slack mit einer Zusammenfassung dessen, was wir seit gestern getan haben und was wir heute tun werden.
• Wir teilen die Aufgaben in Jira in kleinere auf, sodass eine Aufgabe nicht länger als 3-4 Stunden dauert. Dadurch können wir den Fortschritt der Arbeiten besser verfolgen und schnell auf Verzögerungen reagieren. 
• Wenn sich während eines Sprints herausstellt, dass die Aufgabe schwieriger ist, als wir erwartet hatten, ändern wir die Story Points für die Aufgabe. 
• Wir aktualisieren kontinuierlich unsere Dokumentation. Wir halten uns an das Prinzip, dass, wenn eine Frage mindestens zweimal gestellt wird, sie in die Dokumentation aufgenommen werden sollte. 
• Der für Videoanrufe verwendete Computer muss immer mit einem Ethernet-Kabel mit dem Internet verbunden sein – das beseitigt die Ärgernisse von unterbrochenen und verzögerten Videoanrufen.
• In vielen Projekten haben wir auch die Bereitstellung aus dem DoD entfernt – normalerweise finden diese Bereitstellungen alle zwei Wochen oder einmal im Monat statt, manchmal sogar auf der Seite des Kunden. Wenn wir einen wöchentlichen Sprint haben, sollte uns das nicht daran hindern, die Aufgabe abzuschließen.
• Planung unter Berücksichtigung von Support – auf der Basis vorheriger Sprints wissen wir, wie viel Zeit wir für Dinge aufwenden, die nicht geplant werden können (zum Beispiel Hotfixes, die vom Kunden hinzugefügt wurden).

Zusätzliche Sprint Retrospektive-Tools

Meistens reicht ein einfaches Tabellenblatt aus, um die Sprint Retrospektive durchzuführen. Kürzlich haben wir jedoch begonnen, die externe FunRetro-Anwendung (FunRetro | Improve your team with fun sprint retrospectives) zu verwenden. Sie hilft, die Sprint Retrospective-Meetings zu verbessern. Wir ermutigen Sie, es auszuprobieren, besonders da die Anwendung eine kostenlose Version anbietet.

Zusammenfassung

Bei Droptica hat uns die Scrum Retrospective greifbare Ergebnisse gebracht. Ich empfehle jedem Team dringend, auf diese Weise objektiv in die Vergangenheit zu blicken, auch wenn sie SCRUM nicht im Projektmanagement verwenden. Sie können einfach ein 1-2-stündiges Meeting alle zwei Wochen im Kalender einplanen, um darüber zu sprechen, was verbessert werden kann. Sie können in wenigen Wochen ziemlich bedeutende Ergebnisse erzielen. Probieren Sie es selbst aus!