Scrum einfach und kurz erklärt

Die Erfinder von Scrum

Scrum wurde von Ken Schwaber und Jeff Sutherland erfunden und wird seit Anfang der 90er Jahre als Prozessrahmen zum Management von komplexen Produkten verwendet. 1995 wurde Scrum offiziell auf der OOPSLA - der, jährlich in den USA stattfindenden Object-Oriented Programming, Systems, Languages, and Applications - Konferenz vorgestellt.


Der Begriff “Scrum” wurde aus dem Rugby übernommen und bedeutet zu Deutsch, Gedränge. Im übertragenen Sinne ist die enge Zusammenarbeit aller Beteiligten in einem Scrum-Projekt das Gedränge. Wie bei einem Rugby-Spiel akzeptiert Scrum, dass das Ergebnis nicht vorherzusehen ist.

Der Zyklus des Scrum Frameworks

Der Zyklus des Scrum Frameworks

Scrum ist ein Framework

Scrum ist ein Rahmenwerk, dass es ermöglicht, adaptiv, komplexe Aufgabenstellungen zu lösen. Durch die fest integrierte Adaption ist die Produktentwicklung mit Scrum in der Lage, sich permanent neu auszurichten und kann dadurch, unklare Ziele, sogenannte “Moving Targets” erreichen.

Scrum ist iterativ und inkrementell

Der Ansatz von Scrum ist iterativ und inkrementell.

Iterativ, weil die Produktentwicklung in kleinen überschaubaren Zyklen stattfindet. Inkrementell, weil nach jedem Zyklus das Produkt ein Stück mehr fertig geworden ist.

Scrum besteht aus wenigen Elementen

Scrum besteht aus einigen Regeln, Rollen, Events und Artefakten.

Ursprünglich für die Softwareindustrie entwickelt, wird Scrum heute für unterschiedlichste Branchen und Aufgabenbereiche verwendet. Das primäre Ziel von Scrum ist, der höchstmöglich zu erreichende Nutzwert von Produkten.


Scrum ist leichtgewichtig und einfach zu verstehen. Scrum basiert auf der empirischen Prozesssteuerung und fordert ständige Verbesserung.


Scrum stützt sich auf die Säulen: Transparenz, Validierung und Adaption.

Transparenz

ist entscheidend für die Ergebnisverantwortung. Transparenz hilft ein gemeinsames Verständnis herzustellen.

Validierung

in Scrum bedeutet, das die Ergebnisse regelmäßig auf ihre Ziele überprüft werden. Bei Abweichungen werden entsprechende Anpassungen vorgenommen.

Adaption

Anpassung (Adaption) ist erforderlich: wenn festgestellt wird, dass Abweichungen bestehen und das Ergebnis nicht akzeptabel ist. Je nach Analyseergebnis wird eine Anpassung beim Produkt, der Zusammenarbeit oder dem Prozess vorgenommen.


Anpassungen sollten zeitlich schnell erfolgen, damit sich Abweichungen nicht potenzieren. 

4 Meetings oder Events in Scrum

Scrum kennt 4 Events zur Adaption und Validierung: 

  • Das Sprint Planning
  • Das Daily Scrum,
  • Der Sprint Review
  • und die Sprint-Retrospektive.

Die 5 Werte von Scrum

Scrum benennt 5 eigene Werte. Nicht zu verwechseln mit den 12 Werten des agilen Manifest. Die 5 Werte von Scrum heissen:


  1. Selbstverpflichtung 
  2. Mut
  3. Focus
  4. Offenheit
  5. und Respekt

Diese Werte sollen durch das Scrum-Team gelebt werden. Scrum ist dann erfolgreich, wenn alle Beteiligten in Erfüllung dieser fünf Werte kompetenter werden. Das bedeutet, dass die Beteiligten nicht schon zu Beginn von Scrum, maximale Kompetenz besitzen müssen.


Scrum ist vollständig. Werden Teile von Scrum weggelassen, ist das Ergebnis nicht Scrum.


Zusammengefasst ist Scrum: Ein leichtgewichtiges Framework, das  hilft den Wert eines Produktes zu maximieren. Es basiert auf der empirischen Prozesssteuerung.


Scrum ist leichtgewichtig, einfach zu verstehen und schwierig zu meistern. Scrum ist ein Rahmenwerk oder auch Framework, genannt.

 

Die Regeln von Scrum bestimmen die Wechselwirkungen zwischen Rollen, Ereignissen und Artefakten.  Die Vorgehensweise in Scrum ist Iterativ, inkrementell.

Scrum basiert auf der empirischen Prozesssteuerung

Die Empirische Prozesssteuerung ist die Grundlage für die iterative Lösung komplexer Probleme. Scrum basiert darauf. Was verbirgt sich hinter der empirischen, also auf der künftigen Erfahrung beruhenden, Prozesssteuerung?


Empirische Prozesssteuerung ist nicht notwendig, wenn zu Beginn einer Produktentwicklung exakt feststeht, welcher Zielzustand erreicht werden soll.


Ein Besipiel

Verdeutlichen wir das anhand des Brötchenbackens. Der Fertigungsprozess von Brötchen ist ein Prozess, der aus einer Reihe definierter Schritte besteht. Wenn das zu backende Brötchen sich nicht in seiner Eigenschaft ändert, kann dieser Prozeß standardisiert werden.


Bei diesem Prozeß gibt es kaum Überraschungen und die benötigte Zeit für den Herstellungsprozess ist gleichbleibend.


Natürlich kann so ein Prozess beobachtet und optimiert werden. Um zum Beispiel den Produktionsdurchsatz zu erhöhen oder die Produktionskosten zu senken.


Bleibt das zu erzielende Ergebnis gleich, muss der Prozess nicht geändert werden.

Einsatzmöglichkeiten

Die empirische Prozesssteuerung wird dort eingesetzt, wenn ein Produkt  entwickelt werden soll, von dem nicht bekannt ist, wie es beschaffen sein soll. Weder der Zustand FERTIG im Sinne von DONE (Definition of Done) kann definiert werden, noch sind die Anforderungen klar. 


Im Laufe der Produkterstellung werden sich die Anforderungen sicher ändern und der Lösungsweg zum fertigen Produkt ist nicht klar erkennbar.


Die empirische Prozesssteuerung davon aus, dass die Mitarbeiter im Verlauf der Produktentwicklung, Wissen aufbauen und aus Fehlern lernen und sich weiterentwickeln.

Das Fundament empirischer Prozesssteuerung

Das Fundament der empirischen Prozesssteuerung besteht aus:


  • Transparenz 
  • Validierung und
  • Adaption.

In einem Scrum Projekt, werden diese drei Handlungsfelder regelmäßig durchlaufen.


Die Wahl der richtigen Iterationslänge ist entscheidend. Sind die Iterationen zu kurz, sind die Ergebnisse kaum bewertbar. Wenn die Iterationen zu lang sind, kann nicht schnell genug auf Änderungen reagiert werden.


Die empirische Prozesssteuerung vermeidet das Risiko, ein Produkt in die falsche Richtung zu entwickeln und sorgt durch regelmäßige Inspektion und Adaption für eine höhere Produktqualität und oftmals auch eine kürzere Time-to-Market.

Einsatzbereiche für agile Vorgehensweisen

Gibt es Argumente, wann agile Vorgehensweisen eingesetzt werden kann und wann nicht? In welchen Situationen sind klassische Entwicklungsmethoden, wie zum Beispiel, die Wasserfall-Methode, besser geeignet?


Das Wasserfall Modell

Scrum versus Wasserfall

Schauen wir uns den klassischen Wasserfall als Entwicklungsmethode an. Nehmen wir an, ein Kunde kommt zum Hersteller und sagt, ich hätte gerne ein Produkt das die Eigenschaften A, B und C beinhalten soll.

Klassisches Vorgehen

Aus dieser klaren Vorstellung des Kunden heraus erstellen die Analysten einen Katalog mit Anforderungen. Ist dieser Katalog erstellt und mit dem Kunden abgestimmt, wird ein Lieferdatum vereinbart. Dann wird der Anforderungskatalog in die Produktion übergeben und die Herstellung beginnt.


Ist das Produkt getestet und auslieferbar, wird es dem Kunden übergeben. Dieser prüft, ob das Produkt die geforderten Eigenschaften beinhaltet. Ist alles in Ordnung , nimmt der Kunde das Produkt ab und bezahlt die Rechnung. 


Diese Vorgehensweise wird auch BigBang-Lieferung genannt.


Für diesen Fall ist die Wasserfall-Methode gut geeignet. Der Kunde kennt die Eigenschaften seines Produktes ganz genau und ist bestenfalls für marginale Verbesserungsvorschläge empfänglich.


Es ist also für alle Beteiligten klar, wie das Produkt beschaffen sein muss. Der Lösungsweg ist sichtbar.

Scrum oder agiles Vorgehen

Kommt aber ein Kunde zum Hersteller und sagt: “Ich möchte einen Fluss überqueren. Ich weiß nicht wie, aber wichtig ist für mich, dass ich trockene Füße behalte.“


Alles was der Kunde weiß, ist das er ein Transportmittel benötigt um von einem Ufer zum anderen zu gelangen. Dabei ist es völlig offen, welche Beschaffenheit dieses Transportmittel haben soll. Es ist nicht klar, ob es ein Floss, eine Brücke oder sogar ein Katapult sein soll.


In diesem Fall sind die Anforderungen völlig unklar. Nur das Ziel ist bekannt: Der Kunde möchte über diesen Fluss und möchte trockene Füße behalten. Man könnte dieses Ziel auch Vision nennen.


Fakt ist: Der Kunde weiß nicht was für ein Produkt er will. Nur der Nutzen, das Ziel, “Mit trockenen Füßen über den Fluss kommen” ist bekannt.


Unter diesen Voraussetzungen ist der Einsatz einer agilen Vorgehensweise ideal. Denn agile Vorgehensweisen verlangen nicht die Vollständigkeit der Anforderungen für das fertige Produkt. Agile Vorgehensweisen tasten sich in Iterationen, inkrementell an das Ziel heran. Dabei wird der Soll- und Ist-Zustand im Sinne von Inspect & Adapt, regelmäßig abgeglichen.


So kann auf Änderungswünsche schnell reagiert werden. Das ist zum Beispiel der Fall, wenn dem Kunden mitten in der Entwicklung einfällt, dass er zu jeder Zeit bestimmen möchte, an welcher Stelle des Ufers er ankommen möchte und eine Art Steuer benötigt.

Voraussetzungen

Um unter diesen Rahmenbedingungen erfolgreich zu arbeiten, sind 2 Voraussetzungen notwendig.
  1. Die erste Voraussetzung ist die enge Zusammenarbeit zwischen Auftraggeber, Anwender, Auftragnehmer und dem Herstellungsteam. Weil die Anforderungen nicht im Voraus bekannt sind, müssen diese, Schritt für Schritt während des Entwicklungsprozesses gefunden werden.

    Eine enge Zusammenarbeit zwischen den Stakeholdern - Stakeholder sind die Personen, die ein berechtigtes Interesse am Ergebnis haben, und den Entwicklern, ist unumgänglich. Denn um das Produkt zu entwickeln, muss eine stete Diskussion darüber entstehen, wie das Produkt beschaffen sein soll.
  2. Die zweite Voraussetzung ist, dass das Entwicklungsteam auf Veränderung eingestellt sein muss. Denn zu jeder Zeit sind Änderungen möglich, die vom Entwicklungsteam akzeptiert und umgesetzt werden müssen.

Zu erwartende Hindernisse und Probleme bei der Einführung agiler Methoden

In der Praxis hat die agile Vorgehensweise einige Hindernisse zu bewältigen. Wesentliche Hindernisse sind:


  • Die Unternehmensphilosophie oder -kultur steht im Widerspruch zu den zentralen agilen Werten. 
  • Es besteht mangelnde Erfahrung mit der agilen Methode
  • es gibt nur mangelnde Unterstützung des Managements
  • Es formiert sich allgemeiner organisatorischer Widerstand gegen die anstehenden Veränderungen.
Wenn eine Organisation gegen Veränderung resistent ist, funktioniert die agile Einführung nicht. Lassen sich die Hindernisse nicht beseitigen, dann ist es besser traditionelle Verfahren, anstelle von Agilen Methoden anzuwenden.

Fazit

Halten wir fest: Wenn die Anforderungen zu Beginn einer Produktentwicklung nicht vollständig bekannt sind, ist der Einsatz einer agilen Entwicklungsmethode sinnvoll. Sind die Anforderung hingegen klar und zu Beginn der Entwicklung vollständig beschrieben, ist es oftmals besser auf eine klassische Entwicklungsmethode, wie z.B. die Wasserfall-Methode, zurückzugreifen.

Wann würdest du Scrum einsetzen und welche Voraussetzungen hältst du für wichtig? Schreib mir einen Kommentar ...

Über den Autor

Frank Schatz

Wertschätzend. Motivierend. Polarisierend. Einer der führenden T-Shaped Agilisten im deutschsprachigen Raum. Seit über 25 Jahren IT-Unternehmer und Agile Work Experte dem, auf seinem Fachgebiet, kaum jemand etwas vormacht.

Interessante Artikel



{"email":"Bitte E-Mail Adresse eingeben","url":"Website ungültig","required":"Bitte alle Pflichtfelder ausfüllen"}
>