Rechnet sich der Einsatz von agilen Methoden?

Herr Müller hatte bereits vorab die Informationen von Frau Schneider bekommen und im ersten Moment gedacht, sie hätte sich bei der Projektlaufzeit in der Zeiteinheit vertan. sechs Monate? Doch der Vorstand unterstützte Frau Schneiders Idee und der Druck auf Herrn Müller war groß. Er wusste, dass man es mit der etablierten Entwicklungsmethodik nicht schaffen konnte. Er dachte an andere Projekte unter ähnlichem Zeitdruck zurück. Beispielsweise die „Jahr 2000 Umstellung“ oder die Einführung der „Riester Rente“. Damals hatte man auf die formalen Methoden verzichtet, die besten Leute zusammengezogen und Sie einfach machen lassen. „Feuerwehr“ oder „Schnelle Eingreiftruppe“ wurden diese Teams genannt. Funktioniert hatte es dann immer – Zeit und Budget wurden dabei auch gehalten. Warum also nicht das Vorgehen auch bei der normalen Entwicklung einsetzen? Herr Merten, ein junger Abteilungsleiter von Herrn Müller hatte zudem bei sich eines dieser neuen „agilen“ Vorgehensmodelle ausprobiert: Scrum und XP. Im Prinzip ein ähnlicher Ansatz wie bei den „Feuerwehr“-Teams – nur strukturierter und mit erprobten Praktiken. Funktioniert hatte das sehr gut. Sein Projekt hatte sehr schnell lauffähige Anwendungen ausgeliefert und gerade die Fachbereiche waren begeistert von Flexibilität und Produktivität dieser „agilen Teams“.

Herr Müller hatte sich mit Herrn Merten über das Projekt von Frau Schneider unterhalten und er war sich sicher, dass er mit dem richtigen Team die Anwendung in sechs Monaten „live“ bringen könnte. Viele Alternativen hatte Herr Müller nicht, sodass er Herrn Merten sein Vertrauen aussprach und es mit Scrum versuchen wollte.

Frau Schneider war überrascht, als Sie von Herrn Müller hörte, dass es möglich sei, ihre Idee in sechs Monaten umzusetzen. Die Bedingungen waren für sie akzeptabel. Herr Merten hatte ihr deutlich gemacht, dass sie einen „Product Owner“ stellen müsste, der einen Anforderungskatalog erstellen und priorisieren sollte. Zudem mussten Sie ein bis zwei Mitarbeiter abstellen, die mit der IT zusammen in einem Team arbeiten sollten, um direkt die Testfälle zu erstellen und bei den fachlichen Themenstellungen zu unterstützen. Man wollte mit den wichtigsten Funktionen für den Außendienst beginnen und dann alle vier Wochen eine lauffähige Anwendung zur Verfügung stellen, die dann auch schon von den Pilot-Agenturen getestet werden könnte. Für Frau Schneider war dies eine hervorragende Möglichkeit, schnell Feedback von den Anwendern zu bekommen, um so die erste Version so nah wie möglich an den Bedürfnissen der Vertriebsmitarbeiter ausrichten zu können. Zudem konnte man Unklarheiten bei den Anforderungen schrittweise mit Leben füllen und musste nicht alle Anforderungen im Voraus spezifizieren.

Nach einem Training für die Teammitglieder startete das Projekt zwei Wochen später mit der ersten Iteration: dem „1. Sprint“. Man wollte damit die prinzipiellen technischen Schnittstellen und den Anwendungsrahmen der iPad-Anwendung erstellen. So sollte zum einen das technische Risiko minimiert und zum anderen schon zu Beginn das Feedback der Anwender über die Bedienerfreundlichkeit eingeholt werden. Diese würde für die Vertriebsmitarbeiter eine der entscheidenden Erfolgsfaktoren für das Projekt sein, denn die bessere Unterstützung des Vertriebs war eines der zentralen Ziele der neuen Anwendung. Sollte die Anwendung nicht auf 100%-ige Akzeptanz stoßen, wäre das Projekt gescheitert. Unter den Piloten waren deshalb auch erfahrene und junge Agenturmitarbeiter, die durch die Mitarbeit und die Möglichkeit des frühen Feedbacks gewonnen werden sollten.

Der erste Sprint war ein voller Erfolg und man konnte bereits die Mainframe-Schnittstellen der Bestandssysteme anbinden sowie einen ersten funktionierenden Anwendungsrahmen mit einer Partnersuche anbieten. Bei der Vorführung der lauffähigen Anwendung vor allen Interessenten gab es viel konstruktives Feedback der Anwender, und auch der Fachbereich konnte besser einschätzen, wie sich eine iPad-Anwendung verhält und wie man die Funktionen an die neue Technologie anpassen musste.

In den nächsten Sprints wurden ständig Anforderungen neu priorisiert und neue Anforderungen hinzugefügt. Parallel startete ein zweite Scrum-Team mit der Umsetzung des Kundenportals. Nach vier Monaten wurde man durch einen Konkurrenten überrascht, der einen neuen Kfz-Tarif vorgestellt hatte. Dieses neue Produkt ermöglichte es den Kunden kleinere Lackschäden auf Basis von SmartRepair zu beheben. Der Vorteil für den Kunden ist dabei, dass der Selbstbehalt der Teilkasko nicht fällig wird. Der Fachbereich wollte zwei Monate vor Rollout noch nachziehen und zudem noch eine iPhone-Anwendung (App) zur Verfügung stellen, mithilfe der man den nächsten autorisierten SmartRepair-Händler finden konnte. Im Gegenzug verzichtete man auf die Schadenmeldung im Internet für das erste Release. Durch die Umpriorisierung konnte im fünfte Sprint direkt mit der Umsetzung des „SmartRepair“-Themas angefangen werden.

Nach sechs Monaten war ein Basissystem fertig, das genau auf die Bedürfnisse der Vertriebsmitarbeiter abgestimmt war. Die wichtigsten Elemente der Angebotserstellung inkl. neuer multimedialer Elemente waren vorhanden und auch das Portal konnte mit einer Vertragsauskunft und einer iPhone-App für die Lokalisierung von SmartRepair-Händlern ausgeliefert werden. Die Einführung war ein voller medialer und vertrieblicher Erfolg. Gerade junge Leute fühlten sich von der modernen Kommunikation im Vertrieb und den Mehrwerten über das Portal und die Apps angesprochen. Über eine offene Community in Facebook wurden zudem neue Anforderungen diskutiert und auch Kritik am System geäußert.

In den folgenden zwölf Monaten arbeiteten die Teams weiter an den Funktionen des Systems, erweiterten es schrittweise und nahmen das Feedback der Kunden und Vertriebsmitarbeiter auf, um es in monatlichen Release umzusetzen. Die alte Vertriebsanwendung war nach 1,5 Jahren vollständig abgelöst – zu 20 % der ursprünglichen Kosten und deutlich höherer Zufriedenheit der Anwender und Kunden.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.