Wer ist dieser SCRUM überhaupt?

Andreas Öffl, Lehrender am Institut Internet-Technologien & -Anwendungen an der FH JOANNEUM, spricht in seinem Blogbeitrag über das in der Softwareentwicklung agile und oft genutzte Vorgehensmodell SCRUM.

Wer sich in den letzten zwanzig Jahren mit Softwareentwicklung in Entwicklungsteams oder mit Projektmanagement auseinandergesetzt hat, ist wohl früher oder später über den Begriff „Scrum“ gestolpert. Ob als Wunderwaffe, Allheilmittel, Zukunft der Softwareentwicklung, Revolution der Produktivität oder als Hype, Scharlatanerie, Esoterik, Zeitverschwendung – wie alle Buzzwords polarisiert auch Scrum. Wer noch keine Erfahrungen mit Scrum gemacht hat, hat zumindest eine Meinung dazu. Naturgemäß lässt die vergleichsweise große Medienpräsenz von Scrum eine hohe Erwartungshaltung entstehen. Ebenso führen falsche Erwartungen zwangsläufig zu Enttäuschungen. Wer oder was ist also Scrum und was kann man sich erwarten?

Scrum ist ein „agiles“ Vorgehensmodell zur Softwareentwicklung

Das heißt, seine Inhalte und Prinzipien beruhen auf dem berühmten „Manifest für Agile Softwareentwicklung“. Im krassen Gegensatz zur Softwareentwicklung nach traditionellem Projektmanagement wird also nicht versucht, zuerst einen möglichst genauen Plan zu erstellen und diesen anschließend möglichst genau zu befolgen und abzuarbeiten. Stattdessen wird in Zusammenarbeit mit den Kundinnen und Kunden in möglichst kurzen Intervallen immer das zuerst umgesetzt, was den Kundinnen und Kunden am wichtigsten ist. Dadurch haben einerseits die Kundinnen und Kunden häufig die Möglichkeit, den weiteren Projektinhalt zu verändern und damit letztendlich möglichst genau das Endprodukt zu bekommen, dass er oder sie sich wünscht (und bis es so weit ist, zumindest die bereits umgesetzten Teile einsetzen zu können). Andererseits gibt es auch dem Entwicklungsteam regelmäßig die Gelegenheit, darüber nachzudenken, was es zukünftig besser machen kann. Von dieser intensiven, engen Zusammenarbeit in den kurzen Entwicklungszyklen (Sprints) kommt auch der Name „Scrum“, in Anlehnung an das „Angeordnete Gedränge“ im Rugby.

Spielregeln

Die Spielregeln von Scrum sind „leicht zu erlernen, schwierig zu meistern“. Einen Hinweis darauf gibt die Tatsache, dass in den meisten agilen Transformationen Scrum zum Einsatz kommt, aber beinahe die Hälfte aller agilen Transformationen scheitern. Was sind nun diese einfach zu erlernenden Spielregeln von Scrum?

Zunächst gibt es die Rollenteilung

Der Product Owner kümmert sich um den Mehrwert des Produktes – das „was“. Er stimmt mit den Kundinnen und Kunden sowie anderen Stakeholdern ab, was am wichtigsten ist und bereitet die Features (meist in Form von „User Stories“) für das Entwicklungsteam auf. Das Entwicklungsteam soll sich ganz auf seine Kernkompetenz konzentrieren können, dem Erstellen des Produktes. Es kümmert sich also um das „wie“. Das Entwicklungsteam vor Störungen zu schützen ist wiederum eine der Aufgaben des Scrum Masters. Er sorgt auch dafür, dass die Scrum-Spielregeln von allen Beteiligten eingehalten werden, unterstützt bei der Umsetzung von Scrum und klärt darüber auf, was Scrum ist.

Dann gibt es vier definierte Ereignisse

Im Sprint Planning wird vom Scrum Team ein Sprintziel festgelegt, das belegt, wie der kommende Sprint einen Mehrwert für das Produkt generiert. Das Entwicklungsteam legt daraufhin fest, wie viele der wichtigsten und vorbereiteten User Stories im kommenden Sprint umgesetzt werden. Danach plant das Entwicklungsteam im Detail, wie das Sprintziel erreicht werden kann. Im Daily Scrum stimmt sich das Entwicklungsteam täglich max. 15 Minuten ab, was jedes Teammitglied seit dem letzten Daily Scrum gemacht hat, was es bis zum nächsten Daily Scrum machen wird, und ob es auf Hindernisse (Impediments) gestoßen ist. Um deren Beseitigung kümmert sich wieder der Scrum Master. Im Sprint Review wird das Sprintergebnis vom Scrum Team den Stakeholdern live vorgezeigt. Die Stakeholder können dadurch sofort Feedback geben, welches vom Product Owner für künftige Sprints aufgenommen wird. Schlussendlich inspiziert das Scrum Team in der Sprint Retrospektive das Sprintergebnis, um zu ergründen, wie Interaktionen, Werkzeuge, Prozesse etc. noch effizienter eingesetzt werden könnten, um die kommenden Sprints noch angenehmer und erfolgreicher für alle Beteiligten zu gestalten.

Zuletzt definiert Scrum noch drei Artefakte

Im Product Backlog erfasst und verwaltet der Product Owner alle Featurewünsche der Stakeholder und bereitet sie nach Priorität für das Entwicklungsteam auf. Im Sprint Backlog verwaltet das Scrum Team die Featurewünsche, die im aktuellen Sprint umgesetzt werden. Letztlich stellt das Product Increment die funktionstüchtige Software zu Ende des Sprints dar.

Soweit, sehr grob umrissen, die in Scrum definierten Rollen, Ereignisse und Artefakte. Selbstverständlich gibt es all diese Elemente aus gutem Grund und jedes Element erfüllt seinen ganz spezifischen Zweck. Hier liegt auch des Pudels Kern, denn all diese Elemente können völlig falsch eingesetzt werden. Damit man eine Chance hat, Scrum korrekt und erfolgreich einzusetzen, muss man sich auch mit den fünf Werten (Commitment, Fokus, Offenheit, Respekt und Mut) sowie drei Säulen (Transparenz, Inspektion und Adaption) von Scrum befassen. Das ist zwar schwieriger, weil abstrakter, aber das Verständnis und die Umsetzung dieser Werte und Säulen entscheiden letztlich darüber, ob die Ereignisse und Artefakte im Sinne von Scrum eingesetzt werden, oder zu bloßen Werkzeugen, Prozessen und Metriken verkommen.

Scrum im Studiengang „Mobile Software Development“

Im Rahmen von „Mobile Software Development“ haben Studierende nicht nur die Gelegenheit, die Theorie hinter Scrum im Detail kennenzulernen, sie können auch gleich erste praktische Erfahrungen damit machen. Im geschützten Umfeld im Rahmen von zwei verschränkten „Cross-over“-Lehrveranstaltungen können sie unter Verwendung von Scrum in Entwicklungsteams Software entwickeln. Über mehrere Sprints hinweg können sie ihre Erfahrungen mit Scrum reflektieren und sind somit besser auf den Einsatz von Scrum in ihren Partnerunternehmen vorbereitet. Zusätzlich haben sie dadurch die Gelegenheit, agile Entwicklung nicht aus der Perspektive von Studierenden kennen zu lernen, sondern erkennen, worauf es bei der Softwareentwicklung aus Sicht von Kundinnen und Kunden sowie anderen Stakeholdern ankommt.