Was ist Scrum eigentlich?

Scrum Flow - Das Zusammenspiel der Scrum Rollen und Eckpfeiler

Scrum Flow - Das Zusammenspiel der Scrum Rollen und Eckpfeiler

Bei Unternehmen, die sich für agile Software-Entwicklung interessieren bzw. am Beginn stehen, taucht häufig die Frage auf „Was ist Scrum eigentlich?“. Die folgenden Abschnitte sollen einen kompakten Einblick geben, wie man Scrum einfach aber wirkungsvoll erklären kann.

Scrum


Scrum (engl. „Gedränge“) gilt als Vorgehensmodell bzw. als Rahmenwerk für vorwiegend agile Software-Entwicklungen. Vergleicht man hierzu das „Wasserfall“-Modell, in dem sequentiell ein zuvor spezifiziertes Produkt umgesetzt und nach seiner Fertigstellung präsentiert wird, arbeitet man im Gegensatz bei „Scrum“ inkrementell in Iterationen, sogenannten „Sprints“ die zwischen 1 bis 4 Wochen lang sein können. Einmal auf eine Sprintlaufzeit festgelegt, sollte diese nur unter gewissen Umständen geändert werden. Wir empfehlen 2 oder 3 Wochen als Sprintlaufzeit.

Product Owner, ScrumMaster und Team


Scrum gibt uns drei wichtige Rollen vor, aus denen sich das Scrum-Team zusammensetzt: Product Owner, ScrumMaster und das Entwicklungsteam, kurz Team genannt. Der Product Owner ist eine Person, die im Rahmen des Projektes als Auftraggeber oder dessen Stellvertreter steuert. Mit seinen fachlichen Kenntnissen gibt er die Richtung, Priorisierung und Ziele im Projekt vor. Der ScrumMaster ist eine Person, die grundsätzlich die Organisation und Durchführung von Scrum im Projekt übernimmt und die Einhaltung der Werte, Praktiken und Regeln sicherstellt. Er sorgt auch dafür, dass dem Team bei der Entwicklung keine Hindernisse im Weg liegen und damit für eine hohe, bzw. sich steigernde Produktivität. Desweiteren wirkt er auf das Team als Scrum Coach und Scrum Mentor ein. Das Entwicklungsteam selbst ist für die eigenverantwortliche Umsetzung der gemeinsam mit dem Product Owner festgelegten Sprint-Ziele verantwortlich. Es ist funktionsübergreifend, das heißt, jeder Entwickler hat spezielle Fähigkeiten (Architekturentwurf, Softwareentwicklung oder Datenbanken), kann aber auch seine Kollegen in ihren Tätigkeiten unterstützen.

Product Backlog


Zentraler Bestandteil bei „Scrum“ ist das Product Backlog. In diesem hinterlegt der Product Owner alle Anforderungen, auch Business Cases genannt und priorisiert sie nach Wichtigkeit, bzw. Geschäftswert (engl. Business Value). Das Product Backlog ist für alle einsehbar und dient dem Team zur Planung der nächsten Sprints, in dem es die Arbeitspakete anhand der wichtigsten Business Cases identifiziert. Auch gibt es allen Beteiligten einen Überblick über das gesamte Vorhaben und die Größenordnung des Projekts.

Transparenz, Überprüfung und Anpassung


Scrum basiert auf drei Prinzipien: Transparenz (engl. Transparancy), Überprüfung (engl. Inspection) und Anpassung (engl. Adaption). Transparenz für die verantwortlichen Personen über alle Prozesse und Methoden im Projekt, die Einfluss auf das Ergebnis haben. Überprüfungen (Reviews) dienen der Evaluierung der aktuellen Arbeit und Prozesse, um Abweichungen vom gesetzten Ziel frühzeitig zu identifizieren und Anpassungen (Adaption) vornehmen zu können.

Um diese drei Prinzipien im Vorgehensmodell durchzusetzen, sollen zeitbegrenzte (engl. timeboxed) Meetings unterstützen: Sprint Planning I und II, Daily Scrum, Sprint Review und sowie Sprint Retrospektive.

Sprint Planning I


In diesem Meeting stellt der Product Owner seinem Entwicklungsteam das „Was“ vor. D.h. die priorisierten User Stories aus seinem Product Backlog, die er für den folgenden Sprint vorgesehen hat. In einer offenen Diskussion, bspw. mit Planning Poker, klärt das Entwicklungsteam die jeweiligen Anforderungen mit dem Product Owner. Diese werden idealerweise vom Entwicklungsteam schriftlich festgehalten. Am Ende des Meetings verpflichtet sich das Entwicklungsteam zur Umsetzung einer Anzahl von priorisierten User Stories im nächsten Sprint. Diese User Stories werden „Sprint Backlog“ genannt wird.

Sprint Planning II


Das Sprint Planning 2 kümmert sich um die Beantwortung der Frage, “Wie” werden die User Stories umgesetzt. Das Entwicklungsteam hat nach dem Planning I eine gute Vorstellung „Was“ es im Sprint zu entwicklen gilt. In diesem Meeting analysiert das Team jede User Stories und bricht diese in einzelne Aufgaben (engl. Tasks) herunter. Dabei ist zu beachten, dass jede Aufgabe in einem halben oder ganzen Tag erledigt werden kann. Nachdem das Sprint Planning II abgeschlossen wurde, kann mit den Entwicklungsarbeiten begonnen werden.

Daily Scrum


Damit sich das Entwicklungsteam zum Stand der Entwicklungsarbeiten austauschen kann, wird täglich das 15-minütige „Daily Scrum“ oder auch kurz „Daily“ genannt durchgeführt. Es dient dem Team zum identifizieren (Überprüfung) und beseitigen (Anpassung) von Hindernissen bei ihrer Arbeit. Die Teammitglieder bringen sich gegenseitig auf den neuesten Stand und berichten gemäss der Beantwortung der folgenden 3 Fragen:

  • Was habe ich seit dem letzten Daily getan?
  • Was werde ich heute tun?
  • Was sind meine Hindernisse?

Defintion of Done


Anhand einer zu Beginn des Projektes aufgestellten „Definition of Done“, gerne mit DoD abgekürzt, kann jeder jederzeit die Arbeitsergebnisse auf ihre Vollständigkeit und Richtigkeit hin überprüfen. Diese kann auch mit gesammelter Erfahrung im Projekt weiter verfeinert werden, zum Beispiel in der Sprint Retrospektive. Die gelieferten Arbeitsergebnisse sind nur dann „fertig“, wenn sie die Anforderungen der DoD genügen.

Review und Retrospektive

Auch Sprint Review sowie Sprint Retrospektive dienen der Überprüfung und Anpassung im laufenden Projekt und werden nach jedem Sprint durchgeführt. Das Sprint Review dient dazu, die Arbeitsergebnisse des zurückliegenden Sprints dem Product Owner zu präsentieren, der die Ergebnisse begutachtet und schließlich abgenommen oder abgelehnt zu werden. Die Sprint Retrospektive dagegen dient dem Team zur Beurteilung des abgelaufenen Sprints in Bezug auf die beteiligten Personen, Beziehungen, den Prozess und die eingesetzten Werkzeuge.

Wir unterstützen Sie bei der Einführung von Scrum?

Ich hoffe, die zurückliegenden Abschnitte haben Ihnen einen Überblick über das Rahmenwerk Scrum verschaffen können. Benötigen Sie Unterstützung in der Einführung von Scrum? Dann kontaktieren Sie mich noch heute über unser Kontaktformular. Eine Antwort innerhalb 24 Stunden ist Ihnen sicher. Ich freue mich auf Sie!

Ich freue mich über Ihr Feedback.

Ihr Dr. Patrick Seifried
xing patrick_seifried – twitter patrickseifried – linkedin patrickseifried

4 Antworten

  1. Alejandro Sincich
    Hallo Patrick, ich bins aus Argentinien, gratulliere erstmals für diesen Webraum und seine Konzeption. Das Thema Scrum hat mich besonders angesprochen. Die Technik wird im Prinzip als Tätigkeit beschrieben, die mit Abläufen innerhalb eines physikalischen Büros verbunden ist. Daher nun meine Frage: Uns beschäftigt beispielweise ein WebApp Projekt, das präsenziell 3-4 Entwickler, aber eventuell weitere als Fernarbeiter umfassen könnte. Wäre Scrum einem so konzipierten, physikalisch getrennten Team anwendbar? Danke! ... und das Foto vom Team über den Wolken sagt eine Menge. Alex
  2. Dr. Jürgen Hoffmann, Certified Scrum Coach
    Ja. Die Agilen Prinizipien gelten auch dafür: Transparenz, early and regular delivery, selbstorganisiertes Team, inspect & adapt, use of timeboxes. Insofern ist Scrum anwendbar, nur fällt einem manches nicht mehr so leicht in die Hand -> Es ist z.B. schwieriger in einem verteilten Setting eine vergleichbare Transparenz herzustellen. Die Frage ist ob der Gewinn durch weitere Teammitglieder durch die räumliche Distanz nicht wieder verloren geht. Das läßt sich nicht pauschal beantworten - sondern hängt vom Team, der Aufgabenstellung und anderen Rahmenbedingungen ab. Aber auch dafür läßt sich Apply, Inspect & Adapt anwenden: Probiert es aus! Jürgen Hoffmann
  3. Marco Looser
    Wir arbeiten in ähnlicher Konstellation mit Scrum. Wichtig ist eine saubere Ressourcenplanung bzw. konstanter Einsatz der externen Kollegen. Daily Scrums mit Video und interaktivem Board (ScrumWorks) haben sich bewährt. Unsere externen Mitarbeiter sind aber trotzdem oft vor Ort. Es ist dann aus meiner Sicht (PO) einiges effizienter. Aber eventuell reicht auch ein gemeinsamer Research oder Sprint Planning Day und anschliessende enge virtuelle Zusammenarbeit.
  4. Alejandro Sincich
    Vielen Dank für Eure Beiträge - wir werden die Technik genauer eingehen und sie möglichst anwenden. Bei uns geht es neben Code-Generierung um die Erzeugung von Lernstoff mit FlashPPtCamtasiaAudacity, etc. Dabei geht es wieder um sehr kreative Tasks mit schwer abzuschätzenden Erarbeitungs-Zeiten, welche möglicherweise eine flexible Sprint Konzepzion benötigt wird. A. S.
  5. […] zueinander verhalten. Wie konträr, das möchte ich kurz anhand des Wasserfalls-Modells vs. Scrum […]

Einen Kommentar schreiben