Scrum - Diesen Unterschied macht das Framework und so nutzen wir es

Das Scrum Framework macht bei uns einen Unterschied: auch wenn wir von der typischen Scrum-Guide abweichen. Warum wir das tun und wie wir das Framework im Arbeitsalltag leben, erklären euch Peter und Richard.

Um unsere Vision voranzubringen, Freiräume für Gesundheitsfachkräfte zu schaffen, müssen wir insbesondere in unserer Produkt & IT Abteilung dafür sorgen, dass wir unsere Produkte fortlaufend an die Bedürfnisse unserer Kunden anpassen - dabei kommt es vor allem auf Geschwindigkeit an. Um auf Reaktionen im Markt schnell reagieren zu können, arbeiten unsere Teams mit dem agilen Framework Scrum. Wie wir Scrum leben und was wir seit der Einführung gelernt haben, haben uns Peter (DevOps Engineer) und Richard (Senior PHP Developer) erzählt. 

Andreas, Peter & Alex im Meeting, Quelle: Wawibox

Inhaltsverzeichnis

Warum nutzen wir Scrum bei Wawibox?
Richard: Fokus und Agilität sind innerhalb der Produktentwicklung zentral. Durch das Framework haben wir eine Grundstruktur, die uns hilft, uns auf das Wesentliche zu konzentrieren, und dennoch die Flexibilität, Prozesse auf unsere Bedürfnisse anpassen zu können. Zum einen haben wir durch das [User Story-Kickoff], Sprint Planning, Backlog Refinement, Daily Stand-up, Review und Retro eine abteilungsübergreifende Kommunikationsstruktur, die uns hilft uns bestmöglich abzustimmen und zielgerichtet zu arbeiten. Gerade das Produkt- und Sprint Backlog schaffen eine Transparenz, die alle sehr wertschätzen. Zum anderen wissen wir durch die Verknüpfung zu unserem OKR-Framework genau, welchen Beitrag wir mittelfristig leisten und schaffen es durch Scrum in kürzester Zeit Ideen umzusetzen.

Zudem besteht Klarheit über die Vorgehensweise und eine definierte Taktung der Intervalle. Wir wissen genau, welches Sprint-Ziel wir verfolgen und können in regelmäßigen Abständen für unsere Kunden Verbesserungen realisieren, was ihnen hilft, für eine kosteneffiziente und menschlichere Gesundheitsversorgung zu sorgen. 

Es ist klar, dass wir unseren Kunden schnell einen Mehrwert liefern möchten und wir Verbesserungen basierend auf dem Feedback im nächsten Sprint vornehmen können.

Der große Vorteil, den wir in Scrum sehen ist, dass der Scope zum Ziel variabel ist. 

Auf neuen Input und Unvorhergesehenes können wir schnell reagieren, indem wir durch Rücksprachen mit dem Product Owner schnell Entscheidungen treffen können, wie es mit der Story weitergeht, um sie zeitnah abzuschließen.  

Diese Flexibilität schätzen wir alle sehr, denn sie sorgt dafür, dass wir umsetzungsstark bleiben. 

Wo weicht Wawibox vom Scrum-Guide ab?
Peter: Unser IT-Dreamteam hat sich dazu entschieden, mit einer Sprintdauer von zwei Wochen zu arbeiten. Um schnell Learnings generieren zu können, haben wir das Intervall von üblicherweise vier Wochen auf zwei verkürzt. Gerade zu Beginn und mit der Einführung von Scrum war es uns und unseren Entwickler:innen wichtig, dass viel experimentiert und getestet werden kann. Sich regelmäßiges Feedback einzuholen, um schnell Optimierungen an den Scrum-Zeremonien vornehmen zu können, war ebenfalls ein zentraler Punkt. Das ist Teil unserer Unternehmenskultur: Wir wollen schnellstmöglich Erfahrungen sammeln und fortlaufend optimieren - bevor wir uns zu lange an der Planung oder einer Idee aufhalten, gehen wir lieber früher in die Testphase und sammeln unsere praktischen Erfahrungen.

Zur Aufwandsschätzung der Tickets werden Story Points genutzt. Diese basieren auf der Fibonacci Reihe. Je mehr Story Points ein Ticket hat, desto komplexer ist es. 

Seit der Einführung von Scrum wurde unserem IT-Team immer klarer, welche Anzahl an Story Points jeweils einem Ticket zugewiesen werden kann - auch das war ein Lernprozess, der uns nun aber hilft, unsere eigenen Kapazitäten besser planen zu können. So kommt es jetzt nicht mehr vor, dass sich verkalkuliert wird und das Sprint-Ziel in Gefahr ist.

Die Tickets selbst werden im ersten Schritt nach Skill und Interesse zugewiesen, im zweiten Schritt gleichen wir die Zuordnung mit den Kapazitäten ab. So hat jeder von uns ein hohes Maß an Selbstbestimmung, was uns im IT-Team sehr wichtig ist.

Was hat sich seit der Einführung verändert?
Peter: Eine Erkenntnis ist, dass unsere Entwickler:innen bereits bei der Erstellung der Story involviert sein sollen, um den technischen Part, das Wie, zu analysieren. Wurde sich mit der technischen Umsetzung der Business-Sicht, also dem Was, erst im Backlog Refinement oder Sprint Planning beschäftigt, dann kam dies regelmäßig zu Herausforderungen. So haben wir mittlerweile ein User Story Kickoff eingeführt, der außerhalb vom Sprint Planning stattfindet, damit sich die Entwickler bereits frühzeitig mit dem technischen Part einer Story auseinanderzusetzen können.

Ein weiteres Learning ist, dass es unglaublich wichtig ist auch unsere externen Entwickler:innen in die Scrum-Zeremonien zu integrieren. Zu Beginn ist alles über einen externen Entwickler gelaufen, der die Informationen weitergegeben hat. Wir waren der Meinung, dass wir so zeitliche Ressourcen einsparen können. Dann haben wir uns dazu entschieden, dass alle Entwickler:innen an den Zeremonien teilnehmen können - egal ob intern oder extern. Das Resultat war eine effizientere Kommunikation, bessere Absprachen und eine bessere Zusammenarbeit.

Was hat sich mit der wachsenden Teamgröße verändert?
Richard: Uns war klar, dass die Kommunikationswege komplexer werden, was die größte Herausforderung war. Der Scrum Guide besagt, dass ein Scrum Team aus maximal neun Personen bestehen soll - Im Mai 2022 bestand unser Scrum Team aus 11 Mitwirkenden, die sich in einem täglichen Daily-Stand-Up austauschen. Auch diese Flexibilität im Umgang mit dem Scrum Guide haben wir uns erlaubt ;-) 

Das Daily Stand-up dauert allerdings nach wie vor 15 Minuten und jeder unserer Entwickler:innen kann seinen Fortschritt, Herausforderungen und geplanten Beitrag für die nächsten 24 Stunden vorstellen, die zur Erreichung des Sprint-Ziels beitragen. Die weiteren Zeremonien wurden verlängert, und bleiben weiterhin innerhalb der Scrum-Timeboxen.

Im Backlog Refinement und im Story Kickoff sind alle Entwickler:innen eingeladen. Wer dann tatsächlich an diesen Meetings teilnimmt, hängt von der Agenda ab. So nehmen beispielsweise am Story Kickoff nur die Entwickler:innen teil, die das Feature aktuell bearbeiten. So kann eine effiziente Kommunikation garantiert werden. 

Du bist auch Scrum interessiert?

Dann schau doch einfach mal bei uns im Office vorbei. Unser IT- und Produktteam tauscht sich gerne mit Dir aus und teilt Erfahrungen!