Was ist eigentlich Scrum?

Im meinem letzten Blogbeitrag ging es um die Frage, was eigentlich agil bzw. Agilität ist. Jetzt geht es um die nächste Ebene – um die Frameworks. Scrum ist ein Framework für die agile Softwareentwicklung. Reicht Ihnen diese Antwort? Dann können Sie aufhören zu lesen. Wenn Sie jedoch wissen wollen, welche Vorteile dieses Framework für Ihr Business bietet, dann sollten Sie unbedingt dranbleiben!

Scrum wurde von Ken Schwaber und Jeff Sutherland entwickelt. Der erste Artikel dazu wurde 1995 veröffentlicht. Also sogar schon vor Entstehung des agilen Manifests. Ab 2001 erlangte Scrum dann immer mehr Bekanntheit und ist heute zu einer Art Synonym für agile Projektmethoden geworden.

Scrum ist kurz gesagt ein schlankes Prozessframework für die Softwareentwicklung. Es wird auf ca. 16 Seiten im Scrum Guide (Link zu scrumguides.org) definiert und beschreibt

• 3 Rollen
• 3 Artefakte und
• 5 Ereignisse

In Scrum sind die Rollen des Product Owners, des Scrum Masters und des Entwicklungsteams definiert. Falls Sie den Projektmanager suchen und nicht finden: den gibt es in Scrum nicht und es ist auch nicht der Product Owner oder der Scrum Master. Es gibt ihn nicht! Das heißt aber nicht, dass niemand Projektmanagementtätigkeiten übernimmt.

Der Product Owner hat die wirtschaftliche Verantwortung über das Produkt. Er hat die Aufgabe den Nutzen des Produkts zu maximieren.  Das heißt, er ist für den Erfolg des Produktes am Markt verantwortlich. Der Markt kann dabei auch für User in einem Unternehmen stehen. Er erfasst, reiht und priorisiert die Anforderungen und definiert die Produktvision. Durch ihn wird definiert, WAS entwickelt werden soll.

Das Entwicklungsteam ist für die Umsetzung der Anforderungen verantwortlich. Es ist interdisziplinär zusammengesetzt und ist selbstorganisiert. Das Team muss in der Lage sein, das Produkt entwickeln zu können. Es muss also alle Kompetenzen haben, die es dafür benötigt. Dem Entwicklungsteam sagt niemand – wirklich niemand, kein Product Owner oder Manager, auch nicht der Scrum Master – WIE es die Anforderungen umsetzt. Diese Entscheidung trifft das Entwicklungsteam.

Der Scrum Master hilft dem gesamten Scrum Team, also dem Product Owner und dem Entwicklungsteam, dass es seine Aufgaben bewältigt und sich in der Anwendung von Scrum und dem agilen Manifest weiterentwickeln kann. Oft wird der Scrum Master als „Servant Leader“ beschrieben. Er ist jedenfalls Trainer und Coach für das Scrum Team, aber auch für die Organisation. Außerdem hilft er dem Management Scrum das agile Manifest zu verstehen und sich in der Anwendung zu verbessern.

Das sind der Product Backlog, der Sprint Backlog und das Product Increment.

Der Product Backlog ist der Ort, wo die Anforderungen dokumentiert sind. Er ist im Allgemeinen eine gereihte Liste an Anforderungen und verändert sich während der Projektlaufzeit. Anforderungen können dazu kommen, nach oben oder unten gereiht werden oder auch komplett wieder entfernt werden. Der Product Backlog bildet dabei eine Momentaufnahme der aktuell bekannten Anforderungen an das Produkt.

Der Sprint Backlog ist die Menge an Anforderungen, die das Entwicklungsteam in einem Sprint umsetzen möchte. Gemeinsam mit den vom Entwicklungsteam erstellten Tasks, stellt er den Umsetzungsplan für den Sprint dar.

Das Product Increment ist das Ergebnis eines Sprints und erweitert frühere Produktinkremente um weiteren Nutzen. Es sollte auch immer auslieferbar sein, sprich keine Fehler enthalten.

Dabei handelt es sich um die Meetings, die innerhalb eines Sprints abgehalten werden. Diese sind der Sprint selbst, das Sprintplanning zur Planung des Sprints, das Daily Scrum zur Selbstorganisation des Entwicklungsteams. Am Ende des Sprints das Sprint Review zur Präsentation des Product Increment an die Stakeholder, sowie die Sprint Retrospektive zur Prozessverbesserung.

Schlank definiert, kurz erklärt, einfach zu verstehen, aber schwer zu meistern

Scrum ist tatsächlich nicht kompliziert und leicht erklärt. Trotzdem scheitern immer wieder Scrum-Einführungen oder man tut sich schwer mit der Anwendung. Wie eingangs erwähnt, ist Scrum als Framework die nächste Ebene nach dem agilen Manifest, wenn man agil arbeiten möchte. Nur weil man Scrum macht, muss man nicht agil sein. Versteht man die agilen Wertepaare nicht oder nimmt sie nicht ernst, wird man mit Scrum scheitern, da man bereits an der Basis scheitert.

Ich persönlich würde auch nicht von einer Einführung von Scrum sprechen. Das ist kein einmaliger Prozess. Hat man einmal damit begonnen mit Scrum zu arbeiten, entwickelt man sich ständig weiter, findet neue Anwendungen dafür, professionalisiert sich in unterschiedlichen Themen und Gebieten und hat am Ende vielleicht sogar eine agile Organisation im Unternehmen. Ist man so richtig im Geschehen merkt man auch ganz schnell, dass es nicht nur um das Anwenden von Scrum geht. Da sind plötzlich Themen wie Teamphasen, Führung oder andere Fragen am Tisch. Fragen wie zum Beispiel: wie macht man Teams erfolgreich oder was heißt eigentlich selbstorganisiert. Man entdeckt immer weitere interessante Facetten des agilen Arbeitens, die ganz oft mit einem Aha-Effekt verbunden sind.