Deutsche Bahn
zurück zur Übersicht

Medienpaket

Wie Scrum-Teams die App DB Navigator weiterentwickeln

Deutsche Bahn treibt Entwicklung des DB Navigators voran • Vier Kundennutzen stehen im Fokus • Scrum-Teams beschleunigen die Umsetzung

Unterwegs Tickets buchen, den Wagen mit dem reservierten Platz finden oder an den nächsten Umstieg erinnert werden – der DB Navigator bietet Reisenden in allen Situationen die passenden Services und Informationen. Das ist der Anspruch an die beliebte Reise-App. Weil sich das Mobilitätsverhalten der Menschen laufend verändert, entwickelt die Deutsche Bahn (DB) die App kontinuierlich weiter, mit dem Fokus auf vier Anwendungen:

Wer im DB Navigator bucht, soll durch das Hinterlegen von Informationen mit noch weniger Klicks an das Ticket kommen.

Nutzer sollen die Funktionen im DB Navigator an ihr individuelles Reiseverhalten oder Informationsbedürfnis anpassen und die App so personalisieren können – egal ob sie als Pendler, mit der Familie oder auf Geschäftsreise unterwegs sind.

Die richtige Information zur richtigen Zeit: Je nach Reisesituation soll die App auf der Startseite zum Beispiel bei der Reiseplanung Auskunft zum Gepäckservice geben und unterwegs aktuelle Informationen zur Verbindung anzeigen.

Die App soll Nutzer so schnell und einfach wie möglich zu den passenden Informationen und Services leiten. Die DB arbeitet kontinuierlich daran, das Nutzererlebnis zum Beispiel mit neuen Funktionen wie persönliche Anrede und Interaktionsmöglichkeiten zu verbessern.

Faktenblatt DB Navigator  PDF | 0,17 MB

Entwicklungen erreichen Kunden schneller

Jede der vier strategischen Entwicklungen ist mit konkreten Schritten für einen verbesserten DB Navigator versehen, wie zum Beispiel die Buchung verkürzen oder einen Button in der App umgestalten. Im Büro von Armin Böhmer hängen diese sogenannten Anforderungen auf bunten Klebezetteln an der Wand. Der 43-jährige Wirtschaftsingenieur ist der sogenannte Product Owner des DB Navigators, zu Deutsch der Produkteigentümer.

Seit zwölf Jahren arbeitet er bei der Bahn. In die neue Rolle als Product Owner schlüpfte er im Mai 2016, als die Deutsche Bahn den Entwicklungsprozess der App auf die agile „Scrum“-Arbeitsweise umstellte. „Seitdem planen wir weniger und setzen mehr um“, sagt Böhmer. „Neue Ideen erreichen App-Nutzer jetzt viel schneller als vorher“.

So treiben Scrum-Teams die Entwicklung der App DB Navigator voran

Geordnetes Gedränge herstellen

Der Begriff „Scrum“ kommt aus dem Rugbysport und beschreibt ein geordnetes Gedränge, in dem sich mehrere Spieler gleichzeitig über den Ball beugen und versuchen ihn zu ergreifen. In der Entwicklung dient Scrum dazu, Prozesse zu beschleunigen. Viele Start-ups aus der Technologiebranche arbeiten ebenfalls nach diesem Prinzip, um schnell auf Kundenwünsche und Marktveränderungen zu reagieren.

Für die Entwickler des DB Navigators bedeutet die Umstellung mehr Eigenverantwortung und Mitspracherecht. „Eine andere Arbeitsweise ist für die Scrum-Teams heute nicht mehr vorstellbar“, sagt Böhmer.

Bei der DB bestehen die Scrum-Teams aus Entwicklern, Designern und Testern. Drei solcher Teams arbeiten an der Weiterentwicklung der App: jeweils eins für die Betriebssysteme Android und iOS und eins für die Buchung. Sie setzen Entwicklungen eigenverantwortlich um. Ein „Scrum Master“ leitet das Team an und soll  die hohe Eigenverantwortung der Teammitglieder fördern, Hindernisse und Konflikte beseitigen und auf die Einhaltung des Scrum-Prozesses achten.

Die Umsetzung erfolgt in Sprints

Sprint beim Scrum Team

Bevor die Scrum-Teams mit ihrer Arbeit loslegen, priorisiert Armin Böhmer die Liste der Anforderungen an die App – das sogenannte Product Backlog. Aus Kundenfeedback, Befragungen und Tests kennt er Wünsche der App-Nutzer an den DB Navigator und weiß, welche Funktionen und Änderungen auf der Liste ganz oben stehen müssen. „Das Mobilitätsverhalten von Menschen ändert sich schnell“, so Böhmer. „Wird eine Anforderung plötzlich sehr wichtig, rückt sie entsprechend in der Priorität nach oben“.

Zu Beginn der Umsetzungsphase, dem sogenannten Sprint, wählt das Scrum-Team die Anforderungen aus, die es in den nächsten zwei bis vier Wochen umsetzen kann. Die Teammitglieder legen Aufgaben für jede Anforderung fest, die sie bearbeiten. In täglichen Meetings stellen sie vor, was sie seit dem letzten Treffen erreicht haben, was sie bis zum nächsten Meeting machen und was sie behindert – alles in maximal 15 Minuten. „Wir arbeiten sehr flexibel“, sagt Böhmer. „Teammitglieder können täglich Verbesserungsvorschläge machen, Ideen einbringen und so die Lösung von Anfang an beeinflussen.“

Ein Sprint endet damit, dass das Umsetzungsteam dem Product Owner und weiteren Stakeholdern, zum Beispiel den Produktmanagern der App, die Arbeit vorstellt. Neue Funktionen oder Änderungen im DB Navigator können nun für Kunden sichtbar in die App eingefügt werden. Zu jedem Sprint gehört auch ein gemeinsames Auswerten der Arbeitsweise. Was nicht gut funktioniert hat, wird im nächsten Sprint verbessert.

Vom Wasserfall zum Kreislauf

Vor dem Umstellen auf Scrum waren alle Arbeitsschritte nach der Wasserfalllogik von der Planung bis zur Umsetzung festgelegt und wurden von oben nach unten schrittweise bearbeitet. Nichts lief parallel und es war kaum möglich, im laufenden Entwicklungsprozess etwas zu verbessern. Die Entwickler setzten um, was laut Plan vorgesehen war. „Planung und Entwicklung arbeiten heute viel enger zusammen“, sagt Böhmer. „Wir tauschen uns laufend aus.“ Soll eine entwickelte Lösung noch weiter verbessert werden, nimmt Armin Böhmer sie wieder in das Product Backlog auf. Sie wird dann im nächsten Sprint weiter bearbeitet. Endet ein Sprint, heißt das nur, dass bald ein neuer beginnt.

1.    Was ist die größte Herausforderung an der Aufgabe als „Product Owner“?

Armin Böhmer, Product Owner DB Navigator

Ich verstehe mich als Vermittler zwischen zwei Seiten. Auf der einen stehen die Stakeholder und ihre Vision für den DB Navigator, auf der anderen die Scrum-Teams, die die Funktionen der App weiterentwickeln und diese Vision Realität werden lassen. Ich muss immer ausloten, welche Ideen Priorität haben und was das Umsetzungsteam tatsächlich realisieren kann. Das ist eine ziemliche Herausforderung. Es hilft mir, die Anforderungen immer wieder aus Kundensicht zu betrachten und zu bewerten.

2.    Wie sieht ein typischer Arbeitstag aus?

Während eines Sprints habe ich feste Termine, zum Beispiel zur Sprint-Planung oder tägliche Scrum-Meetings. Ansonsten gleicht kein Tag dem anderem. Wir nähern uns einer neuen App-Funktion Schritt für Schritt und darum tauchen auch jeden Tag neue Fragen auf mit denen wir uns auseinandersetzen.

3.    Welcher Punkt während eines Sprints ist der schwierigste?

Wir machen keine langen Analysen der Ausgangssituation mehr und starten schneller mit der Umsetzung, deshalb kommt es manchmal zu Überraschungen. Zum Beispiel kann es vorkommen, dass wir im Sprint Zusammenhänge zwischen Systemkomponenten entdecken, die wir vorher nicht kannten. Wir müssen unsere Lösung dann so weiterentwickeln, dass sie mit allen Teilen des Systems in Einklang steht.

4.    Was ist der größte Vorteil an der Scrum-Arbeitsweise?

Mit der agilen Arbeitsweise brechen wir komplexe Vorhaben in kleine Schritte. So können wir immer prüfen, ob wir noch auf dem richtigen Weg sind und den Kundenwunsch erfüllen. Wenn das nicht der Fall ist, entscheiden wir neu wie es weitergeht. Das war vorher nicht möglich. In einem Sprint entsteht durch die Eigenverantwortung des Entwicklungs-Teams außerdem eine hohe Dynamik. Das agile Arbeiten macht dadurch einfach nur Spaß!