Scrum - kurz & gut (eBook)

KAPITEL 1

Einleitung

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.

Was ist Scrum?

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 ist angewandter Empirismus

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:

• Transparenz (Transparency): Um Erkenntnisse aus Erfahrungen zu gewinnen, müssen alle notwendigen Informationen verfügbar und sichtbar sein.
• Überprüfung (Inspection): Das Scrum-Team muss in angemessenen zeitlichen Abständen seine Vorgehensweise auf den Prüfstand stellen. Es gilt zu beurteilen, ob die gewählte Arbeitsweise für das Erreichen des Ziels förderlich ist. Um sicherzustellen, dass das Scrum-Team auf das richtige Ziel hinarbeitet, wird in regelmäßigen Abständen auch das Inkrement hinsichtlich des Produkt-Ziels und der Vision überprüft.
• Anpassung (Adaptation): Die im Rahmen der oben beschriebenen Überprüfung erkannten Verbesserungspotenziale werden vom Scrum-Team umgesetzt, sodass das Ziel besser oder schneller erreicht werden kann.

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.

Scrum hilft, komplexe Probleme zu meistern

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:

• Product Owner: Der Product Owner gibt mit dem Sprint-Ziel den Rahmen dafür vor, was innerhalb des nächsten Sprints entwickelt werden soll.
• Developer: Die Developer bauen die Inkremente mit Blick auf das gemeinsam mit dem Product Owner formulierte Sprint-Ziel und präsentieren das Ergebnis am Ende des Sprints.
• Scrum Master: Der Scrum Master ist unter anderem verantwortlich dafür, dass der Wertschöpfungsprozess so reibungslos wie möglich verläuft, und unterstützt bei der kontinuierlichen Verbesserung des Prozesses und des Scrum-Teams.

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.

Scrum entfaltet seine Wirkung auch außerhalb der Softwareentwicklung

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.

Warum Scrum?

Um diese Frage zu beantworten, werfen wir zunächst einen Blick in die Vergangenheit.

Die Historie von Scrum

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...