Eine Gruppe von Investoren will ein neues Internet-Portal für die Stellenvermittlung im High Professional-Umfeld entwickeln. Die Investoren analysieren die existierenden Konkurrenzprodukte und erstellen ein Grobkonzept, das ihre Vision eines web-basierten Job-Portals beschreibt. Dieses Grobkonzept wird an ein Softwarehaus gegeben, das ein Angebot erstellt, bestehend aus Anforderungsanalyse, Spezifikation, Entwurf, Programmierung, Test und Integration. Diese sechs Phasen sollen sequentiell durchlaufen werden; der Plan sieht vor, das Portal in acht Monaten zu veröffentlichen.

Das Softwarehaus erhält den Zuschlag und die Arbeit beginnt. Besonderen Wert wird dabei auf die Ausarbeitung der schriftlichen Spezifikation gelegt, die von sämtlichen Stakeholdern in mehreren Durchläufen gegengelesen und überarbeitet wird. Man will in dieser Phase nichts falsch machen und möglichst jede potenzielle Anforderung von vornherein berücksichtigen. Jeder weiß, dass Änderungen teuer sind, so dass es besser ist, von Anfang an alles richtig zu machen. Die Investoren sind von dem Plan und der Erfahrung des beauftragten Softwarehauses überzeugt und gehen davon aus, dass das geplante Job-Portal in spätestens acht Monaten online sein wird.

Schwierige Planung

Kommt Ihnen das beschriebene Szenario bekannt vor? Wenn alles gut läuft, und die Software wie geplant entwickelt und geliefert werden kann, dann bekommen die Investoren im besten Fall das, was zu Beginn des Projekts schriftlich spezifiziert wurde. Aus Erfahrung ist jedoch bekannt, dass dies nur selten das ist, was sich der Kunde wirklich vorgestellt hat. Zum einen ist es nur schwer möglich, Software so genau zu spezifizieren, dass die Spezifikation genau das Bild der Software beim Programmierer erzeugt, das der Produktmanager vor Augen hat. Und zum anderen ändern sich die Rahmenbedingungen während der Laufzeit eines Softwareprojekts, was zwangsläufig zu Anpassungen und neuen Anforderungen führt.

Beispielsweise sind während der acht Monate Entwicklungszeit zwei weitere Konkurrenten in den Markt eingetreten. Einer der beiden besitzt ein "Killer-Feature", das die Investoren während ihrer Planungsphase noch nicht kannten, jetzt aber unbedingt auch für ihr eigenes Produkt wollen. Es ist bereits klar: Ohne dieses Feature kann man am Markt nicht bestehen. Änderungswünsche werden mit dem beauftragten Softwarehaus zäh verhandelt und resultieren in zusätzlichen Kosten und Terminverschiebungen.

Außerdem läuft die Test- und Integrationsphase längst nicht so glatt, wie geplant. Je näher das Projektende rückt, desto größer wird die Anzahl der Probleme. Projektleitung und Entwicklungsteam geraten unter Druck, Mehrarbeit wird zur Regel, Motivation und Qualität sinken. Irgendwie kriegen die Entwickler es mit einer zweimonatigen Verspätung aber doch noch hin. Allerdings entspricht das Ergebnis nicht wirklich dem, was sich die Investoren vorgestellt haben. Die entwickelten Features sind längst nicht mehr auf der Höhe der Zeit und teilweise schlechter umgesetzt, als in den Produkten der Konkurrenz. Zudem kommt das Portal zu spät auf den Markt, so dass ein Großteil der Zielnutzer bereits an eines der Konkurrenzportale gebunden ist.

Agile Softwareentwicklung als Gegenentwurf

Das beschriebene Szenario skizziert das klassische "Wasserfallvorgehen" bei der Durchführung von Softwareprojekten: Zu Beginn des Projekts wird ein genauer Plan erstellt, dessen Einhaltung höhere Priorität genießt, als die Entwicklung von Software im Sinne des Kunden. Die typischen Probleme dieses Vorgehens sind spätes Feedback aufgrund seltener und zu später Releases, mangelnde Offenheit für Änderungen sowie die Entwicklung zu vieler Features, die der Markt nicht braucht. Als Gegenentwurf zum Wasserfallmodell hat sich in den letzten Jahren die agile Softwareentwicklung etabliert. Der zurzeit wohl populärste Vertreter agiler Entwicklungsprozesse ist Scrum.

Dieser Beitrag richtet sich an Projektmanager mit Erfahrung in der klassischen Softwareentwicklung. Der Artikel stellt das agile Projektmanagement als Alternative zur klassischen Softwareentwicklung am Beispiel von Scrum vor und ermöglicht Ihnen zu entscheiden, ob sich der agile Managementansatz für Ihre jeweilige Projektsituation eignet.

Was ist Scrum?

Scrum ist ein Framework für das Management komplexer Softwareprojekte und entstammt der Familie agiler Softwareentwicklungsprozesse. Agile Softwareentwicklung versucht den Softwareentwicklungsprozess flexibel und schlank zu gestalten und begegnet damit den eingangs beschriebenen Problemen. Ein wesentliches und zentrales Merkmal der agilen Softwareentwicklung ist Feedback. Kurze Feedback-Schleifen, stellen sicher, dass der Auftraggeber das bekommt, was er haben will. Änderungen sind keine unerwünschten Hindernisse mehr, sondern selbstverständlicher Teil des Prozesses.

Der Begriff "Scrum" tauchte 1986 zum ersten Mal auf und wurde von Hirotaka Takeuchi und Ikujiro Nonaka als Methode zur Produktentwicklung beschrieben. Fast zehn Jahre später griffen Ken Schwaber und Jeff Sutherland das Thema auf und entwickelten gemeinsam Scrum zu einer Methode für das Management agiler Softwareprojekte weiter. Mittlerweile zählt Scrum zu den etabliertesten agilen Managementmethoden, für die sich Projektleiter, Produktmanager und Softwareentwickler von zertifizierten Trainern der Scrum Alliance ausbilden und zertifizieren lassen können (siehe www.scrumalliance.org).

Viel Feedback und Transparenz

Scrum greift die Prinzipien der agilen Softwareentwicklung auf und setzt sie mit Hilfe einfacher Regeln, klar definierter Rollen und einigen wenigen Meetings in ein Framework. Der Inhalt dieses Frameworks ist vom jeweiligen Scrum-Team…