Praktisches & Grundsätzliches zur Informatik

SCRUM Definition, Agiler Prozess

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

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


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:





stw4238SCRUMPOSCRUM . Product . OwnerNews?

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