Die Scrum-Erfahrungen bei Payback

Es ist kein Geheimnis, dass komplexe Softwareprojekte mit langen Laufzeiten selten in Time & Budget bleiben. Das Problem verschärft sich noch, wenn Off-shore-Dienstleister ins Spiel kommen. "Nach der klassischen Methode entstehen bei solchen Projekten Lasten- und Pflichtenhefte mit mehreren tausend Seiten Dokumentation, die dann ohne etablierte Eingriffsmöglichkeiten abgearbeitet werden", sagt Anton Dechko, Director of Business Development beim Münchner Outsourcing-Dienstleister SAM-Solutions.

Gehen zwischen Analyse und Implementierung Jahre ins Land, haben sich unterdessen nicht nur die Anforderungen an die Software geändert; auch lassen sich viele Fragen, Probleme und Abhängigkeiten vor Projektbeginn oft noch gar nicht absehen. "Je genauer man einen Plan austüfftelt und danach arbeitet, umso eher bekommt man, was man geplant hat – aber nicht, was man eigentlich haben will", sagt IT-Manager Ralf Ehrhardt. Er bezeichnet es das "Bekommen-was-man-nicht-braucht-Dilemma".

Ehrhardt ist als Vendor Manager bei Loyalty Partner Solutions (LPS) in München für die Auswahl und Steuerung externer Dienstleister verantwortlich. Die LPS wurde im August 2008 als Tochter eines ehemaligen Geschäftsbereichs von Payback gegründet und entwickelt die gesamte Software des Bonusprogramms. Zu den Kunden von LPS, das auf IT-Lösungen für Kundenbindungsprogramme spezialisiert ist, zählen neben Payback auch die Deutsche Bahn AG mit ihrem BahnCard-Programm sowie weitere Unternehmen unterschiedlicher Branchen.

Wegen des "Bekommen-was-man-nicht-braucht-Dilemmas" ist Ehrhardt von der klassischen "Wasserfallmethode" abgerückt und hat die Projekte seiner Entwicklungsteams auf Scrum, eines unter mehreren Vorgehensmodellen der sogenannten "agilen Softwareentwicklung", umgestellt.

Die "Wasserfallmethode"

Scrum basiert, ebenso wie Crystal, Extreme Programming, Feature Driven Development (FDD) oder Adaptive Software Development (ASD), um nur einige Beispiele zu nennen, auf den Prinzipien der sogenannten "agilen Softwareentwicklung." Erste Ansätze der "agilen" Methoden gibt es seit Beginn der neunziger Jahre, aber erst in den vergangenen Jahren erfreuen sie sich – allen voran Scrum – auch in Deutschland zunehmender Beliebtheit. Sie unterscheiden sich erheblich von dem klassischen Vorgehensmodell, der sogenannten "Wasserfallmethode".

Während das Wasserfallmodell schon vor Beginn des Projektes eine Detailplanung für jede der linear ablaufenden Phasen verlangt (Analyse, Entwurf, Realisierung, Test, Implementierung, Nutzung), bringen die agilen Vorgehensmodelle deutlich mehr Flexibilität in die Programmierung. Mit ihnen wird es möglich, veränderte beziehungsweise neue Anforderungen gleichsam "on the fly" in den laufenden Entwicklungsprozess einzubeziehen.

Scrum setzt die wichtigsten Prinzipien der agilen Softwareentwicklung um:

• Funktionierende Programme sind wichtiger als ausführliche Dokumentationen. Zwar gilt Dokumentation als hilfreich, das eigentliche Ziel jeder Entwicklung ist jedoch die lauffähige Software. Nichtsdestotrotz liefert auch Scrum eine Dokumentation, allein ihre Entstehung erfolgt auf einem anderen Weg.

• Die konsequente Abstimmung mit dem Kunden ist wesentlicher als ursprünglich formulierte Ziele und Vertragsinhalte.

• Die Offenheit für Änderungen gilt mehr als das Befolgen eines festgelegten Plans.

"Das Regelwerk ist so unkompliziert und die Methode so einfach zu erlernen, dass man annimmt, man hat sofort alles verstanden", sagt IT-Manager Ehrhardt. Die Erkenntnis, welche Auswirkungen Scrum auf die tägliche Arbeit hat, sei dann umso überraschender: "Erst wenn man Scrum tatsächlich einsetzt, merkt man, dass es sich um einen wirklichen Paradigmenwechsel handelt, der von allen Beteiligten ein radikales Umdenken verlangt."

Vor allem bei den Software-Entwicklern sei Scrum auf große Begeisterung gestoßen. Viele machten erstmals die Erfahrung, dass ihre Meinung gefragt und geschätzt sei. "Früher fand die Entwicklung ja oft so statt, dass veränderte oder neue Anforderungen dem Entwicklungsteam per Zettel rübergereicht wurden, ohne nach deren – ohne Zweifel kompetente – Meinung zu fragen", blickt Ehrhardt zurück. Das habe oft zu Frust geführt, im schlimmsten Fall, weil schon geleistete Arbeit sich plötzlich als nutzlos herausstellte. Jetzt führe die neue Freiheit – die Teammitglieder schätzen jeweils selbst ein, welche Aufgaben sie innerhalb eines Sprints erledigen können, und arbeiten dabei ohne externe Kontrolle – zu einer spürbar besseren Motivation und einer messbar gestiegenen Produktivität.

Nerds tun sich schwer

Andererseits fordert Scrum die Entwickler auch: Der Programmiertyp des Nerds, der am liebsten im stillen Kämmerlein ohne Kontakt zur Außenwelt vor sich hin programmiert, tut sich schwer in der neuen Umgebung. "Viele Entwickler machen das erste Mal die Erfahrung des direkten Kundenkontakts. Das stellt natürlich andere Anforderungen an die Kommunikationsfähigkeit und soziale Kompetenz", sagt Ehrhardt. Dabei sorge aber das Scrum-Regelwerk für einen Rahmen, der für beide Seiten – Auftraggeber wie Entwickler – die Rollen und Kommunikationsanforderungen adäquat festlegt. Denn nicht nur das Entwicklerteam muss bei Scrum umdenken. Auch für den Auftraggeber brechen mit Scrum neue Zeiten an. "Bei Scrum gibt es nur sehr wenige Rollen und Prinzipien – wenn diese aber nicht exakt eingehalten werden, entsteht Chaos. Und das gilt selbstverständlich auch für den Kunden in seiner Rolle als Product Owner", sagt Dechko von SAM-Solutions.

Als Nearshore-Dienstleister unterhält er mehrere Projektteams in Weißrussland und der Ukraine, die zusammen mit den LPS-Entwicklern in München die Payback-Software weiterentwickeln – auf Grundlage der Scrum-Prinzipien. "Bei der Auswahl des Outsourcing-Dienstleisters war es für uns Bedingung, dass er Scrum beherrscht und die Zusammenarbeit auf dieser Basis stattfindet", blickt Auftraggeber Ehrhardt zurück. Nach einer viermonatigen Probephase arbeiten jetzt Scrum-Teams auf beiden Seiten mit jeweils synchronen zweiwöchigen Sprints. Die Koordination der Teams, das "Scrum of Scrums", findet mit Videokonferenzen und täglichen Telefongesprächen statt. "Ohne regelmäßige und intensive Kommunikation aller Projektbeteiligten klappt Scrum nicht", sagt Dechko.

Um Sicherheit mit der Methode zu gewinnen, haben sowohl LPS als auch SAM schon mehrere Mitarbeiter zur Schulung geschickt. Die Rollen des Scrum-Masters oder Product-Owners etwa lassen sich in zwei- bis dreitägigen Kursen bei der Scrum-Alliance erlernen. Bisher ziehen alle Beteiligten ein durchweg positives Resümee: Sie verzeichnen eine gesteigerte Produktivität, verbesserte Transparenz in der Softwareentwicklung, eine höhere Zufriedenheit aller Projektbeteiligten und eine größere Akzeptanz der IT beim Kunden.

Verträge anders gestalten

Den wesentlichen Hemmschuh für eine weitere Verbreitung von Scrum sieht IT-Manager Ehrhardt in der gängigen Vertragsgestaltung: "Im Zuge der Wasserfallmethode sind Festpreise üblich, wobei schon zu Projektbeginn der Leistungs- und Funktionsumfang möglichst exakt festgeschrieben wird." Das mache mit Scrum natürlich keinen Sinn, weil es ja gerade zum Prinzip vom Scrum gehört, dass sich der Leistungsumfang während der Laufzeit ändert und an die tatsächlichen Anforderungen angepasst wird.

Als Vertragsgrundlage empfehlen sich – nach einer Pilotphase – projektbezogene Open-Scope-Verträge auf Basis von Monatspauschalen mit definierten Ausstiegskriterien. Damit habe der Kunde allemal eine bessere Kalkulations- und Steuerungsgrundlage als mit den bisher üblichen Verträgen.

Ehrhardt kann sich an kein langjähriges Projekt erinnern, das nach klassischer Methode geplant, vertraglich vereinbart und abgewickelt wurde und tatsächlich in Time & Budget geblieben wäre. "Die Wahrscheinlichkeit, dass Sie ein großes Projekt planen, Dokumentation und Pflichtenheft an einen Outsourcing-Dienstleister geben und nach einem Jahr eine Software erhalten, die ohne Nachbesserungen einsetzbar ist, ist gleich null", sagt Ehrhardt. Vertrag hin oder her.

Agile Software-Entwicklung - Sprechen Sie "Scrum"?