Die Ausgangssituation im Network Deployment

Der Bereich Network Deployment der Vodafone GmbH verantwortet den deutschlandweiten Ausbau des Mobilfunknetzes. Dafür wünschte sich Vodafone ein Management-Dashboard, mit dem es Fortschritte kontrollieren und deutschlandweit Forecast-Analysen für alle Vodafone-Regionen durchführen kann. Die zu entwickelnde Anwendung sollte dabei für die Mitarbeiter möglichst flexibel nutzbar und konfigurierbar sein.

Die Aufgabenstellung war sehr allgemein gehalten, da Vodafone eine erste Version kurzfristig in Betrieb nehmen und während der Entwicklung die Anforderungen dynamisch detaillieren und repriorisieren wollte. In zweiwöchentlichen Review-Meetings sollte der aktuelle Produktstatus präsentiert werden und der Vertreter von Vodafone neue Eingaben und Vorschläge zu Features und Layout machen können.

Klassische lineare Vorgehensmodelle schieden damit aus. Zusätzlich war bei den anzubindenden Schnittstellen und Partnersystemen – von denen noch nicht alle im Detail identifiziert waren – einiges an Kommunikations- und Abstimmungsaufwand zu erwarten, weshalb eine agile Vorgehensweise als beste Option erachtet wurde. Außerdem sollte Vodafone so wenig wie möglich mit dem Projekt belastet werden.

Zunächst wurden insgesamt sechs Reviews und somit sechs Projektabschnitte, sogenannte Sprints, vereinbart. Die Sprint­inhalte wurden zwar zu Beginn grob festgelegt, im Lauf des Projekts ergaben sich jedoch spürbare Änderungen dieser Vorfestlegungen. Hier spielte das agile Vorgehensmodell seine Vorzüge aus. Es erlaubte ein flexibles Reagieren auf Sonderwünsche, die Forderung nach weiteren Features und sogar die Verlagerung eines Entwicklungsschwerpunkts. So änderte sich im Lauf des Projekts zum Beispiel die komplette Datenbasis und die dazugehörige Schnittstelle. Jedes lineare Projekt in der Development-Phase hätte hier neu aufgesetzt werden müssen. Das agile Team konnte jedoch ohne Probleme die Schnittstellenänderung annehmen und die Entwicklung der Schnittstelle in die folgenden Sprints integrieren.

Das gewählte Vorgehen bot die gewünschte Flexibilität nicht nur in Bezug auf die Inhalte, sondern auch auf die Anzahl der Sprints.

Aufgrund der hohen Bedeutung, die dem Produkt zugemessen wurde, hatte die Zufriedenheit der Nutzer oberste Priorität. So eine Variante agiler Entwicklung wird als Customer-Centric Development bezeichnet. Die folgenden Ausführungen konzentrieren sich auf die Besonderheiten des Customer-Centric-Development-Ansatzes im Unterschied zum klassischen Scrum (zu Scrum siehe auch den Artikel „Software agil entwickeln mit Scrum“).