Praktisches & Grundsätzliches zur Informatik


SCRUM verglichen mit klassischem Projektmanagement

Klassisches Projektmanagement favorisiert ein Team, dem ein unumschränkt herrschender Projekt­manager vorsteht — wo der nicht weise genug regiert (indem er jede anstehende Entscheidung der Person überlässt, die am ehesten in der Lage ist, sie richtig zu fällen), wird das Projekt Schaden nehmen.

Wo solch ein Projektmanager vom Auftragnehmer kommt, beobachtet man immer wieder, dass er nicht neutral genug handelt: Sein Interesse ist, den Auftraggeber so früh wie möglich zu einem Einfrieren der Requirements an die entstehende Lösung zu bewegen. Dies widerspricht der Tatsache, dass

  • in der heutigen Geschäftswelt die Anforderungen an geschäftskritische Applikationen einem ständigen Wandel im Detail unterliegen und
  • solche Anforderungen derart komplex sind, dass man nicht annehmen sollte, sie könnten noch vor Implementierungsbeginn in allen Einzelheiten bekannt und genau verstanden sein.

Daher gilt: Ein Einfrieren der Anforderungen an entstehende Software lange vor Projektende ist dem Auftraggeber heute nicht mehr wirklich zumutbar (auch wenn das die Abwicklung von Fest­preis­projekten deutlich schwieriger macht).


SCRUM will dem Rechnung tragen und verteilt deswegen die Verantwortlichkeiten im Projekt wie folgt an gleichberechtigt nebeneinander stehende Akteure: Es sind dies

  • ein Product Owner (Requirements Manager) – er tut alles, was notwendig ist, zu erreichen, dass das entstehende Produkt an den Kunden schrittweise ausgeliefert werden kann und jede dieser Versionen zum Zeitpunkt ihrer Auslieferung nur Eigenschaften hat, die Nutzer, Betreiber und Anwender des Produkts sich wirklich (und am dringendsten) wünschen.
  • ein SCRUM Master (Teilersatz für den klassischen Projektmanager) – seine Aufgabe besteht darin, alles zu tun, dass das Entwicklungsteam möglichst effektiv, möglichst effizient und möglichst ungestört arbeiten kann.
  • und ein sich selbst organisierendes Entwicklungsteam (SCRUM Team), welches
    • seine Arbeit als Folge sog. Scrums organisiert,
    • in ständigem Kontakt mit dem Product Owner steht,
    • und das Produkt so formt, wie der Product Owner das möchte (nach Features und auch nach Reihenfolge, in der sie auslieferbar sein sollen).

    Scrum in diesem Sinne ist
    • ein durch das Team in Absprache mit dem Product Owner definierter kurzer Zeitabschnitt,
    • der dazu bestimmt ist, ein ganz bestimmtes Zwischenergebnis zu erarbeiten,
    • welches nach Möglichkeit auslieferbar, wenigstens aber durch den Product Owner begutacht­bar sein muss (damit der weiss, ob das Projekt sich in die richtige Richtung bewegt – wenn nicht, wird erwartet, dass er gegensteuert, d.h. Anforderungen präzisiert, ihrer Priorität nach neu einstuft, oder im Ausnahmefall auch revidiert).

SCRUM-Puristen halten nichts davon, weitere Rollen zu definieren. Wo das dennoch sinnvoll erscheint, muss man sie sehen als Rollen einzelner Mitglieder des Entwicklungsteams. In meinen Augen sollte es so wenigstens noch einen Teamleiter geben und einen Systemarchitekten, der gleich­zeitig auch als Qualitätsmanger agiert.

SCRUM Master sind typischerweise für mehrere Projekte gleichzeitig tätig.

Die Rolle Product Owner geeignet zu besetzen ist schwierig, da diese Person — ein der wichtigsten im Projekt — einerseits Vertreter der Endanwender, andererseits aber auch ein erfahrener Software Ingenieur sein sollte.

Siehe auch:

Die Erfinder von SCRUM — Jeff Sutherland & Ken Schwaber — haben ihre Idee zuletzt aktualisiert und komplett spezifiziert im SCRUM Guide 2011.

In [1] wird berichtet: "Ken Schwaber acknowledged that only 1 in 4 Scrum implementations achieve the success desired by the companies trying it. ... This number has been generally accepted by the Scrum community as accurate (as discussed at Scrum gatherings and on user groups)." In [2] wird versucht, dem etwas nachzugehen.

In [2] liest man: "For SCRUM, just like in an intense rugby scrum, the team members gather together every morning in a short, high-impact session. They all answer just three basic questions: what did you do yesterday, what will you do today and are there any impediments in your way? In such a burly, but friendly brawl, the team spirit becomes strong and tight. But before you know it, the main emphasis is on optimising micro results and it gets very far from direction, coherence, business context and architecture."

In [3] wird klar, wie unbefriedigend solches Vorgehen enden kann: "The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. Which of these milestones marks the end of the work is entirely specific to the project. No matter which impetus stops work, Scrum ensures that the most valuable work has been completed when the project ends." Kann ein derart praktiziertes Projektende in Festpreisprojekten beide Parteien zufriedenstellen?

Mein Eindruck:

  • SCRUM passt gut zu Projekten, in denen es darum geht, ein existierendes System kontinuierlich fortzuentwickeln in einer langen Folge kleiner, in sich abgeschlossener Schritte.
  • Für Vorhaben aber, die erfordern über Monate vorauszudenken und entsprechend langfristig zu planen, ist SCRUM sicher nicht ausreichend (man würde damit fahren wie nachts mit einem Auto ohne Fernlicht).

Wissenswertes zu "Agiler Prozess, SCRUM Definition" zusammengestellt durch Gebhard Greiter.
tags: seiteSCRUMProductOwner: SCRUM1gegreit Product1gegreit Owner1gegreit