Scrum-Charakteristika
Scrum ist eine von mehreren existierenden sogenannten agilen Methoden für Projektmanagement in der Software-Entwicklung und für Projekte aus anderen Disziplinen (F&E, Produktenwicklung im Maschinenbau, Prototyp-Entwicklung im Nahrungsmittelbereich u.v.a.m.) verwendet.

Scrum bietet eine schlanke Projektmanagement-Methode mit folgenden Charakteristika:
- einfache Regeln
- wenige Rollen
- mehrere Arten von Meetings mit bestimmten Zwecken
- einige Schlüssel-Artefakte, deren Pflege Overhead vermeidet und die maximale Transparenz auf einfache Weise bieten
- Pragmatismus statt Dogmatik
- iteratives Vorgehen
- Selbstorganisation und Eigenverantwortung in interdisziplinären Teams
- Konzentration auf hochqualitative Arbeit anstatt auf eine Papierflut bei der Spezifikation
- Änderungen der Kundenanforderungen während des Projekts gelten als normal, nicht als Störfaktor (es gibt keine „fertige“ Spezifikation)
- speziell geeignet für hochkomplexe Projekte mit unklaren Anforderungen (nach der persönlichen Erfahrung des Autors der Normalfall)
( Quelle: http://scrum-master.de/content/view/59/31)

Historisches zu Scrum
Bereits Mitte der 1980er Jahre gab es erste Tendenzen, die bekannten Projektmanagement-Methodiken in Frage zu stellen und nach agileren Ansätzen zu suchen. Seit den 1990er Jahren werden Scrum-Projekte durchgeführt. Etwa seit der Jahrtausendwende war der Erfolg von Scrum mit der explosionsartig wachsenden Zahl erfolgreicher Projekte nicht mehr aufzuhalten.

Harvard BusinessReview schrieb 1986 in "The New New Product Development Game":

Die bestehende "Staffellauf-Vorgehensweise" in der Produktentwicklung gerät unter Umständen in Konflikt mit dem Ziel, maximaler Geschwindigkeit und Flexibilität. Stattdessen könnte ein ganzheitlicher "Rugby-Ansatz" - in welchem ein Team versucht, Wege als Einheit zurückzulegen und dabei den Ball hin- und herspielt - den Anforderungen des heutigen Wettbewerbs dienlicher sein!

Scrum etabliert sich innerhalb weniger Jahre in tausenden Projekten mit bis zu mehreren hundert Beteiligten und wird als konform zu FDA-, ISO-9000- und anderen Standards anerkannt.
( Quelle: http://scrum-master.de/content/view/60/31 )

Scrum in Kurzform
Scrum kennt drei Rollen für direkt am Prozeß Beteiligte: Product Owner (stellt fachliche Anforderungen und priorisiert sie), ScrumMaster (managt den Prozeß und beseitigt Hindernisse) und das Team (entwickelt das Produkt). Daneben gibt es die Rollen des Kunden und zusätzlich des Anwenders.

Die Anforderungen (Requirements) werden in einer Liste (Product Backlog) gepflegt, erweitert und priorisiert. Das Product Backlog ist ständig im Fluß. Um ein sinnvolles Arbeiten zu ermöglichen, wird monatlich vom Team in Kooperation mit dem Product Owner ein definiertes Arbeitspaket dem oberen, höher priorisierten Ende des Product Backlogs entnommen und komplett in Funktionalität umgesetzt (inkl. Test und notwendiger Dokumentation). Dieses Arbeitspaket, das Increment, wird während der laufenden Iteration, des sog. Sprints, nicht durch Zusatzanforderungen modifiziert, um seine Fertigstellung nicht zu gefährden. Alle anderen Teile des Product Backlogs können vom Product Owner in Vorbereitung für den nachfolgenden Sprint verändert bzw. neu priorisiert werden.

Das Arbeitspaket wird in kleinere Arbeitspakete (Tasks) heruntergebrochen und mit jeweils zuständigem Bearbeiter und täglich aktualisiertem Restaufwand in einer weiteren Liste, dem Sprint Backlog, festgehalten. Während des Sprints arbeitet das Team konzentriert und ohne Störungen von außen daran, die Tasks aus dem Sprint Backlog in ein Increment of Potentially Shippable Functionality, also einen vollständig fertigen und potentiell produktiv einsetzbaren Anwendungsteil, umzusetzen. Das Team gleicht sich in einem täglichen, streng auf 15 Minuten begrenzten Informations-Meeting, dem Daily Scrum Meeting, ab, damit jeder weiß, woran der andere zuletzt gearbeitet hat, was er als nächstes vor hat und welche Probleme es evtl. gibt.

Am Ende des Sprints präsentiert das Team dem Product Owner, den Stakeholders u.a. interessierten Teilnehmern in einem sog. Sprint Review Meeting live am System die implementierte Funktionalität. Halbfertiges oder gar Powerpoint-Folien sind während des Reviews verboten. Das Feedback der Zuseher und die neuen Anforderungen des Product Owners für den kommenden Sprint fließen dann wieder in das nächste Sprint Planning Meeting ein, und der Prozeß beginnt von neuem.
( Quelle: http://scrum-master.de/content/view/61/31 )

Scrum-Prozeß
Der ScrumMaster sorgt während des gesamten Prozesses dafür, daß Regeln eingehalten werden und der Status aller Tasks im Sprint Backlog von den jeweils zuständigen Team-Mitgliedern täglich aktualisiert wird. Er macht den Projektfortschritt transparent durch einen geeigneten Reporting-Mechanismus: die Veröffentlichung sog. Burndown Charts, welche den Fortschritt für den aktuellen Sprint bzw. für das gesamte Projekt jeweils in Form einer Kurve visualisieren. Eingezeichnete Trendlinien erlauben es, mögliche Probleme und Verzögerungen einfach (und rechtzeitig!) zu erkennen.
( Quelle: http://scrum-master.de/content/view/61/31 )

Im Kern basiert Scrum also auf einer inkrementellen Vorgehensweise, der Organisation von Entwicklungsabschnitten und Meetings in vordefinierten Zeitabschnitten (Time-Boxes) und der Erkenntnis, daß ein funktionierendes Produkt wichtiger ist als eine dreihundertseitige Spezifikation.

Quellen: Die angeführten Textpassagen wurden grossteils übernommen von: Scrum-Master.de (www.scrum-master.de) mit freundlicher Genehmigung von Alexander Kriegisch.