Scrum – Agile Software-Entwicklung

Der Begriff "Scrum" stammt ursprünglich aus dem Rugby-Sport und bedeutet "Gedränge". In der Software-Entwicklung bezeichnet Scrum ein agiles, intuitives und sehr wirkungsvolles Vorgehensmodell, welches von Ken Schwaber, Jeff Sutherland und Mike Beedle Anfang der 1990er Jahre entwickelt wurde.

Bei Scrum wird angenommen, dass Entwicklungsprozesse so komplex sind, dass sie sich weder in große abgeschlossene Phasen noch in einzelne Arbeitsschritte von Tagen oder Stunden pro Mitarbeiter planen lassen. Somit ist es produktiver, wenn sich ein Team in einem festen Rahmen selbst organisiert. Dieses selbstorganisierte Team übernimmt gemeinsam die Verantwortung für die Fertigstellung der gewählten Aufgabenpakete. Ein Management "von oben" sowie traditionelle Methoden zur Projektsteuerung, die die Zusammenarbeit im Team regeln, gibt es nicht.

Tönt verrückt? Ist es auch. Zumindest beim ersten Mal. Doch wer einmal mit Scrum gearbeitet hat, möchte es nicht mehr missen, so offensichtlich sind die Vorteile, so eindrücklich die Erfolge.

Scrum erfüllt als agile Methode die Bedingungen der agilen Software-Entwicklung, die 2001 im Agilen Manifest von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden:

Individuen und Interaktionen gelten mehr als Prozesse und Tools.
Funktionierende Programme gelten mehr als ausführliche Dokumentation.
Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen.
Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans.

Doch ganz ohne Struktur kommt auch Scum nicht aus. Doch sie ist so einfach, dass es garantiert jeder versteht.

Aller guten Dinge sind drei.

Bei Scrum gibt es nur drei Rollen. Mehr ist nicht nötig. Der Product Owner vertritt den Kunden und legt aus seiner Sicht die Ziele fest, welches das Team zusammen mit ihm erreichen soll. Zur Definition der Ziele dienen ihm meist User-Storys, also Beschreibungen der Funktionen, welche die Software haben soll. Er alleine setzt dabei die Prioritäten, also welche Features am wichtigsten sind. Die Storys werden im sogenannten Product-Backlog geführt, aus welchem das Team die Aufgaben für den jeweiligen Entwicklungszyklus ("Sprint") zusammenstellt.

Das Team besteht idealerweise aus 7±2 gleichberechtigten Personen. Es setzt sich aus allen für die Entwicklung benötigten Rollen zusammen, von Business-Analysten über Designer bis hin zu Entwicklern und Testern. Das Team hat daher auch die Aufgabe, als Kompetenzträger die Aufwände der einzelnen Backlog-Elemente zu schätzen und sich pro Sprint für die Umsetzung einer Auswahl zu verpflichten ("Committment"). Während des Sprints, welcher meist 4 Wochen dauert, gibt es keine Änderungen mehr an der Auswahl. Darüber wacht der Scrum Master.

Der Scrum Master hat die Aufgabe, die Rollen und Vorgänge zu überwachen. Er ist auch für die Transparenz zuständig während der gesamten Entwicklung aufrecht und unterstützt Team und Product Owner. Der Scrum Master ist dabei nicht Vorgesetzter des Teams, sondern steht in seinem Dienst und sorgt mit allen Mitteln dafür, dass das Team produktiv sein kann.

Manch altgedienter Consultant wird sich nun fragen: und wo ist der Projektleiter, der alles steuert? Nun: Den braucht es nicht mehr. Die Rollen wurden so definiert, dass das Team sich selbst organisieren muss. Der Product Owner gibt nicht vor, welches Teammitglied wann was tut und wer mit wem zusammenarbeitet. Bei Scrum gilt das Prinzip, dass das Team sich intuitiv selbst organisiert, und zu jeder Aufgabe dynamisch eine optimale innere Organisationsstruktur bildet, die sich viel schneller an die sich wandelnde Umgebungen anpasst als es in traditionellen, starren Organisationen möglich wäre.

Ob das in der Praxis funktioniert? Und wie.

Wie isst man einen Elefanten?

Genau: in Stücken ;-). Soll heissen: unlösbar grosse Aufgaben bewältigt man am besten häppchenweise. Scrum ist daher komplett als iteratives Vorgehen aufgebaut. Zentrales Element des Entwicklungszyklus von Scrum ist der Sprint, welcher die Umsetzung einer Iteration bezeichnet und ca. 30 Tage dauert.

Vor dem Sprint werden die Produkt-Anforderungen des Kunden im Product Backlog gesammelt. Auch technische und administrative Aufgaben werden dort aufgenommen. Das Product Backlog muss dabei nicht vollständig sein, ist aber immer nach Wichtigkeit priorisiert.

Im Sprint-Planning wählt das Team dann aus den Product Backlog Items diejenigen Elemente, welche im kommenden Sprint umgesetzt werden können. Dabei müssen immer zuerst die Storys realisiert werden, welche vom Product Owner mit der höchsten Priorität klassifiziert wurden, sofern sie als realistisch machbar eingeschätzt werden können. Basis der Auswahl ist die Aufwand-Schätzung, welche das Team selbst erstellt. Ziel eines Sprints ist immer lauffähige, getestete und inkrementell verbesserte Software.

An jedem Tag eines Sprints findet ein kurzes Daily Scrum-Meeting statt, welches dem Informationsaustausch des Teams untereinander dient. Dabei erzählt jedes Teammitglied, was es seit dem letzten Meeting getan hat, was es bis zum nächsten tut und ob dabei neue Hindernisse aufgetreten sind. Diese müssen vom Scrum Master bearbeitet werden.

Nach einem Sprint wird das Sprint-Ergebnis einem Review durch den Product Owner unterzogen. Dazu wird das Ergebnis des Sprints als laufende Software vorgeführt. Der Product Owner prüft dabei, ob das Ergebnis seinen Anforderungen entspricht und nimmt ggf. entsprechende Umpriorisierungen vor. Das Team verarbeitet zudem die Arbeit und die Ereignisse des Sprints in einer eigenen Retrospektive, um sich zukünftig verbessern zu können.

Und was bringts?

Der CIO einer namhaften Firma soll einmal gesagt haben: "Früher erhielt ich nach anderthalb Jahren Entwicklung teure Software die nicht das tat, was wir wollten. Mit Scrum erhalten wir die unbrauchbare Software bereits nach einem Monat."

Etwas weniger sarkastisch formuliert liegen die Vorteile der agilen Vorgehensweise auf der Hand: durch die kurzen Entwicklungszyklen wird das Resultat für Kunde und Entwickler viel schneller greifbar, was ein deutlich besseres Steuern und Umpriorisieren ermöglicht. Somit kann schneller auf ein bewegtes Umfeld reagiert werden, Fehler werden schneller hochgespült. Und die Produktivität eines Teams ist um ein vielfaches höher als mit einer traditionellen Wasserfall-Methode.

Für Kunden sind diese Vorteile ein Segen, da sie Ihnen die Möglichkeiten zur Beeinflussung ermöglichen, welche mit traditioneller Entwicklung nicht möglich sind. Aber auch Analysten, Designer, Entwickler und Tester profitieren deutlich, da die Kommunikation untereinander massiv verbessert wird, was das Verständnis zwischen den Disziplinen fördert.

Doch diese Erfolge sind nur möglich, wenn ein eingespieltes Team die Vorgaben des Frameworks befolgt und die Rollen sauber getrennt werden. Dann kann Scrum seine ganze Kraft ausspielen. Und wer einmal damit gearbeitet hat, wird zustimmen: es macht tierisch Spass!

Quellen: ScrumAlliance, Wikipedia, et al.