Boris Gloger ist einer der bekanntesten und erfolgreichsten SCRUM Trainer und Berater in Österreich. In dieser Präsentation aus dem Jahr 2008 schneidet er ein sehr interessantes Thema an, nämlich den Fokus in SCRUM auf den strategischen Geschäfts- bzw. Produktnutzen:
Boris beschreibt in der Präsentation zu recht, dass im traditionellen Projektmanagement der Projektstrukturplan (Work Breakdown Structure) ein zentrales Planungsinstrument ist. Die kleinste Planungseinheit sind Arbeitspakete oder einzelne Aufgaben. Dies kann dazu führen, dass das Projekt „aufgaben-getrieben“ abläuft und die eigentlichen Anforderungen und Ziele im Extremfall vernachlässigt werden. Taktisches anstatt strategisch sinnvolles Arbeiten kann die Folge sein.
In SCRUM ist das zentrale Planungsinstrument der Product Backlog. Boris bezeichnet diesen zurecht als „Feature Breakdown Structure“. In SCRUM orientiert sich das Projektteam an den jeweiligen Features, die unmittelbar aus den definierten Anforderungen des Kunden (bzw. Product Owner) resultieren. Der Fokus auf den strategischen Geschäftsnutzen ist fast die unausweichliche Folge dieses Vorgehen.
Gut, ganz schwarz und weiß malen darf man die Sache sicher nicht. Auch mit traditionellen Methoden kann man den Geschäftsnutzen sicher stellen, und auch mit agilen Methoden können Projekte völlig am Geschäftsnutzen vorbei laufen. Von der Tendenz her stimme ich Boris Gloger aber vollkommen zu: Ein wesentlicher Vorteil der SCRUM Methode besteht darin, dass die Ziele (in IT Projekten Features) im Planungs- und Umsetzungsfokus stehen. Und diese resultieren in der Regel unmittelbar aus den Anforderungen und der Produktvision des Kunden (bzw. Product Owner).
Oder aus der anderen Perspektive gedacht: Im traditionellen Projektmanagement wird der Projektauftraggeber in den Initiierungs- und Planungsprozessen verstärkt eingebunden. Während der Durchführungsprozesse ist die Einbindung häufig nur noch sporadisch. Dies birgt die Gefahr, dass das Projektteam (teilweise) an den Bedürfnissen und Anforderungen des Auftraggebers vorbei arbeitet.
Was meint Ihr? Seid Ihr anderer Meinung?
In gewisser Weise verstehe ich das Problem nicht. Dass der Nutzen nicht aus dem Fokus gerät dafür gibts den Product Owner. Was gelegentlich unter den Tisch fällt ist, dass es nicht nur Features sondern auch eine Product-Vision geben muss. In der Vision stecken die großen Ziele und der strategische Nutzen drin. Wenn der Product Owner an dieser Stelle schlampt schwinden auch die restlichen Scrum-Vorteile dahin.
@Eberhard: Wir sind uns einig, dass der Product Owner eine überaus wichtige Funktion hat und dass die Product Vision natürlich auch gegeben sein muss.
Mir ging es darum, dass eben genau diese Produkt- und Nutzenperspektive im „traditionellen“ Projektmanagement häufig verloren geht. Die Ziele werden am Beginn mehr schlecht als recht formuliert, dann wird GEARBEITET. Die Methodik ist aufgabengetrieben, nicht so sehr produkt- und zielgetrieben. Diese Aussage ist zwar stark vereinfachend, von der Tendenz aber stimmig (finde ich).
Eine besondere Stärke der SCRUM Methodik besteht schlussendlich darin, dass das (Entwicklungs)Team laufend mit den Anforderungen, mit der Produktvision und den damit verbundenen Funktionalitäten/Zielen konfrontiert ist.
Hi Stefan,
ich denke die Bezeichnung Feature Breakdown Structure ist nicht angemessen, da sie mehr Ähnlichkeiten heraufbeschwört als da sind.
Zum Beispiel:
Das Backlog ist nie vollständig und wird normalerweise auch nicht vollständig abgearbeitet.
Der PSP hat eine hierarchische Struktur, auch dies hat das Backlog nicht. Dafür ist es Prioisiert, während jedes Item im PSP erstmal als gleichwichtig zählt.
Gibt wahrscheinlich noch mehr Unterschiede, aber für mich reicht das schon mal um den Begriff Feature Breakdown Stucture abzulehen. Ganz abgesehen, dass im Backlog auch Sachen drinn stehen können, die keine Features sind, sondern zum Beispiel die Entwicklungsinfrastruktur betreffen.
Hi, der der Begriff Feature Break-Down Structure sollte beschreiben, dass eben im Backlog nicht Aufgaben, sondern Dinge, die geliefert werden stehen. Diese werden im Backlog doch auch aufgebrochen in immer kleinere Stories. Das traditionelle Projektmanagement kennt doch auch den Rolling Wave Planungsansatz. Dort werden dann später die WBS detailierter ausgefasst.
btw – in ein Backlog gehören ausschließlich Lieferungen hinein. Entwicklungsumgebungen haben dort drin nichts verloren.
Boris
Das Product Backlog enthält üblicherweise Features in Form von User Stories. Ob Fragen zur Infrastruktur dahin gehören ist abhängig davon, ob die nichtfunktionalen Anforderungen ebenfalls in Form von UserStories erfasst werden. Ich denke nicht, dass es da ein „entweder oder“ gibt, sondern es ganz konkret vom Projekt und dem Vorgehen im Projekt abhängig ist. Nicht zuletzt kann ein Product Backlog auch mehrstufig sein mit Akzeptanzkriterien angereichert werden die solche Elemente beinhalten.
Gruß
Danny