Wie Scrum entwickelt wurde: Ursprünge und Anwendung der Methodik
Scrum ist eine agile Entwicklungsmethodik mit einer einzigartigen Rollenverteilung im Team und einer besonderen Organisation der Iterationen. Scrum, wie andere agile Projektmanagementmethoden, betont einen teamorientierten Ansatz, kurze Iterationen und kontinuierliche Verbesserung während der Arbeit. Diese Prinzipien werden durch eine Reihe spezifischer Rollen, Regeln, Prozesse und Werkzeuge realisiert, die es Teams ermöglichen, Produkte doppelt so schnell zu produzieren.
In Scrum-Teams sind die Schlüsselrollen der Scrum Master und Product Owner. Die Iterationen beginnen mit der Planung, bei der die Teammitglieder „Planning Poker“ spielen, und enden mit einer Demo und Retrospektive.
Die Scrum-Methodik wurde 1993 von den Amerikanern Jeff Sutherland, einem Forscher und Unternehmensberater, und Ken Schwaber, einem praktizierenden Programmierer, entwickelt. 1995 präsentierten die Autoren ihren Ansatz offiziell auf einer wissenschaftlichen Konferenz der Association for Computing Machinery in Austin, Texas.
Die Idee der Co-Autoren war neu: Sie entlehnten sowohl das Konzept als auch den Namen aus der Arbeit der japanischen Managementforscher Takeuchi und Nonaka, “The New Product Development Game”, veröffentlicht 1986. Japanische Hersteller hatten bereits Ansätze verwendet, die die Grundlage von Scrum bilden. Der Name der Methodik stammt aus dem Rugby, wo “Scrum” – ein Spiel – die Bedeutung von Teamarbeit für den Sieg auf dem Spielfeld hervorhebt.
Anwendung von Scrum in IT und darüber hinaus
Scrum wurde zuerst in Unternehmen angewendet, die Software produzieren. Das erste Projekt, das von Sutherland vor der offiziellen Präsentation von Scrum geleitet wurde, war die Entwicklung von Software für ein Geldautomaten-Netzwerk (1983). Programmierer in IT-Unternehmen und ‑Abteilungen sind die Hauptnutzer von Scrum. Der Schöpfer der Methodik besteht jedoch darauf, dass Scrum zur Lösung jeder Aufgabe verwendet werden kann, und zitiert Beispiele aus der Fertigung, dem Bauwesen, der Bildung, der Politik und sogar aus Haushaltsaufgaben wie allgemeiner Reinigung oder Eventorganisation.
Laut dem Scrum Alliance Bericht von 2016 waren 21% der mit Scrum abgeschlossenen Projekte nicht IT-bezogen. Verschiedene Abteilungen verwenden Scrum erfolgreich:
Scrum vs. Agile vs. Waterfall
Scrum gehört zur Gruppe der agilen Methodologien. Agile ist keine separate Methodik, sondern eine Entwicklungsphilosophie. Ihre Hauptprinzipien sind im “Manifest für agile Softwareentwicklung” (2001) aufgelistet, in dem die Bedeutung von Teams, Produktfokus, Prozesstransparenz, kontinuierliche Verbesserung und schnelle Ergebnisse hervorgehoben werden.
Scrum ist eines der agilen Frameworks, eine formalisierten Methodik für Projektarbeit. Andere agile Methodologien sind XP, Crystal, Kanban, Lean, Rapid Application Development, Scrumban usw. Scrum ist also agil, aber agil ist nicht nur Scrum.
Um die Unterschiede und Ähnlichkeiten zwischen Scrum und Agile zu visualisieren:
Scrum | Agil | |
Philosophie | - | + |
Methodik | + | - |
Rituale | + | - |
Rollen | + | - |
Artefakte* | + | - |
Transparenz | + | + |
Kurze Iterationen | + | + |
Häufige Releases | + | + |
Änderungsmanagement | + | + |
| Kontinuierliche Verbesserung | + | + |
*Artefakte in Scrum sind Objekte, die vom Team während des Projekts erstellt werden. Dazu gehören das Produkt-Backlog, das Sprint-Backlog und das Produkt-Inkrement – ein funktionierendes Stück Funktionalität, das am Ende des Sprints demonstriert wird.
Agile Methoden stehen im Gegensatz zum Wasserfallmodell, das in den 90er Jahren von Entwicklungsteams weit verbreitet verwendet wurde. Dieses Modell umfasst die sequenzielle Ausführung, wobei jede Phase erst gestartet wird, wenn die vorherige abgeschlossen ist.
Wie man gemäß Scrum arbeitet
Rollen in Scrum:
- Scrum-Team: Das Kernteam von Scrum – eine zusammenhängende Gruppe von Fachleuten. Scrum-Teams sind autonom und entscheiden selbst, wie sie Aufgaben erledigen.
- Scrum Master: Der formelle Leiter des Scrum-Teams, der sicherstellt, dass die Methodik korrekt angewendet wird und die Team-Moral hoch bleibt. Sie sind verantwortlich für das „Wie“ der Arbeit.
- Product Owner: Verantwortlich für die Funktionalität des Produkts. Verwalten das Projekt-Backlog und kommunizieren mit dem Kunden.
- Kunde: Der Endbenutzer oder Klient des Projekts, entweder extern oder intern (z.B. die Verkaufsabteilung, die ein CRM-System anfordert).
Regelmäßige Scrum-Meetings in Worksection
- Planung: Das erste Meeting beginnt den Sprint. Das Team, zusammen mit dem Scrum Master und dem Product Owner, wählt Aufgaben aus dem obersten Teil des Backlogs aus, um sie zu erledigen.
- Tägliches Stand-Up: Jeden Tag zur gleichen Zeit diskutieren die Teammitglieder den Fortschritt der Arbeit und beantworten:
— Was habe ich gestern getan, um dem Team zu helfen, sein Ziel zu erreichen?
Was werde ich heute tun?
Was hat meine Arbeit behindert? - Sprint-Review: Wenn der Sprint endet, wird eine Demo der abgeschlossenen Funktionalität dem Kunden gezeigt.
- Retrospektive: Das Team bespricht die abgeschlossenen Aufgaben, die aufgetretenen Probleme und Möglichkeiten zur Verbesserung.
Algorithmus: Was kommt als Nächstes?
- Wählen Sie einen Product Owner, um die Ziele klar zu definieren.
- Bildung eines Scrum-Teams.
- Bestimmen Sie einen Scrum Master.
- Erstellen Sie ein Projekt-Backlog mit allen potenziellen Aufgaben.
- Schätzen Sie die Backlog-Aufgaben mit relativen Werten (z.B. Fibonacci-Zahlen).
- Planen Sie den Sprint, wählen Sie Aufgaben aus und weisen Sie sie zu.
- Richten Sie ein Scrum-Board ein, das in „To Do“, „In Progress“ und „Done“ unterteilt ist.
- Führen Sie tägliche Stand-Ups durch.
- Am Ende des Sprints eine Überprüfung und Retrospektive durchführen.
- Starten Sie den nächsten Sprint mit der Planung.
Was zu lesen, um Scrum besser zu verstehen
- Scrum Guide (Ken Schwaber, Jeff Sutherland)
- Scrum: Die Kunst, in der Hälfte der Zeit doppelt so viel Arbeit zu leisten (Jeff Sutherland)
- Agiles Manifest für Softwareentwicklung
Vorteile und Nachteile von Scrum in IT
Vorteile:
- Transparenz: Offener Informationsaustausch und Zusammenarbeit.
- Teamautonomie: Teams entscheiden selbst, wie sie arbeiten, was Freiheit und Verantwortung motiviert.
- Risikominimierung: Schnelle Anpassung an Änderungen im Projekt.
Nachteile:
- Nicht geeignet für Projekte mit vagen Anforderungen an das Endprodukt.
- Schwierig in groß angelegten Projekten ohne Modifikationen anzuwenden.