Ist SCRUM eigentlich ein Framework für Projekte und Projektsteuerung?

Diese Frage begegnet einem öfter. Sie ist keineswegs trivial. Am liebsten möchte man mit „Jein“ antworten. Aber lasst uns das genauer ansehen.

SCRUM ist ein primär produkt- und qualitäts-orientiertes Framework; ich zitiere aus dem SCRUM Guide:

Scrum is a framework for developing, delivering, and sustaining complex products. … Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

Und:

… Scrum was initially developed for managing and developing products. Starting in the early 1990s, Scrum has been used extensively, worldwide, to:

  1. Research and identify viable markets, technologies, and product capabilities;
  2. Develop products and enhancements;
  3. Release products and enhancements, as frequently as many times per day;
  4. Develop and sustain Cloud (online, secure, on-demand) and other operational
    environments for product use;
  5. and,

  6. Sustain and renew products.

Nun könnte man sagen, dass das Entwickeln von Produkten („developing products“) – und im Besonderen von SW-Produkten – ja typischerweise in Projekten erfolge. Aber da ist auch die Aussage zu „sustaining products“ bzw. „sustain and renew products“ – also ein Bekenntnis zu einer nachhaltigen (und ggf. laufenden und langfristigen) Pflege von Produkten. Ausdrücklich werden auch „enhancements“ – also Erweiterungen – erwähnt. Damit wird ein ganz anderes Spielfeld betreten, nämlich das der Pflege von IT-Produkten, die in der Praxis meist in IT-Services eingebettet sind. SCRUM weist also zumindest in der IT einen Überlapp mit dem IT Service Management [ITSM] auf, das sich in spezifischen Prozessen mit (Produkt- und Service-) Changes sowie (Produkt-) Releases befasst.

Zeitbeschränkung?

Ein Projekt hat nach klassischer Auffassung einen definierten Anfang und ein definiertes Ende. Das Änderungs- und Arbeitsaufkommen zu einem Produkt wird in SCRUM über den „Product Backlog“ gesteuert. Und dazu sagt der SCRUM Guide:

A Product Backlog is never complete… If a product exists, its Product Backlog also exists.

In der Version von 2016 hieß es aus meiner Sicht noch deutlicher: „As long as a product exists, its Product Backlog also exists.“
Sprich: Die Arbeit/Pflege des Produktes endet potentiell nie. Das ist vollständig kompatibel mit einem langfristigen Life-Cycle-Management – etwa von SW-Produkten.

Am anderen Ende der Zeitskala ist die Aussage zur Abdeckung einer möglicherweise hochfrequenten Release-Politik von Interesse – sogar unterhalb der Zeitskala von 1 Tag. Auch dann wird man im IT-Geschäft kaum noch von Projekten sondern eher von DevOP-Aktivitäten sprechen.

Verwendet der SCRUM-Guide das Wort „Projekt“?

Ein anderer Hinweis auf eine projektfreie Ausrichtung des SCRUM-Frameworks ergibt sich aus der Tatsache, dass der SCRUM-Guide das Wort „Projekt“ (project) nur an einer Stelle verwendet und zwar interessanterweise auf der Ebene der Sprints – aber auch dort nur vergleichsweise:

„Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product.“

Was ist davon zu halten?

Scrum stellt unzweifelhaft das zu erzeugende und/oder zu pflegende Produkt in den Vordergrund – und Sprints wie Events/Inspections als Mittel zur Produkterzeugung wie der geordneten Produkt-Modifikation. Hinsichtlich des Arbeitsumfangs (Anzahl der benötigten Sprints) werden bewusst keine Vorgaben gemacht. Damit werden beliebige Zeitskalen abdeckbar.

SCRUM ist es letztlich völlig egal, ob man den Erzeugungsprozess oder eine Sprintabfolge zur gezielten Modifikation eines Produkts ein Projekt nennt oder nicht. Gegen den Projektbegriff spricht das Anerkennen der Tatsache, dass der Product Backlog die Arbeit über die gesamte Lebenszeit des Produkts steuert. Damit ist SCRUM im Besonderen für die Erstellung von SW geeignet, die sich laufend im Beta-Stadium befindet. Freundlicher ausgedrückt: SCRUM unterstützt u.a. eine kontinuierliche Fortentwicklung von SW-Produkten.

Es wirkt somit generell – aber im Besonderen auch im im SW-Geschäft – fast künstlich, SCRUM auf Projektarbeit einschränken zu wollen. Wenn das dennoch gemacht wird, so ist das meist auf externe Faktoren (Business Cases, Auftraggeber/Auftragnehmer-Verhältnis, Verträge mit Begrenzungen von Budgets, Zeit, Ressourcen etc.) zurückzuführen. Es wird es uns dann aber auch nicht wundern, wenn man feststellt, dass man SCRUM für solche Fälle durch weitere Verfahren ergänzen muss, die den speziellen Rahmenbedingungen Rechnung tragen. In der Regel bleiben entsprechende Verfahren und Aktivitäten am Product Owner hängen, der letztlich für das Produkt, seine Eigenschaften und Qualität verantwortlich ist. Den Leser dieses Blogs wird es ferner nicht überraschen, dass ich ein „agiles Release-Management“ als eine sinnvolle SCRUM-Ergänzung betrachte.

Schreibe einen Kommentar

Dieser Blog verwendet Cookies. Bei weiterer Nutzung gehen wir von Ihrem Einverständnis aus. Optionen/Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen