Customer-Centric Development mit Vodafone

Scrum, eine Methode, um Projekte agil zu entwickeln, ist noch immer ein Phänomen: Obwohl sie sich schon in vielen Projekten bewährt hat, wissen viele Unternehmen noch nicht, was sie davon halten sollen. Woran soll der Kunde seine Dienstleister messen, wenn er kein Pflichtenheft in der Hand hält? Wer garantiert ihm, dass seine Wünsche auch wirklich umsetzbar sind? Es sind diese und andere Fragen, die sie zögern lassen.

Die Anhänger von Scrum preisen das Konzept als modern, dynamisch und flexibel, die Skeptiker zweifeln an der Praxistauglichkeit.

Den Beweis, dass agile Vorgehensmodelle sinnvoller sein können als lineare oder iterative Modelle wie das Wasserfall- und das Spiralmodell, trat die msg systems AG mit der Entwicklung eines Business-Dashboards für Vodafone an. Dabei setzte msg auf einen auf Scrum basierenden Ansatz, der auch als Customer-Centric Development bezeichnet wird. Grund: So konnte msg den Wunsch seines Auftraggebers nach einem Höchstmaß an Flexibilität erfüllen.

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“).

Im Customer-Centric Development beschreibt der Auftraggeber seine Ideen und Vorstellungen vom Endprodukt und überlässt die Ausführung, die Auswahl der Maßnahmen und das detaillierte Vorgehen komplett dem Dienstleister.

Im konkreten Projekt wurden vier interagierende Rollentypen eingesetzt: der Customer (CU), der Enabler (EN), der Teamlead (TL) und mehrere Solution Developers (SD).

Die Rolle des Customers (CU) nimmt eine Vertrauensperson des Auftraggebers des Projekts ein. Er ist aus dessen Sicht für den Projekterfolg verantwortlich. Weil das beschriebene Projekt für Vodafone nur eines von vielen war, wurde die Rolle des Customers stark minimiert. Als seine Aufgaben wurden lediglich die Brainstormings während der Präsentations-Meetings und die Auswahl von Alternativen im Fall anstehender Entscheidungen festgelegt. Der Customer ist auch derjenige, der das Projektergebnis formal akzeptiert. Die Dokumentationspflicht, die im klassischen Scrum-Ansatz eher beim Product Owner verortet ist, wurde bewusst von der Rolle des Customers gelöst und von anderen Rollen über­nommen.

Im Customer-Centric Development fallen diese Aufgaben hauptsächlich dem Enabler (EN) zu: Er antizipiert, so weit möglich, Ideen und Entscheidungen des Customers und koordiniert das Projekt als Vermittler zwischen Auftraggeber und Dienstleister. Der Enabler ist formal Teil des Lieferantenteams, zu dem auch die anderen beiden Rollen, Teamlead und Solution Developers, gehören.

Hauptfunktion des Enablers ist die Übersetzung der fachlichen Anforderungen und Interessen, die durch den CU verbal geäußert werden, in die Welt der IT. Diese Form des Business-/IT-Alignments erfordert eine Kenntnis beider Welten – sowohl der fachlichen des CU als auch der technischen
der IT.

Der Enabler ist der zentrale Dreh- und Angelpunkt der Kommunikation. Er dokumentiert die Wünsche und Anregungen des CU als möglichen Input für zukünftige Sprints. Zusätzlich nimmt er Bedenken und Anregungen des Teamleads und der Solution Developers auf. Er initiiert Lösungsansätze und organisiert die Kommunikation zwischen Business und IT. Eine rauschfreie Verständigung ist dabei immens wichtig für den Projekterfolg. Im vorliegenden Fall war der Enabler nicht nur mit der fachlichen Thematik, sondern auch mit dem Auftraggeber bereits aus vorangegangen Projekten vertraut – ein enormer Vorteil, der die Kommunikation zwischen ihnen wesentlich effizienter machte.

Der Teamlead (TL) stellt in jeder Beziehung den Spiegel des Kunden dar. Er ist das Sprachrohr der Solution Developers und agiert in deren Sinn und als Vertreter des Dienstleisters. Er ist hauptverantwortlich für das Controlling der entstehenden Aufwände und sichert den Projekterfolg durch eine zielorientierte Steuerung der Solution Developers. Der TL bestimmt die finale Zuordnung der Wünsche des Customers zu den entsprechenden Sprints, präsentiert den aktuellen Status während der Meetings und vertritt gegenüber dem CU argumentativ die Aufwände. Aus den Anforderungen des Enablers definiert er die Arbeitspakete für die Solution Developers und koordiniert neben der korrekten Zuordnung von Arbeitspaketen auch die Priorisierung der Abarbeitung im Team.

Zur Gruppe der Solution Developers (SD) zählen alle Projektbeteiligten auf der Seite des IT-Dienstleisters, die direkt an der Konzeption und Realisierung sowie sämtlichen anderen relevanten Prozessen beteiligt sind. Jeder SD ist für die ihm zugeordneten Arbeitspakete und deren saubere Abarbeitung in Abstimmung mit dem TL verantwortlich. Der Informationsfluss ist aus Sicht des SD eine Holschuld – jeder SD ist für die Vollständigkeit der Informationen, die er für die Erstellung seines Arbeitspakets benötigt, zuständig. Sein Ansprechpartner ist in erster Linie der Teamlead in Abstimmung mit anderen SD, in Einzelfällen auch der Enabler und in Sonderfällen der CU selbst.

Die vier Rollentypen agieren innerhalb von fünf Prozess-Schritten miteinander. Die Prozess-Schritte des Customer- Centric Developments bauen fachlich aufeinander auf, können sich zeitlich aber durchaus überlappen. Sie lassen sich in zwei Typen klassifizieren: einerseits die Prozess-Schritte, bei denen der Fokus auf der Kundenkommunikation und der Abstimmung mit dem Kunden liegt, die sogenannten FIELD-Prozesse, und andererseits die Prozess-Schritte, die dienstleisterintern vollzogen werden und in geschütztem Rahmen stattfinden, die sogenannten HOOD-Prozesse.

Wie die Zuordnung schon vermuten lässt, gehören die Prozess-Schritte mit Beteiligung des CU zu den FIELD-Prozessen. Hierbei handelt es sich um diejenigen Prozess-Schritte, bei denen Abgrenzungen zwischen Kunde und Dienstleister vorgenommen werden, der Grad der Zielerreichung des vorherigen Sprints  beschlossen sowie die Zielinhalte für zukünftige Sprints definiert werden und die unterschiedlichen Interessen zwischen Dienstleister und Kunde offen zutage treten.

Alle zwei Wochen fand ein Treffen mit Vodafone statt, um den aktuellen Ausbaustand der Anwendung und die Umsetzung der Ideen vorzuführen. Anregungen und Änderungswünsche, die Vodafone bei diesen Präsentationen vortrug, wurden durch den Enabler aufgenommen und am Ende der Sitzung zwischen den Beteiligten noch einmal abgestimmt. In dieser Runde wurde auch bereits die Priorisierung und Zuordnung zu konkreten Sprints in groben Zügen vorgenommen. Aufgrund der Erfahrung des Teamleads gelang das sowie die Ad-hoc-Abschätzung der Aufwände schnell und effektiv.

All dies trug dazu bei, die Wünsche des Kunden flexibel umzusetzen. Sogar die Datenbasis konnte mitten im Projekt ausgetauscht werden. Dies ermöglichte die Integration weiterer Key Performance Indicators (KPIs), die für die Darstellung und die interne Vermarktung des Geschäftsbereichs durch Vodafone als höchst relevant eingestuft wurden. Um die veränderten Anforderungen zu realisieren, wurden die Inhalte des nächsten Sprints neu definiert und die Anzahl der Sprints erhöht. Die ursprünglich geplanten Inhalte überführte man in die zusätzlichen Sprints.

Diese außerordentliche Flexibilität während des Projekts war nur möglich, weil zwischen msg als Dienstleister und Vodafone als Kunde ein partnerschaftliches Verhältnis herrschte. Ebenso wichtig war das hohe Maß an Vertrauen, das Vodafone in die Expertise des msg-Teams setzte – insbesondere, was Details der technischen Realisierung anging.

Es sollte deutlich geworden sein: Der größte Vorteil der Scrum-Methode ist ihre Flexibilität. Die breit angelegten Anforderungen sowie die große Aufmerksamkeit, die auf dem Projekt lag, erforderten ein geschmeidiges Vorgehen, um auf Anforderungen schnell und auftraggeberorientiert reagieren zu können.

Die größte Herausforderung war von Anfang an die begrenzte Verfügbarkeit des Auftraggebers in der Rolle des Customers, da dieser für den Erfolg vieler Projekte zugleich verantwortlich und deshalb ausgelastet war.

Dank Customer-Centric Development entstand eine Scrum-Struktur, die die Aufgaben des CU auf ein Minimum begrenzte und anderen Rollen, wie dem Enabler als Schnittstelle zum Kunden und dem Teamlead, mehr Gewicht verlieh beziehungsweise diese sogar neu kreierte.

Customer-Centric Development setzt zweierlei voraus: Erstens muss der Auftraggeber dem Dienstleister viel Vertrauen entgegenbringen – sowohl auf personeller Ebene wie aufseiten der technischen Expertise. Zweitens muss der Enabler in allen Business-Bereichen, die von dem Projekt berührt werden, über eine ausgeprägte Fachkenntnis verfügen.

Beides war im beschriebenen Fall gegeben – ebenso wie die nicht selbstverständliche Bereitschaft Vodafones, einen ergebnisoffenen Scrum-Ansatz überhaupt zu wagen. Unter diesen Gegebenheiten stellte sich die Entscheidung für ein Customer-Centric Development als die optimale Wahl heraus.