Rollenverteilung im Customer-Centric Development

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.