SCRUM verglichen mit klassischem Projektmanagement
Klassisches Projektmanagement favorisiert ein Team, dem ein unumschränkt herrschender Projektmanager 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.
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).
- 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 begutachtbar 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 gleichzeitig 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:
- SCRUM Master Training
- Top 10 failure modes of a Product Owner
- Die SCRUM Fibel – SCRUM sehr klar beschrieben durch einen SCRUM Master
- Sehr ausführlich, aber auch gut: SCRUM erleben
- und nochmals erklärt bekommen (interessant ist die in diesem Video um 4:50 erklärte Extrapolationsmöglichkeit).
- Setting Mini Milestones for Scrum Success: Was hier gefordert wird,
garantiert noch lange nicht Erfolg — da bin ich ganz sicher. Aber leider wird SCRUM sehr oft tatsächlich so gelebt: mit Focus auf Mini Milestones,
und somit auf eher nur kurzfristig wichtigen Aspekten statt auf solchen, die nachhaltig Erfolg zu garantieren in der Lage wären.
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).
stw4238SCRUMPO — SCRUM . Product . Owner — News?
Mehr + B G E + S H A + More
SCRUM in all Details
Six Reasons to dislike SCRUM
Die Nase voll von SCRUM (aus dem Alltag naiv-agiler Teams)
Perfect Agile