Hinter den Kulissen: Scrum-Prozess bei Finfox

Längst mehr als ein Buzzword – die Scrum-Methode hat sich als State of the Art in der agilen Softwareentwicklung durchgesetzt. Wir werfen einen Blick hinter die Kulissen von Finfox und zeigen, wie wir den Scrum-Prozess bei der Entwicklung unserer mobilen Anwendungen FinfoxAdvice und FinfoxTouch einsetzen und davon profitieren. Aber auch, wo und warum wir in gewissen Bereichen bewusst von den theoretischen Vorgaben abweichen.

Pflege des Backlogs

Das Backlog enthält sämtliche Arbeitsaufträge, die in naher oder ferner Zukunft umzusetzen sind. Wir haben das Backlog zweigeteilt. Ein erster Teil umfasst die fachlichen Anforderungen, die sogenannten User Stories, die in der Verantwortung der Business Analysten und des jeweiligen Product Owners (d.h. der internen Auftraggeber) liegen und von diesen priorisiert werden. Der zweite Teil enthält technische Stories wie beispielsweise Versions-Upgrades oder Verbesserungen der Code-Qualität; also Aufgaben, die vom Entwicklungsteam identifiziert und gepflegt werden.

Scrum Board

Das Scrum Board gibt jederzeit über den aktuellen Stand der Bearbeitung Auskunft: Welche Aufgaben stehen an, sind in Arbeit oder bereits erledigt? Das Board führen wir rein elektronisch mittels eines in der Branche etablierten Tools. Ein physisches Board mit Papierzetteln pro Story existiert bei uns nicht. Da heutzutage selbstverständlich ein Teil der Arbeit im Homeoffice erbracht wird, liegen die Vorteile des elektronischen Boards auf der Hand.

Organisation in Sprints

Die Planung der Entwicklungsarbeiten in der Form von Sprints (Iterationen) ist für uns sehr wertvoll, da sich das Team in regelmässigen Abständen strukturiert mit der Detailplanung auseinandersetzt und sich bewusst zu einem bestimmten Zeitplan committet.
Ein Sprint dauert bei uns eher kurz, üblicherweise 2 oder in Ausnahmefällen auch 3 Wochen. Gemäss Scrum-Vorgabe sind 2 bis 4 Wochen möglich. Wir bevorzugen die kurzen Zeitintervalle, da wir die Planning Meetings lieber öfters durchführen und dafür etwas kürzer halten. Zudem können wir so sehr schnell auf Kundenwünsche reagieren oder wenn nötig kurzfristig die Priorisierung bei der Planung des nächsten Sprints anpassen.
Bei Ferienabwesenheiten oder Feiertagen können die Sprints auch mal etwas länger dauern. Wir streben an, dass der gesamte Workload für das Team pro Sprint etwa konstant ist.

Sprint Planning Meeting

Das Sprint Planning Meeting dient dazu, den «Inhalt» eines Sprints zu definieren, also die detaillierte Planung für die nächsten 2 bis 3 Wochen festzulegen. Dieses Meeting führen wir ziemlich genau gemäss Scrum-Lehrbuch durch. Der Product Owner stellt die Stories vor, das Team schätzt daraufhin für jede Story die Umsetzungsaufwände in «Story Points» und plant die Stories entsprechend der Teamkapazität ein. Wobei für uns vereinfacht gilt, dass ein Story Point (die abstrakte Masseinheit für Komplexität in Scrum) einem Personentag Arbeitsaufwand entspricht. Die Stories verteilen wir bereits im Planning Meeting möglichst genau auf die einzelnen Teammitglieder, um sicherzustellen, dass alle gemäss ihren jeweiligen Kernkompetenzen und Arbeitspensen ausgelastet sind.

«Wir planen jeweils ca. 80 % der innerhalb des Sprints verfügbaren Teamkapazität für die Arbeit an den Sprint Stories ein. Die restlichen 20 % sind für übergreifende Meetings, Reviews oder nicht planbare kurzfristige Anfragen vorgesehen.»

Thomas Rutz
Scrum Master und Teamleiter Mobile Applications bei Finfox

Daily Scrum

Im Daily Scrum Meeting tauschen sich die Mitglieder des Entwicklungsteams täglich zur selben Zeit während ca. 15 Minuten über den Fortschritt der Arbeit und offene Fragen aus. Product Owner und Business Analysten nehmen nicht daran teil. Je nachdem können sich aus dem Daily Scrum Anfragen an den Product Owner ergeben oder auch Punkte, die im Entwicklungsteam bilateral weiter zu vertiefen sind.

Sprint Review Meeting

Das Review Meeting findet üblicherweise am Ende eines Sprints statt und dient dazu, die Arbeitsergebnisse vor dem Team und den Auftraggebern zu präsentieren. Bei diesem Meeting weichen wir stark von der Scrum-Vorgabe ab, weil wir es nicht nur einmal pro Sprint durchführen, sondern wöchentlich und unabhängig vom Sprint-Rhythmus. Streng genommen ist dieses Meeting kein Sprint Review Meeting im Sinne von Scrum. Vielmehr präsentieren wir fertiggestellte Stories, besprechen offene Fragen oder mögliche Lösungsansätze zu neuen Anforderungen, deren Umsetzung noch nicht unmittelbar geplant ist.

Ein grosser Vorteil der wöchentlichen Durchführung besteht für uns darin, dass abgeschlossene Stories viel rascher den internen Auftraggebern präsentiert werden können, als wenn dies erst am Sprint-Ende geschehen würde. Bei Bedarf können allfällige Korrekturen somit meistens noch im aktuellen Sprint erfolgen.

Product Increment

Ein Product Increment ist ein Softwarepaket, das im klassischen Scrum-Prozess jeweils auf das Sprint-Ende hin finalisiert wird und alle umgesetzten Anforderungen enthält. Die Fertigstellung und Auslieferung eines solchen Increments per Sprint-Ende praktizieren wir nicht. Stattdessen werden testbare Deployment-Pakete üblicherweise 1x pro Woche oder je nach Bedarf erstellt, unabhängig vom Sprint-Zyklus.

Sprint Retrospective

Auch Retrospective Meetings dürfen bei uns nicht fehlen. Allerdings führen wir diese nur alle paar Monate und nicht wie üblich am Ende jedes Sprints durch. Wir erachten dieses Meetingformat als wertvoll, weil wir durch den gemeinsamen Blick auf die zurückliegenden Sprints unsere Zusammenarbeit stetig optimieren und uns als Team weiterentwickeln können. Die Meetings werden immer wieder anders ausgestaltet und abwechselnd von den Mitgliedern des Entwicklungsteams organisiert und moderiert.

«Scrum bedeutet für uns: klare und transparente Aufträge, eine verlässliche Detailplanung und ein rasches Feedback zu den umgesetzten Aufgaben. Das steigert die Effizienz und Qualität unserer Arbeit massgeblich. Die regelmässige Durchführung der Scrum Meetings ist zudem extrem förderlich für die interne Kommunikation und den Teamspirit.»

Elsa Gafner
Front End Developer bei Finfox

Fazit

Bei der Softwareentwicklung unserer mobilen Anwendungen FinfoxAdvice und FinfoxTouch lehnen wir uns stark an die Scrum-Methode an, auch wenn es kein Scrum in Reinkultur ist. Wir verwenden diejenigen Elemente, die uns einen Mehrwert bringen und verzichten auf Aspekte, die in unserem individuellen Setup mehr Aufwand als Nutzen generieren würden.
Insgesamt wird das angewandte Scrum-Vorgehensmodell vom Entwicklungsteam als sehr wertvoll und gewinnbringend geschätzt.