Scrum: Rugby für Softwareprojekte

Zu spät, zu teuer, falsche Features, mangelhaftes Produkt: Softwareprojekte liefern aus Anwendersicht oft nicht die gewünschten Ergebnisse. Eine erfolgreiche Methode, um typische Fehler zu vermeiden ist "Scrum". Dr. Erik Lenhard erklärt, was genau sich hinter diesem Vorgehensmodell verbirgt und unter welchen Voraussetzungen es tatsächlich zum Erfolg führt.

Mehr als zwei Drittel aller Softwareprojekte scheitern oder geraten in Schwierigkeiten. Sie werden, wenn überhaupt, zu spät oder zu teuer fertig und liefern aus Anwendersicht nicht die gewünschten Ergebnisse. Eine Lösung für viele dieser Probleme können agile Softwarentwicklungsmethoden sein. Sie versuchen den typischen Fehlern in einem solchen Projekt entgegenzuwirken indem sie den klassischen Ansatz der Softwareentwicklung ("Wasserfall-Methode") verlassen. Diesen Methoden liegen die Prinzipien einer agilen Entwicklung zugrunde:

Dr. Erik Lenhard ist leiter Management Information bei Kabel Deutschland. Er verantwortet organisatorisch, fachlich und technisch das zentrale Reporting der Kundenkennzahlen. Neben seinem Schwerpunkt im Bereich Business Intelligence / Data Warehouse hat er umfangreiche Expertise in agiler Softwareentwicklung und ist zertifizierter Scrum-Master.

• Frühe Realisierung von Geschäftsnutzen
• Enge Abstimmung Kunde / Auftragnehmer und Priorisierung
• Unterstützen der Kreativität der Projektmitglieder
• Situations- / projektbezogene Anpassung des Vorgehens
• Beseitigen von Kommunikationsbarrieren
• Bevorzugen einfacher Lösungen
• Fördern der Selbstorganisation der Teams
• Kontinuierliche Verbesserung durch Beobachtung und Feedback
• Dokumentation: soviel wie nötig, so wenig wie möglich
• Unsicherheiten und Anforderungsänderungen werden erwartet
  (Quelle u.a. Tigges (Opitz))

Als eine der elaboriertesten Methoden der agilen Softwareentwicklung gilt "Scrum". Der Name kommt aus dem Rugby und beschreibt das Gedränge das um den Ball entsteht. Auch bei Scrum stehen alle Beteiligten eng beieinander. Durch klare Rollenaufteilung (Scrum Master, Product Owner, Team), eine engmaschige Meetingstruktur (Sprint Planing 1 und 2, Daily Scrum, Sprint Retrospektive, Sprint Review) und fest definierte Artefakte (Taskboard, Burndown Chart, Product Backlog) wird ein methodischer Rahmen gegeben.

Dieses Vorgehen ändert Rollen und Beziehungen aller an der Softwareentwicklung beteiligter Personen: Entwickler und Kunden interagieren direkt miteinander. Fehler und Probleme werden frühzeitig erkannt und beseitigt. Während beispielsweise bei der Wasserfallmethode ein - mehr oder weniger starres - Lasten- und Pflichtenheft angelegt und dann abgearbeitet wird, wird bei Scrum in Intervallen gearbeitet, die eine ständige Prüfung und Anpassung zulassen und fördern. Besonders erfolgreich ist dieser Ansatz in Fällen, in denen am Anfang keine präzise Vorstellung, sondern nur eine Vision steht. Agile Projekte geben die vermeintliche Sicherheit von dicken Fach- und Feinkonzepten, engen und meist unrealistischen Projektplänen und rigiden Vorgehensweisen auf. Der Kunde muss seine Vorstellungen direkt äußern und die Entwickler gehen feste commitments ein.

In schnellen Entwicklungszyklen von einer bis drei Wochen entsteht dann ein auslieferungsfähiges "workable piece of software". Dieses wird dem Kunden präsentiert, dessen Feedback die Rückkopplungsschleife schließt. Gemeinsam werden anschließend die Features für den nächsten Entwicklungszyklus festgelegt. Fortschritte und Probleme werden laufend festgehalten und für alle Beteiligten sichtbar gemacht.

Wer aber nun glaubt der heilige Gral der Softwareentwicklung sei gefunden täuscht sich. Agile Softwareprojekte haben keine eingebaute Erfolgsgarantie. Häufig scheitern aber nicht Scrum-Projekte per se sondern die Einführung von Scrum misslingt. Denn Scrum ist nicht nur ein neues Tool, sondern ein eigenständiges Vorgehensmodell, dem eine eigene Philosophie zu Grunde liegt. Zum Erfolg führt Scrum nur, wenn alle Beteiligten bereits sind, sich voll darauf einzulassen.

Es sind außerdem zahlreiche organisatorische, prozessuale und technische Erfolgsfaktoren notwendig damit ein agiles Vorgehen auch erfolgreich Fuß fassen kann. Vor der Einführung von Scrum müssen sich die Verantwortlichen daher zahlreiche Fragen stellen und diese ehrlich beantworten:

• Wie agil ist die Systemlandschaft?
• Können die Deployment- sowie andere IT-Prozesse mit der Scrum-Geschwindigkeit mithalten?
• Teilt das Personal die veränderten Anforderungen, das neue Rollenverständnis und die agilen Werte, insbesondere die veränderte Fehlerkultur?
• Wird der Fachbereich bzw. werden die Kunden mitziehen?
• Haben wir einen erfahrenen Scrum-Master der als Change-Agent agieren kann?

Die Einführung von Scrum ist ein Change Prozess für zentrale IT-Abläufe und kann die gesamte Organisation verändern. Die Entwicklung in einer abgeschlossenen IT-Infrastruktur mit mehr Freiheitsgraden als in den produktiven Systemen, einer so genannten "Sandbox", ist dabei ein sinnvoller Zwischenschritt zur vollständigen Umstellung. Auch eine iterative, schrittweise Einführung von Scrum ist sinnvoll um Erfahrungen zu machen und Ängste abzubauen. Ein erfolgreiches Pilotprojekt ist daher enorm wichtig. Wie auch beim Rugby gilt: Man will sich nicht im ersten Gedränge ein blaues Auge holen sondern das Match gewinnen. (gs)