Schweitzer Fachinformationen
Wenn es um professionelles Wissen geht, ist Schweitzer Fachinformationen wegweisend. Kunden aus Recht und Beratung sowie Unternehmen, öffentliche Verwaltungen und Bibliotheken erhalten komplette Lösungen zum Beschaffen, Verwalten und Nutzen von digitalen und gedruckten Medien.
Dieses Kapitel beantwortet die grundlegende Frage »Was ist Scrum - und was ist es nicht?«. Anwendungsszenarien, wissenschaftliche Grundlagen, ein historischer Rückblick sowie das Agile Manifest sind die Perspektiven, aus denen wir Scrum in diesem Kapitel betrachten.
Laut Scrum Guide ist Scrum »ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren«. Scrum wurde ursprünglich in der Softwareentwicklung eingesetzt, um (Software-)Produkte mit dem größtmöglichen fachlichen Nutzen zu entwickeln. Mittlerweile hat es auch in vielen anderen Domänen Einzug gehalten, um komplexe Aufgaben zu meistern - von der Produktentwicklung über Dienstleistungen bis hin zu Verwaltungsund Managementfunktionen in Organisationen.
Scrum ist ein Framework, kein Prozess. Es definiert nur wenige Verantwortlichkeiten, Events, Artefakte und Commitments und beschreibt deren Zusammenspiel. Die Arbeitsweisen eines Scrum-Teams entwickeln sich in dem vom Scrum Guide abgesteckten Rahmen.
Scrum ist kein Allheilmittel. Sein immer breiter werdendes Einsatzspektrum erweckt bei einigen Menschen den Anschein, dass sich mit Scrum alle Probleme dieser Welt sehr leicht lösen lassen. Das ist nicht der Fall. Scrum kann z.B. Risiken nicht verhindern (das kann kein Vorgehensmodell), macht sie aber frühzeitig transparent und somit beherrschbar. Es fördert die Zusammenarbeit zwischen Menschen, den Austausch von Wissen und das organisationale Lernen und stärkt damit die Resilienz von Teams, Projekten und Organisationen.
Scrum per se ist kein Entwicklungsbeschleuniger. Teams werden nicht besser oder schneller, nur weil sie nach Scrum arbeiten. Da sie aber fokussiert nur die Dinge tun, die aktuell relevant sind, werden die wirklich wichtigen Dinge früher fertig.
Scrum stützt sich auf Lean Thinking und Empirismus. Lean Thinking reduziert Verschwendung und fokussiert auf das Wesentliche. Die Theorie des Empirismus besagt, dass Wissen auf Erfahrung beruht und Entscheidungen auf der Grundlage dieses Wissens getroffen werden. Die drei Säulen des Empirismus schaffen die dafür notwendigen Voraussetzungen:
Die zyklische Struktur von Scrum mit seinen Iterationen und den wiederkehrenden Events bietet regelmäßig die Gelegenheit zur Überprüfung und Anpassung. Da diese Zyklen vergleichsweise kurz sind (zwischen wenigen Tagen und maximal einem Monat), können Risiken und Abweichungen schnell erkannt und frühzeitig angegangen werden. Auch der Fortschritt wird damit sofort sichtbar.
Die Entwicklung mit Scrum geschieht iterativ-inkrementell: Mit jeder Iteration, also mit jedem Entwicklungsabschnitt, in Scrum Sprint genannt, werden Inkremente fertiggestellt, die benutzbar sind. Diese Methode eignet sich aufgrund ihrer kurzen Feedback-Zyklen besonders für die Lösung komplexer Probleme. Dafür sind lediglich drei Ergebnisverantwortlichkeiten erforderlich:
Historisch bedingt, ist im Kontext von Scrum immer noch sehr viel von Produktentwicklung die Rede. Sein tatsächlich breiteres Einsatzspektrum findet im Scrum Guide erst seit der im November 2017 erschienenen Revision Erwähnung. Ein Produkt im Sinne von Scrum ist nicht zwingend ein physisches Artefakt oder ein Stück Software, sondern kann eine Dienstleistung, ein Konzept oder etwas völlig anderes sein. Wenn im Folgenden von »entwickeln« und »Entwicklung« die Rede ist, meinen wir damit generell das Bearbeiten komplexer Aufgabenstellungen.
Zwar hat Scrum seine Wurzeln in der Entwicklung komplexer Softwaresysteme, aber komplexe Probleme gibt es auch in anderen Bereichen unserer Welt. So war es nur folgerichtig, dass irgendwann die ersten Versuche unternommen wurden, die Prinzipien von Scrum auf andere Branchen, Anwendungs- und Lebensbereiche zu übertragen - mit Erfolg. In [Wolf 2015] berichten einige Pioniere von ihren Erfahrungen mit Scrum in der Verwaltung, bei der Unternehmensgründung oder im Kundenservice. Mittlerweile gibt es viele Fallbeispiele und sogar spezielle Konferenzen zum Einsatz agiler Vorgehensmodelle jenseits der IT.
Der Scrum Guide trägt dieser Entwicklung Rechnung. Alle Referenzen auf IT-spezifische Tätigkeiten und Prozesse sind aus dem Dokument verschwunden. In unserem Buch liegt der Schwerpunkt dennoch weiterhin auf der Entwicklung komplexer Softwareprodukte, weil das gut zu einem Verlag passt, der schwerpunktmäßig Bücher zu Softwareentwicklungs- und IT-Themen publiziert. Bei allem Verständnis für das zunehmend breite Anwendungsspektrum von Scrum sind wir es unserer vornehmlich mit Softwareentwicklung beschäftigten Leserschaft schuldig, einen angemessenen Praxistransfer für ihre Domäne zu liefern. Erst dann wird das, was im Scrum Guide sehr allgemein formuliert ist, leicht anwendbar - das ist die Essenz unserer langjährigen Erfahrung in vielen ganz unterschiedlichen Scrum-Teams und -Projekten.
Um diese Frage zu beantworten, werfen wir zunächst einen Blick in die Vergangenheit.
Die geistigen Väter von Scrum sind Ken Schwaber und Jeff Sutherland. Beide beschäftigen sich zu Beginn der 1990er-Jahre zunächst unabhängig voneinander, später gemeinsam mit der Frage, wie man Produkte schneller und flexibler entwickeln kann. Aus dem Fachartikel »The New New Product Development Game« [Takeuchi 1986] beziehen sie nicht nur wesentliche Ideen für ihr Framework, sondern auch den Namen Scrum. Der Begriff stammt aus dem Rugby und bezeichnet dort den Neustart eines Spiels nach einer kleineren Regelverletzung [Rugby Scrum].
Die Welt der Softwareprojekte ist zu dieser Zeit geprägt von traditionellen Managementmethoden, die der Komplexität der Softwareproduktentwicklung durch Projekthierarchien, Kontrollmechanismen sowie langfristige und detaillierte Planung zu begegnen versuchen. 1994 veröffentlicht die Standish Group ihren ersten CHAOS-Report, der die Fehlerquote aufzeigt, die auf der Grundlage von mehr als 8.000 untersuchten IT-Projekten berechnet wurde. Die Ergebnisse sind alarmierend: 31% aller Projekte wurden vor der Fertigstellung komplett abgebrochen - ein wirtschaftlicher Verlust von 80 Milliarden US-Dollar. 53% der Projekte wurden mit erheblichen Mängeln fertiggestellt. Obwohl dabei nur durchschnittlich 61% der ursprünglichen Anforderungen erfüllt wurden, brauchten diese Projekte das Doppelte der ursprünglich veranschlagten Dauer und wurden zudem doppelt so teuer wie geplant. Nur 16% der Projekte wurden letztlich erfolgreich fertiggestellt.
1995 präsentiert Ken Schwaber während des Workshops »Business Object Design and Implementation« im Rahmen der OOPSLA-Konferenz den wissenschaftlichen Artikel »SCRUM Development Process« [Schwaber 1997], in dem er die Erfahrungen mit dem Entwicklungsprozess in seiner Firma »Advanced Development Methods« beschreibt. Co-Chair des Workshops ist Jeff Sutherland, der 1993 bei der Firma Easel gemeinsam mit Kolleginnen und Kollegen ein ähnliches Vorgehensmodell entwickelt und eingesetzt hat. Sutherland und Schwaber arbeiten fortan gemeinsam an der Weiterentwicklung von Scrum. 1999 veröffentlichen sie zusammen...
Dateiformat: ePUBKopierschutz: Wasserzeichen-DRM (Digital Rights Management)
Systemvoraussetzungen:
Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet - also für „fließenden” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an. Mit Wasserzeichen-DRM wird hier ein „weicher” Kopierschutz verwendet. Daher ist technisch zwar alles möglich – sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.
Weitere Informationen finden Sie in unserer E-Book Hilfe.
