Scrum – mit Scrum für jeden Sprint gerüstet

Scrum – das Projekt-Entwicklungs Framework — Bildquelle: Thinkstock Askold Romanov

Für viele ist Scrum der Inbegriff agiler Methoden.

Das geht so weit, dass manche denken, beide Begriffe seien synonym. In der Tat ist Scrum ein wichtiges Tool im agilen Baukasten und wohl das am häufigsten verwendete – auch wenn es noch andere gibt.

Ein Artikel von Carolin Metz - Lesezeit ca. 8 Minuten

Scrum ist ein Framework für Produkt- und Projektmanagement, das in der Softwareentwicklung entstanden ist. Mittlerweile findet es aber auch in vielen anderen Bereichen Einsatz. Der Begriff "scrum" stammt von Ikujirō Nonaka und H. Takeuchi, bedeutet "Gedränge" und ist dem Rugby entlehnt. Er spielt auf die sich selbst organisierenden Teams an, die ihre eigene Taktik bestimmen, um ihr Ziel zu erreichen – sowohl im Rugby als auch im Unternehmen. Scrum weist Parallelen zum Lean Management auf und folgt den Werten der agilen Softwareentwicklung.

Ein Framework ist eine Art Arbeitsumgebung, die sich aus Best Practice-Erfahrungen speist und für den der das Framework benutzen will, erlernbar ist, so dass er auf Arbeitsschritte und fertige Teillösungen zurückgreifen kann. So gibt es für viele Programmiersprachen Frameworks, die die Entwicklungsarbeit extrem erleichtern. Doch nicht nur für Programmiersprachen existieren diese Arbeitsumgebungen, sondern auch für den Akt der Software-Entwicklung selbst. Scrum ist eine solche Framework-Arbeitsmetthodik, die viele Prozesse während der Planung und Ausführung erleichtert und anstehende Aufgaben in sinnvolle und handhabbare Arbeitsschritte unterteilt. Gleichzeitig animiert sie zu einer engagierten Zusammenarbeit im Team und zu Routinen, die Fehler vermeiden.

Warum Scrum?

Auf der einen Seite steht der Wille, systematisch eine komplexe Software zu entwickeln. Früher hat man das nach dem so genannten Wasserfallprinzip geregelt – das heißt man hat Phase für Phase abgearbeitet, um zum endgültigen Resultat zu kommen. Auf der anderen Seite stehen die ständig wechselnden Anforderungen an die Software, die viele Voraussetzungen, die in frühen Phasen noch Geltung hatten, in späteren Phasen auf einmal obsolet machen und durch neue Anforderungen ersetzen. Die Scrum-Herangehensweise ist nun, die verschiedenen Phasen im Kleinen, in realisierbaren Einheiten beizubehalten und Fortschritte in so genannten "Sprints" zu vollziehen. Sprints sind Teillösungen, die in einem überschaubaren Arbeitszeitrahmen – etwa einer Woche, maximal einem Monat - vollzogen werden können.

Wie funktioniert Scrum?

Bei Scrum werden sowohl die Planung als auch das Produkt iterativ und inkrementell entwickelt – also in Wiederholungen und in kurzen abgeschlossenen Abschnitten. Es gibt einen langfristigen Plan (Product Backlog), der immer weiter konkretisiert und verfeinert wird. Innerhalb eines Sprints wird ein Teilplan (Sprint Backlog) erstellt, der sich auf die nächsten anstehenden Aufgaben konzentriert.
Das Product Backlog erhebt keinen Anspruch auf Vollständigkeit wie ein Pflichtenheft, sondern wird ständig weiterentwickelt. Die Anforderungen werden dabei nicht in technischer Fachsprache aufgeschrieben, sondern aus Sicht des Nutzers in Alltagssprache – oft geschieht das in der Form von Userstories. Diese erklären, was der User mit einer Funktion machen will und warum er es machen will. Das Sprint Backlog wiederum wird mit einem Taskboard visualisiert. Es handelt sich dabei um eine Kanban-Tafel, auf der man den Bearbeitungszustand der Aufgaben erkennt. So erkennen alle, auch ein Kunde, der nicht aus der IT kommt, was warum entwickelt wird.
Sie möchten wissen, in welchen Unternehmen Scrum eingesetzt wird? In unserem Download-Produkt finden Sie Beispiele aus bekannten Firmen und Tipps zur Umsetzung.

Rollenspiel - jeder hat eine feste Rolle

Im Scrum kennt man drei Rollen: den Scrum Master, das Entwicklerteam und den Product Owner. Das Entwicklerteam bearbeitet die Sprints eigenverantwortlich und ungestört. Der Product Owner ist im besten Fall ein Sachverständiger des Auftraggebers, der mit allen Anforderungen an das Projekt vertraut ist und als Ansprechpartner für alle offenen Fragen dient. Er ist für die Eigenschaften des Produkts verantwortlich, sammelt die Anforderungen im Product Backlog und priorisiert sie. Der Scrum Master ist der Projektleiter und muss in seiner Rolle dafür sorgen, dass alle vereinbarten Scrum-Regeln eingehalten werden und diese gegen Dritte durchsetzen.

Die Scrum-Aktivitäten

Wichtig ist, dass ein Sprint einen fixen vorher festgelegten Zeitrahmen hat, beispielsweise zwei Wochen. Alles, was nicht in dieser Zeit abgeschlossen wird, wird in den nächsten Sprint geschoben. Während des Sprints kann das Team im Optimalfall ungestört an den Aufgaben arbeiten und wird nicht für andere Tätigkeiten herangezogen. Regelmäßig wiederkehrende Aktivitäten strukturieren den Sprint:

Sprint Planning

In der Sprintplanung wird geklärt, was im nächsten Sprint entwickelt wird und wie die Aufgaben erledigt werden. Product Owner und Entwicklungsteam erarbeiten ein gemeinsames Verständnis für die to dos, besprechen Eigenschaften und Akzeptanzkriterien der Features und legen Kriterien dafür fest, wann eine Userstory in die Entwicklung gehen kann ("Definition of Ready") und wann eine Funktionalität als fertig gilt ("Definition of Done"). Anschließend plant das Entwicklungsteam im Einzelnen, welche Tickets für das Sprintziel abgearbeitet werden müssen – das Ergebnis davon ist das Sprint Backlog, also der "Fahrplan" für den nächsten Sprint. Das Team verpflichtet sich gemeinsam, das Sprint-Ziel zu erreichen. Das Sprint Planning sollte maximal zwei Stunden je Sprint-Woche in Anspruch nehmen.

Daily Scrum

Am Anfang jedes Arbeitstages kommt das Entwicklungsteam zum "Daily Scrum" zusammen und jeder berichtet, woran er gerade arbeitet. Hier werden keine Probleme einzelner Entwickler gelöst. Stattdessen geht es darum, dass sich jeder im Team einen Überblick über den Stand der Dinge verschafft. Das Meeting sollte nicht länger als 15 Minuten dauern.

Sprint Review

Am Ende eines Sprints findet ein Sprint Review statt, bei dem auch Kunden und User anwesend sein sollten. Das Entwicklungsteam präsentiert seine Ergebnisse und die Funktionalitäten werden diskutiert. Der Product Owner sammelt das Feedback, um das Product Backlog zu aktualisieren. Dauer des Meetings: höchstens eine Stunde je Sprint-Woche.

Sprint Retrospective

Auch dieses Meeting findet am Ende eines Sprints statt, aber nur innerhalb des Entwicklungsteams. Hier wird besprochen, wie der Sprint gelaufen ist und was man in Zukunft verbessern kann, um effizienter und effektiver zu werden. Probleme sollten offen angesprochen werden, das Team entscheidet dann selbst, wie es die Verbesserungsmaßnahmen festhalten will – zum Beispiel im Sprint Backlog oder in einer eigenen Liste. Für die Sprint Retrospective sollte man sich nicht mehr als 45 Minuten pro Sprint-Woche nehmen.

Product Backlog Refinement

Dieser Prozess, auch Backlog Grooming genannt, ist fortlaufend: Der Product Owner und das Entwicklungsteam entwickeln das Product Backlog weiter: Es werden neue Aufgaben hinzugefügt, unnötige gestrichen, Releases geplant etc. Da hierfür auch die Meinung des Kunden wichtig ist, kann es hilfreich sein, wenn er beim Product Backlog Refinement ebenfalls zugegen ist. Dieser Prozess sollte nicht mehr als 10 Prozent der Zeit des Entwicklungsteams verbrauchen.
Wenn dringende Aufgaben hinzukommen, müsste laut Lehrbuch eigentlich der Sprint abgebrochen und ganz neu geplant werden. In der Praxis werden die Tasks oft in den laufenden Sprint aufgenommen und dafür Tickets mit entsprechendem Umfang entfernt. Gemäß der Agilen Theorie ist das Vorgehen bei Scrum transparent – jeder kann sich jederzeit über den Fortschritt im Projekt informieren. Zu diesem Zweck gibt es üblicherweise ein Burn-down-chart, auf denen der Soll- und der Ist-Zustand grafisch angezeigt werden. Am Ende eines Sprints muss das Inkrement in einem nutzbaren Zustand sein und der Definition of Done entsprechen.

Was benötigt man, um Scrum im Unternehmen einzusetzen?

Zunächst braucht es die passende Unternehmenskultur, in der Eigeninitiative, Vertrauen und Verantwortungsbewusstsein verankert sind, damit Scrum funktioniert. Die Mitarbeiter müssen nicht nur fachlich qualifiziert sein, sondern auch die nötigen Sozialkompetenzen mitbringen, um agile Methoden umzusetzen. Für sie hat das durchaus Vorteile, denn sie können mit Scrum selbstbestimmter arbeiten, Verantwortung übernehmen und sind im Projekt flexibler.

Doch es gibt auch Fallstricke, die man vermeiden sollte: Man darf sich mit Scrum nicht verzetteln. Wenn alle mitdiskutieren und sich einbringen dürfen, ist es nicht ganz einfach, das Team auf Linie zu bringen und konzentriert in eine Richtung zu arbeiten. Außerdem sollte man nicht zu vielen verschiedenen Ideen und Aufgaben nachhängen, sondern sich auf das große Ganze konzentrieren. Scrum ist zudem nicht für langfristige Planung geeignet, daher kann es sinnvoll sein, um den Scrum-Prozess herum noch eine Projektplanung für die langfristigen Ziele aufzubauen.

Scrum ist nicht sehr kompliziert und benötigt nicht viel Equipment. Hilfreich ist eine Software, die bei der Sprintplanung unterstützt, indem sie zum Beispiel Burn-Down-Charts und das Taskboard visualisiert. Mittlerweile gibt es zudem viele Ausbildungen und Zertifizierungen für Scrum-Master, mit denen man sich das benötigte Wissen schnell aneignen und zum Experten für agile Methoden im Unternehmen werden kann.

Sie möchten agile Methoden bei sich im Unternehmen einführen? Experte für agiles Projektmanagement werden? Melden Sie sich für den Online-Zertifikats-Lehrgang Agiles Projektmanagement an!