Softwareentwicklern dürfte Scrum schon lange ein Begriff sein. Denn das wörtliche „Gedränge“ ist ein weiteres Beispiel für agile Vorgehensmodelle. Wenn Sie Scrum anwenden, arbeiten Sie flexibel und eng mit dem Kunden. Dadurch erhält er am Ende das Produkt, das er in der Praxis tatsächlich benötigt. Einen kompakten Einblick in Scrum erhalten Sie in diesem Beitrag.

Wie sich Scrum von klassischen Vorgehensweisen unterscheidet

Von klassischen Prozessmodellen wie der Wasserfallmethode unterscheidet sich Scrum hinsichtlich der Arbeitsweise, Rollenverteilung und Ergebnisse. Wie bei agilen Vorgehensmodellen üblich fließen die Änderungen der Kundenanforderungen während der Produktentwicklung flexibel ein. So können Sie zum Beispiel Kosten minimieren, da die Änderungen nicht erst erfolgen, wenn das Produkt bereits fertiggestellt ist.

Der Kunde erhält also bereits nach jedem Durchlauf, dem sogenannten Sprint, ein funktionsfähiges Gesamtsystem. Somit ist er mit dem Ergebnis am Ende wahrscheinlich zufriedener, da er die Funktionalitäten bereits frühzeitig ausprobieren kann.

Scrum setzt ebenfalls nicht auf die klassische Rollenverteilung. Es gibt keinen Projektmanager, der plant, delegiert und überwacht. Vielmehr organisiert das Scrum-Team, das aus verschiedenen Rollen besteht, sich selbst.

So ist das Scrum-Team aufgebaut

Zum Scrum-Team gehören drei interne Rollen, die keiner Hierarchie unterliegen. Externe Rollen haben ebenfalls Einfluss auf den Scrum-Prozess.

Interne Rollen:

Product-Owner: Der Product-Owner vertritt die Belange des Kunden im Projekt. Deshalb spielt er im Scrum-Team eine wichtige Rolle. Er definiert die Anforderungen an das Produkt und ist die gesamte Projektlaufzeit vor Ort. Durch den Product-Owner fließen Änderungen flexibel in das Projekt ein. So ist sichergestellt, dass der Kunde stets in die Entwicklung involviert ist und Einfluss auf sein Produkt nehmen kann.

Scrum-Master: Als Verbindungsglied zwischen dem Scrum-Team und der Öffentlichkeit fungiert der Scrum-Master. Er kommuniziert für das Scrum-Team mit nicht am Projekt Beteiligten. Intern überwacht der Scrum-Master, dass das Team die Scrum-Grundsätze einhält und beseitigt mögliche Hindernisse im Scrum-Prozess.

Entwicklungsteam: Das Entwicklungsteam entwickelt das Produkt in mehreren Durchläufen (Sprints). Fünf bis neun Personen gehören meistens zum Entwicklungsteam. Benötigt ein Projekt mehr Entwickler, werden mehrere Scrum-Teams gebildet. Damit bleibt die gute Kommunikation unter den Teammitgliedern erhalten.

Externe Rollen:

Management: Das Management sorgt für die idealen Rahmenbedingungen des Projektes, indem es zum Beispiel materielle Ressourcen bereitstellt. Es schirmt das Scrum-Team vor externen Anforderungen ab und beseitigt mit dem Scrum-Master die Hindernisse.

Kunde: Der Kunde ist der Auftraggeber, der am Ende das Produkt erhält. Er steht in engem Kontakt zum Product-Owner, der seine Anforderungen im Projekt vertritt.

Nutzer: Der Nutzer ist der Anwender, der das Produkt letztendlich benutzt. Er kann auch mit dem Kunden identisch sein und ist die eigentliche Zielgruppe des Produkts.

Wie der Scrum-Prozess funktioniert

Genau wie beim klassischen Projektmanagement erfolgt vor dem Projektstart eine Planung der personellen und materiellen Ressourcen. Eine feste Zeit- und Budgetplanung ist allerdings nicht möglich, weil Scrum während der Entwicklung flexibel Änderungen zulässt. Deshalb einigen sich Kunde und Auftragnehmer häufig auf ein gewisses Zeit- oder Budgetkontingent – ohne ein festes Projektergebnis. Der Auftragnehmer kann aber schätzen, was er in dieser Zeit realisieren kann.

Der Scrum-Prozess besteht aus Artefakten (Übersichten) und Meetings und läuft in Sprints ab. Bei jedem Durchlauf entsteht bereits ein funktionsfähiges System oder Produkt, das der Kunde einsetzen kann. So stellt er fest, ob er damit arbeiten kann oder nicht. In weiteren Sprints passt das Scrum-Team das Produkt immer weiter an die tatsächlich benötigten Funktionen des Kunden an.

Vor dem Sprint

Die Anforderungen des Kunden hält der Product-Owner im Product-Backlog fest. Diese Übersicht verändert sich ständig und ist somit nie vollständig. Ergeben sich Änderungen, ergänzt das Scrum-Team die fortlaufende Liste. Die Anforderungen sind nach Prioritäten geordnet und erhalten jeweils eine Aufwandsschätzung.

Vor jedem Durchlauf (Sprint) beraten alle Projektrollen im Sprint-Planning-Meeting über die Aufgaben des Sprints. Der Product-Owner stellt dabei die Arbeitspakete aus dem Product-Backlog vor, das Entwicklungsteam schätzt den Aufwand der einzelnen Arbeitspakete ein. Das Team wählt Arbeitspakete für den nächsten Sprint aus und hält diese im Sprint-Backlog fest. Der Sprint kann nun starten.

Während des Sprints

Im Gegensatz zum Extreme Programming (XP), bei dem jederzeit Änderungen möglich sind, sind bei Scrum die Arbeitspakete des Sprint-Backlogs während eines Sprints nicht veränderbar. Wenn die Teammitglieder auf Hindernisse stoßen, die sie von Aufgaben abhalten, hält der Scrum-Master diese in einer Liste, dem Impediment Backlog, fest. Er ist auch verantwortlich dafür, diese Hindernisse zu beseitigen. Im Daily-Scrum-Meeting erfahren alle Teammitglieder von den neuen Hürden. Dieses Treffen findet täglich statt und dauert maximal 15 Minuten. Hierbei tauschen die Teammitglieder lediglich Informationen aus: Was hat jeder seit gestern erledigt? Was setzt jeder bis zum nächsten Meeting um? Welche Hindernisse gibt es? Jeder kann am Meeting teilnehmen.

Nach dem Sprint

In einem Sprint-Review-Meeting führt das Entwicklungsteam dem Product-Owner das System live vor beziehungsweise präsentiert die Ergebnisse des Sprints. Dieses Treffen ist für alle Rollen offen. Dessen Ergebnisse fließen wiederum in das Planning-Meeting des nächsten Sprints ein. Davor diskutieren das Entwicklungsteam und der Scrum-Master in der sogenannten Retrospektive über die Erfahrungen während des Sprints und die Evaluierung beim nächsten Sprint.

Scrum ist also im Vergleich zu XP eine gemäßigte Form der agilen Vorgehensmodelle. Wenn Sie nach dieser Methode arbeiten, erhält Ihr Kunde schnell ein funktionsfähiges Produkt, das er testen kann. So verhindern Sie späte und damit teure Änderungen im Entwicklungsprozess und erhöhen die Kundenzufriedenheit.