In der Software-Welt hat sich der klassische Entwicklungsprozess mit den 5 Meilensteinen (Produktidee, -definition, -entwicklung, -einführung und End-of-Life) nicht bewährt. Die starren Projektvorgehensweisen führen zu verspäteten und nicht mehr marktgerechten Produkten. Größere Entwicklungsprojekte haben gezeigt, dass durch lange Projektlaufzeiten die Planungsrisiken in der Funktions-, Termin- und Qualitätseinhaltung zu groß geworden sind. Deshalb erfolgt heute das Management vieler SW-Projekte in agilen Prozessen nach dem Scrum-Prinzip. Das Basiskonzept von Scrum setzt auf ein iteratives und inkrementelles Vorgehen in kleinen Entwicklungsschritten und Teams.
Das Erfolgskonzept ist:

• gesicherte Produktfunktionalitäten in kleinen Entwicklungsintervallen
• regelmäßige Anpassbarkeit der Anforderungen im Produktentstehungsprozess
• permanente Transparenz der Entwicklungssituation

Der Produktmanager als Product Owner

Der Produktmanager wird bei einem agilen Produktmanagement Product Owner genannt. Er repräsentiert den Kunden und das Management. Seine Verantwortung bezieht sich sowohl auf das Produkt als auch die internen Prozesse. Er arbeitet enger und intensiver mit dem Entwicklungsteam zusammen als in dem alternativen „Wasserfall“-Prozess mit Meilensteinen ausgerichtet auf das Gesamtprojekt.
Das Entwicklungsteam enthält alle Funktionsträger, die für ein fertiges Produkt erforderlich sind, und ist verantwortlich für die Umsetzung der geplanten Funktionen. Es hat 7 (plus/minus) Mitglieder, die interdisziplinär arbeiten.
Hinzu kommt der Scrum Master, der als der Hüter des Vorgehens für die Einhaltung der agilen Prozesse sorgt und entstehende Hemmnisse beseitigt.
Zunächst erarbeitet der Product Owner die Produktvision. Dazu gehören die Zielgruppen, der Nutzen für den Kunden und die angestrebte Wettbewerbsposition des neuen Produktes. Auf dieser Basis werden mit dem Entwicklungsteam die Kundenanforderungen in dem Produkt-Backlog gesammelt und priorisiert. Wikis sind geeignete Lösungen für den Produkt-Backlog.
Die Kundenanforderungen werden in User-Stories formuliert und die bilden die Vorgabe für die Entwicklung. Die hochprioren Anforderungen haben für die Umsetzung Vorrang.
In der Regel ersetzen die User-Stories das Lasten- und Pflichtenheft. Der Detailierungsgrad ist somit deutlich geringer als im klassischen Prozess.

Der Entwicklungsprozess

Entwickelt wird in mehreren Intervallen genannt Sprints. Für den jeweiligen Sprint werden die Ziele, die Aufgaben (User Stories/Funktionen) und das Zeitraster durch den Product Owner vorgegeben. Es erfolgt in jedem Sprint ein vollständiger Entwicklungszyklus bis zum Test und der Dokumentation, so dass einsatzfähige Lösungen für den Kunden entstehen. Ein Sprint dauert typischerweise 30 Tage. Es können auch kürzere Sprints vereinbart werden.
Wesentliche Steuerungselemente des Sprints sind die Sprint-Planung, der Daily Scrum, der Sprint-Review und die Sprint Retrospektive. Täglich erfolgt der Daily Scrum, ein kurzes Meeting, zur Feststellung des Fortschrittes, der Planung für den nächsten Tag und der eventuellen Beseitigung von Hemmnissen. Für die Visualisierung des Entwicklungsfortschrittes in einem Sprint werden typischerweise Burn Down Charts verwendet, die permanent aktualisiert werden. In dem Burn Down Chart wird der Verlauf der täglichen Leistung dargestellt und durch Fortschreibung kann das voraussichtliche Ende des Sprints kalkuliert werden. Im Sprint-Review erfolgt die Abnahme der entwickelten Funktionen durch den Product Owner. Es ist dann der Kundentest oder -einsatz möglich.
Die Vorgaben für den nächsten Sprint erfolgen anhand der im Produkt-Backlog aktualisierten Kundenforderungen, so dass sehr kunden- und marktnah entwickelt wird. Es folgen weitere Sprints von der gleichen Zeitdauer wie der des ersten Sprints bis zur Fertigstellung des neuen Produktes oder der neuen Produktversion. Durch die Mitarbeit am Product-Backlog, den kleineren Entwicklungsschritten und dem eventuellen frühen Kundeneinsatz ist das Entwicklungsteam näher am Marktgeschehen und kann aktiver mitgestalten.

Mögliche Probleme des Konzeptes sind Einführungsprobleme durch eine fehlende Systematik und Konsequenz, die evtl. nicht vorhandenen Entscheidungsbefugnisse des Product Owners und Reibungen mit den angrenzenden Funktionsbereichen Service, Marketing oder Vertrieb aufgrund der asynchronen Arbeitsweise. Größere Unternehmen stoßen häufiger auf Probleme, da es gilt, die spezifische Kultur und Vorgehensweise von Scrum im Unternehmen zu akzeptieren.

Neben den bereits genannten Vorteilen des agilen Prozesses ist die höhere Motivation des Entwicklungsteams durch die selbstorganisierte, funktionsübergreifende und marktnahe Arbeitsweise von besonderer Bedeutung. Jeder Entwickler ist gleichberechtigt am Erfolg beteiligt und sieht dieses auch. So ist es nicht verwunderlich, dass Fan-Gemeinde von Scrum sehr groß geworden ist und Unternehmen wie Google, Microsoft, Yahoo, SAP oder Motorola erfolgreich Scrum-Methoden anwenden.

Tags: Innovation, Produktmanagement