Business Technology 10/10

Business Case für Agilität: Rechnet sich der Einsatz von agile Methoden?

Autoren: ,

Agile Methoden wie Scrum oder Kanban etablieren sich zunehmend als Alternative zu klassischen Vorgehensmodellen in der Softwareentwicklung. Ist das alles nur ein großer Hype oder steckt mehr dahinter? Gibt es vielleicht sogar einen echten Business Case? Anhand einer idealisierten Geschichte soll verdeutlicht werden, welche Chancen die Agilität bietet und warum sich ein Umstieg rechnet.

Heute ist ein entscheidender Tag für Frau Schneider. In den letzten Wochen hat die Bereichsleiterin für Vertrieb bei einer großen deutschen Versicherungsgesellschaft viel Zeit investiert. Sie hat ihre Ideen von einer besseren Unterstützung der Agenturen und höheren Kundenbindung mit Vorstand und Kollegen diskutiert. Jetzt hat sie endlich das benötigte Budget bekommen. Die Zeit drängt. Entscheidend wird auch sein, mit dieser innovativen Idee als erster im Markt zu starten. Jeder Außendienstmitarbeiter soll mit einem iPad ausgestattet werden. Auf diesem soll eine Vertriebssoftware laufen, die neben dem normalen Angebots- und Antragsgeschäft vor allem multimediale Elemente zur Vertriebsunterstützung enthält. Gerade junge Vertriebsmitarbeiter sollen dadurch eine bessere Servicequalität und höhere Abschlussraten erzielen können. Zudem lässt sich über eine dynamisch veränderbare. Software auch besser steuern, was und wie verkauft wird. Entscheidende Vorteile in einem hart umkämpften Markt. Außerdem soll es eine direkte Verbindung zwischen Agentursoftware und den Kunden geben. iPhone und das Web 2.0 mit seinen sozialen Netzwerken sollen genutzt werden, um einen Dialog mit dem Kunden herzustellen und Mehrwertdienste anzubieten. So soll die Kundenbindung erhöht und die Cross-Selling-Rate optimiert werden.

„Live“ in sechs Monaten

Nur eine Hürde liegt noch vor Frau Schneider. Aber eine Hürde, über die sie in den letzten Jahren sehr häufig gestolpert ist. Gleich hat sie ein Gespräch mit Herrn Müller, dem Bereichsleiter der Anwendungsentwicklung. Sie muss mit ihm über den Einführungstermin und die Anforderungen der Software sprechen. In sechs Monaten möchte Frau Schneider dem Außendienst eine erste Version der Software inklusive iPad bereitstellen. Parallel dazu soll das neue Kundenportal im Internet und für mobile Plattformen präsentiert werden. Gerade für das Kfz-Versicherungsgeschäft ist es wichtig, pünktlich vor dem Jahresendgeschäft ab Oktober zu veröffentlichen, da ansonsten das Geschäft für ein Jahr gelaufen ist.

Das aktuelle Außendienstsystem ist erst vor einem Jahr produktiv gegangen. Aus den ursprünglich geplanten drei Jahren Projektlaufzeit sind mehr als sechs Jahre geworden. Gesetzliche Änderungen wie die EU-Vermittlerrichtlinie und marktbedingte Produktänderungen hatten zu hohem Änderungsaufwand geführt. Die Mitarbeiter von Frau Schneider hatten zu Beginn des Projekts alle Anforderungen im Detail spezifiziert. Dabei wusste man selbst noch gar nicht genau, wie die neue Anwendung aussehen und funktionieren sollte. Aber die Methodik wollte es so, und die IT garantierte dafür, Termin und Budget zu halten. Am Ende war man dann im Termin drei Jahre nach hinten gerutscht – trotzdem war der Projektstatus immer „grün“. Wie sollte man jetzt in sechs Monaten eine ganz neue Software bauen?

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 Pilotagenturen 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.

Window of Opportunity

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 derer man den nächsten autorisierten SmartRepair-Händler finden konnte. Im Gegenzug verzichtete man auf die Schadensmeldung im Internet für das erste Release. Durch die Umpriorisierung konnte im fünften 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 Releases 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. Und die Moral von der Geschichte? Die Anforderungen an die IT nehmen immer mehr zu. Marketing und Vertrieb treiben uns in immer kürzere Entwicklungszyklen. Immer häufiger hört man selbst von hartgesottenen Verfechtern schwergewichtiger Methoden, dass man in bestimmten Fällen auf agile Verfahren zurückgreift: Nämlich dann, wenn man nicht genug Zeit und Budget für die Anwendung der Methode hat. Der Business Case für Agilität lässt sich dabei anhand von vier Kernthesen aufzeigen:

1. Schneller geschäftlicher Nutzen und Time to Market
2. Weniger Fehl- und Blindleistungen
3. Risikomanagement von komplexen Situationen
4. Hohe und nachhaltige Qualität

Schneller geschäftlicher Nutzen und Time to Market

Agile Methoden arbeiten mit kurzen Iterationen und liefern in jeder Iteration ein lauffähiges Inkrement („Working software over comprehensive documentation“ [3]) aus. Die Iterationen dauern in der Regel zwei bis vier Wochen und beinhalten die geschäftlichen Funktionen mit der aktuell höchsten Priorität. Nach jeder Iteration kann der Funktionsumfang der nächsten Iteration neu festgelegt werden, d. h. es können Funktionen umpriorisiert oder auch völlig neue Funktionen hinzugefügt werden. Die Geschwindigkeit, mit der man heute am Markt agiert (Time to Market), kann entscheidend für den wirtschaftlichen Erfolg sein. Ein Produkt als Erster auf den Markt zu bringen (First Mover) bedeutet in der Regel, dass man höhere Preise erzielen kann, da es wenige oder keine Konkurrenten gibt.

Abbildung 1 zeigt, dass der iterative Ansatz von agilen Methoden es ermöglicht, schon früher mit einer minimal vermarktbaren Funktionalität zu starten, da prinzipiell jedes Inkrement lauffähig ist. Frau Schneider konnte beispielsweise schon nach sechs Monaten eine neue Vertriebssoftware ausliefern, obwohl der gesamte Funktionsumfang erst nach 18 Monaten fertiggestellt wurde. Entscheidend kann aber auch der Zeitpunkt der Markteinführung sein. Wenn Frau Schneider den neuen Kfz-Tarif nicht zum Oktober in das Vertriebssystem integriert hätte, wäre das Geschäft für ein Jahr ggf. stark eingeschränkt gewesen.

Ist die Konkurrenz besonders innovativ und bietet, wie in unserer Geschichte, den Kfz-Tarif mit Smart-Repair- Option ohne Selbstbehalt, ist es wichtig, schnell reagieren zu können und ggf. ein ähnliches Produkt anzubieten (Fast Follower). Als Second Mover hat man dann sogar die Chance, das Produkt der Konkurrenz zu übertreffen. Agilität unterstützt schnelle Entwicklungszyklen und akzeptiert Veränderungen durch einen empirischen Entwicklungsprozess basierend auf iterativ entwickelten Inkrementen.

Weniger Fehl- und Blindleistung

Studien gehen davon aus, dass fast zwei Drittel der Funktionen in einer Anwendung selten oder überhaupt nicht genutzt werden [4]. Im Umkehrschluss bedeutet das: Der Geschäftswert der Anwendung steckt hauptsächlich im verbleibenden Drittel. Die Problematik in Softwareprojekten ist, schon zu Beginn eines Projekts genau das Drittel zu identifizieren, das den größten Geschäftswert liefert. Frau Schneider und ihr Fachbereich hatten beispielsweise nur eine sehr vage Vorstellung davon, wie ihre Ideen in konkrete Funktionen umgesetzt werden sollen. Diese vage Vermutung über die benötigte Funktionalität konkretisiert sich aber, sobald man ein System benutzt hat [5]. In unserer fiktiven Geschichte war es wichtig, die Anwendung auf dem iPad schon sehr früh auszuprobieren, um ein Gefühl für die Bedienung zu bekommen.

Selbst unter der idealisierten Annahme, man kenne zu Projektbeginn schon alle Anforderungen im Detail und wisse um deren Geschäftswert, bleibt das Risiko, dass sich diese Anforderungen im Projektverlauf ändern, weil sich die Rahmenbedingungen geändert haben. Beispielsweise durch eine gesetzliche Änderung wie die Einführung der EU-Vermittlerrichtlinie. Bei agilen Methoden hat man nach jeder Iteration die Möglichkeit, den aktuellen Stand zu kontrollieren und ggf. nachzusteuern.

Durch das kontinuierliche Feedback der Kunden und Benutzer zu den bereits fertiggestellten Releases nähert man sich schrittweise dem wertschöpfenden Anforderungsdrittel im Projektverlauf. Zudem werden die tatsächlichen Anforderungen des Kunden durch die intensive Kommunikation besser verstanden, was in der Tendenz zu günstigeren Lösungen des eigentlichen Problems führt.

Risikomanagement von komplexen Situationen

Wie Friedrichsen in seinem Artikel in dieser Ausgabe [6] dargelegt hat, ist die Softwareentwicklung eine komplexe Aufgabenstellung, die sich durch die hohe Dynamik der Randbedingungen (Anforderungen, Technologien, Menschen) auszeichnet. Um einen komplexen Prozess steuern zu können, bedarf es eines empirischen Vorgehens. Eine Analogie zur Verdeutlichung: Auch Klimaanlage und Heizung können nicht für Stunden oder Tage im Voraus programmiert werden, um eine konstante Raumtemperatur zu erreichen. Die aktuelle Temperatur muss ständig gemessen werden, um dann die Regler nachsteuern zu können. Erst dadurch können Änderungen der Randbedingung wie Sonneneinstrahlung, Anzahl und Aktivität der im Raum befindlichen Personen ausgeglichen werden. Analog verhält es sich mit der Softwareentwicklung: Erst mit einem Prozess, der viele Messpunkte und Möglichkeiten zur Nachsteuerung bietet, kann man in komplexen Situationen das Risiko in den Griff bekommen. Gemessen wird z. B. in Scrum auf vielen Ebenen: Täglich beim Daily Scrum, um zu prüfen, ob das Sprint Commitment noch gehalten werden kann. Bei dem Sprint Review, um zu prüfen, wie viel Fortschritt innerhalb des Sprints gemacht wurde und welche Auswirkungen das auf das Release hat.

Das größte Risiko, das man dann eingeht, ist eine Iteration, die komplett am Geschäftsnutzen vorbeigeht: Man hat also keinerlei Kundennutzen aus der Arbeit der Iteration generieren können. Der iterative Ansatz deckelt das Risiko aber auch auf eine Iterationslänge. Im Gegensatz zu schwergewichtigen Prozessen, bei denen man sehr häufig erst gegen Projektende merkt, ob der „grüne“ Status eher auf Hoffnung oder lauffähiger Software basiert, die den Kundenanforderungen entspricht. Der Business Case von Agilität kann im Extremfall sogar darin liegen, das Projekt zu beenden – der finanzielle Schaden kann durch die frühzeitige Validierung von Risiken reduziert werden.

Hohe und nachhaltige Qualität

Spaghetticode ist einfacher und schneller zu schreiben als eine gut strukturierte Komponente. Das jedenfalls behauptet Josuttis, der sogar so weit geht zu behaupten, die Zukunft läge im „Crappy Code“. Man solle sich einfach damit abfinden, dass schlechter Code normal ist [7]. Marketing und Vertrieb würden einen solchen Kostendruck aufbauen, dass man einfach zu der billigsten Art der Programmierung greifen müsse, und das sei eben, einfach etwas zusammenzuhacken, was funktioniert. Der Denkfehler aus Sicht der Autoren: Schlechter Code ist nicht billiger, ganz im Gegenteil. Josuttis Ansatz greift zu kurz, weil er sich nur auf die einmaligen Erstellungskosten des Codes bezieht. Die wahren Kosten verstecken sich aber ganz woanders. 85 % der Kosten, Tendenz steigend, stecken in der Wartung [8]. Ja, Spaghetticode zu schreiben ist günstiger, aber eben auch nur das Schreiben. Dazu kommt, dass man sich bei einer agilen Vorgehensweise quasi in der zweiten Iteration schon in der Wartungsphase befindet. Nun, das könnte jetzt ein Argument sein, eben nicht iterativ zu entwickeln, um die Wartungsphase möglichst weit herauszuschieben, aber auch die Betrachtungsweise ist verkürzt. Denn auch wenn die Wartungsphase „offiziell“ erst nach dem Release anfängt, Software zu warten heißt, zu bestehender Funktionalität neue hinzuzufügen, und das geschieht tagtäglich in der Softwareentwicklung.

Eine Untersuchung des amerikanischen Verteidigungsministeriums hat den Einfluss von der Struktur eines Systems auf die Wartbarkeit gemessen. Danach wurden Kosten, Fehler und zeitlicher Aufwand einer Änderung an einem System gemessen, bevor und nachdem es von einem unstrukturierten in einen strukturierten Zustand überführt wurde. Die Unterschiede sind drastisch: Die Änderungen am strukturierten System dauerten nur halb so lange und verursachten die Hälfte der Kosten. Die Anzahl der Fehler ging noch drastischer auf fast ein Zehntel zurück [9]. All das sind Kostenvorteile, die man mitnimmt, wenn sich das System in einem qualitativ hochwertigen Zustand befindet.

Die Erfahrung zeigt, dass die Qualität des Codes häufig Zeit und Budget zum Opfer fällt. Martin Fowler nennt diese Qualitätsschulden, die ein Projekt über die Laufzeit aufbaut, auch Technical Debt [10]. Agile Methoden wie Scrum führen deshalb eine „Definition of Done“ ein, die die Qualitätskriterien für eine Anforderung festlegt. Nur wenn diese komplett erfüllt sind, wird eine Anforderung in einer Iteration ausgeliefert. Zudem schreiben agile Softwareentwicklungsmethodiken wie eXtreme Programming [11] Praktiken wie Test-driven Development, Continuous Integration und Pair Programming vor, um die Codequalität der Anwendung hochzuhalten.

Zusammenfassung

Natürlich kann kein allgemeingültiger Business Case aufgestellt werden, ohne die konkrete Situation mit einzubeziehen. Trotzdem rechnen sich agile Methoden in vieler Hinsicht und sind definierten („Wasserfall“-)Prozessen vorzuziehen. Regelmäßige iterative Fertigstellung kleiner Inkremente kann die Time to Market von Produkten deutlich verkürzen. Dadurch können früher Umsätze erzielt und Gelegenheiten wahrgenommen werden, die man sonst als zu kurzfristig hätte verstreichen lassen müssen. Änderungen können nach jeder Iteration erfolgen und unterliegen keinem teuren Change Management, das versucht, dem Kunden die Änderungen auszureden. So kann schnell auf neue Rahmenbedingungen und die Konkurrenz reagiert werden. Die enge Kommunikation mit Kunden und Benutzern führt dazu, dass nur das entwickelt wird, was tatsächlich benötigt wird. Dadurch werden Fehl- und Blindleistung vermieden, was eine Kostenersparnis von rund zwei Dritteln der Entwicklungskosten ausmachen kann. Durch das Risikomanagement komplexer Problemstellungen in der Softwareentwicklung auf Basis empirischer Prozesse können Projektrisiken schon früh erkannt und gehandhabt werden. Der Nutzen des Systems steigt quasi durch die Vermeidung negativen Geschäftswerts. Die Forcierung hoher und nachhaltiger Qualität senkt die Kosten in der Wartung des Systems nachweislich bis auf die Hälfte der Kosten bei einem üblichen Vorgehen.

In Addition kann man durch den Einsatz von Agilität also Kosten sparen, Risiken minimieren und den Nutzen einer Anwendung steigern – auch wenn sicherlich gewisse Rahmenbedingungen erfüllt sein müssen.

Links & Literatur

[1] Scrum Guide: http://www.scrum.org/scrumguides/
[2] Software Kanban: http://agilemanagement.net/
[3] Agiles Manifest: http://agilemanifesto.org/
[4] Schwaber, Ken: „The Enterprise and Scrum“, Microsoft Press,
ISBN-13: 978-0735623378, 2007
[5] Watts S. Humphrey: „A Discipline for Software Engineering“,
SEI Series in Software Engineering. Addison-Wesley 1995
[6] Friedrichsen, Uwe: „Agil oder doch lieber ingenieursmäßig?“
Gleiche Ausgabe
[7] Josuttis, Nicolai M.: „Welcome Crappy Code“:
http://www.josuttis.com/WelcomeCrappyCode.html
[8] Koskinen, J.: „Software Maintenance Cost“, 2003:
http://www.cs.jyu.fi/~koskinen/smcosts.htm
[9] Department of Defense: Guidelines for Successful Acquisition
and Management of Software Intensive Systems, Anhang F:
http://www.stsc.hill.af.mil/resources/tech_docs/gsam3.html
[10] Technical Debt: http://martinfowler.com/bliki/TechnicalDebt.html
[11] eXtreme Programming: http://www.extremeprogramming.org

Vollständiger Artikel