Scrum

 
Scrum Flow – Das Zusammenspiel der Scrum Rollen und Eckpfeiler

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