Um das nachzuvollziehen, müssen wir einen kurzen Ausflug in die Zeit vor Scrum wagen, in die Zeit vor den agilen Ansätzen. Entwicklungsprozesse in großen Firmen und Projekten waren bis ins Kleinste ausgeklügelt. Aufgaben, Tätigkeitsbereiche und Verantwortlichkeiten gegen einander abgegrenzt. Wie eine gut geölte große Maschine sollen solche Firmensysteme funktionieren, wo jedes hochspezialisierte Zahnrädchen Teil daran hat, dass am Schluss das gewünschte Ergebnis herauskommt – zum Beispiel das neue Softwaresystem. In einer Art Taylorismus waren (und sind) solche Firmen durchstrukturiert, durchprozessiert und durchdefiniert: Abteilung A macht nur Konzeption, Abteilung B setzt um und Abteilung C testet das Ergebnis. Die drei Abteilungen reden möglichst wenig miteinander, dafür gibt es ja definierte Prozesse. Wie sich aber immer mehr herausstellte, ist das kein immer gut funktionierender Ansatz, wenn man Software entwickeln will.

Das hat mehrere Gründe. Zunächst ist es.- die Erfahrung macht fast jeder - selten, dass ein Kunde zu Beginn eines Projekts genau weiß, was er will. Auch der Kunde lernt im Verlauf des Projekts. Hat man nach klassischem „Wasserfall-Modell“ geplant, also erst die komplette Konzeption abgeschlossen, um dann mit der Umsetzung zu beginnen, muss man bei Änderungen im Grunde zurück auf Los – noch mal konzipieren, noch mal neu anfangen mit der Umsetzung.

Auch die strikte Trennung der Zuständigkeiten bewährt sich nicht. Sie sorgt für eine Einengung des einzelnen auf einen Teilaspekt, für das große Ganze ist der Projektmanager zuständig, der aber hat natürlich keine Zeit, mit jedem einzelnen zu reden. Zu Beginn versuchen alle, genau festzulegen, worum es gehen soll, um sich abzusichern. Am Ende wundert man sich dann oft, dass etwas ganz anderes herauskommt, als gedacht und gewünscht.

Um der Verknöcherung der Softwareindustrie zu begegnen, proklamierten Ken Schwaber, Jeff Sutherland (die Scrum-Begründer) und andere 2001 schließlich das Agile Manifest:

1. Individuen und Interaktionen über Prozesse und Tools

2. Funktionierende Programme über erschöpfende Dokumentation

3. Zusammenarbeit mit dem Kunden über Vertragsverhandlung

4. Reagieren auf Veränderung über das Befolgen eines Plans

Das Ziel war, die Verantwortlichkeit für den kreativen Prozess, den Softwareentwicklung darstellt, wieder an die Entwickler zurückzugeben. Und der Tatsache Rechnung zu tragen, dass nun einmal nie zu Beginn wirklich genau feststeht, was am Ende des Projekts das optimale Ergebnis sein wird.Scrum ist dabei eine Methodik, die schon in den Achtzigern geschaffen wurde und ursprünglich aus der Produktentwicklung stammt (vgl. Nonaka und Takeushi im Harvard Business Review, 1986). Der Begriff Scrum wurde aus dem Rugby entlehnt, er bedeutet „Gedränge“ und beschreibt eine Situation, in der sich alle Spieler in einer Spielunterbrechung kurz zusammenstellen. Das Miteinander, das regelmäßige Zusammenkommen als Institution, ist eines der Leitmotive in Scrum. Im so genannten Daily Scrum, also täglichen Scrum-Meeting, treffen alle zusammen und besprechen kurz, was anliegt, was stört usw. Dabei ist ein so genannter Scrum-Master dafür zuständig, dass der Prozess optimal abläuft, und der so genannte Product Owner dafür, dass etwas Verwertbares entsteht.

Scrum macht als Methode weniger Vorgaben als zum Beispiel Extreme Programming oder gar nicht-agile Systeme wie der Rational Unified Process (RUP). Man spricht deshalb bei Scrum auch von einem Framework, weil es vor allem Werte und Leitmotive vorgibt, und nicht feste Verfahrensregeln.

In Scrum gibt es an Vorgaben im Grunde nur drei Rollen: Den Scrum-Master, den Product Owner (PO) und das Team. Eine weitere Vorgabe ist die Einteilung des Projektablaufs in feste Zeitabschnitte, sogenannte Sprints, also Arbeitszeiträume von (meist) ein bis vier Wochen. Und schließlich sind einige sogenannte Artefakte vorschrieben, wie das Product Backlog, eine Liste aller zu erledigenden Aufgaben (Tasks) und das Sprint-Backlog, in dem Tasks aus dem Product Backlog ausgewählt werden, die dann in einem Sprint abgearbeitet werden sollen.

Das Scrum-Team setzt sich aus dem Scrum-Master, dem PO und dem Team zusammen. Die Nomenklatur ist zunächst etwas verwirrend, das Team, also die Entwickler, die tatsächlich programmieren, stellen eine der drei Rollen dar, und alle drei Rollen zusammen ergeben das Scrum-Team. Der Scrum-Masters ist für das Einhalten der Scrum-Regeln und Werte zuständig, er muss dafür sorgen, dass das Team optimal arbeiten kann. Bei so genannten Impediments, also Faktoren, die die optimale Arbeit behindern, kümmert er sich um die Beseitigung oder Verbesserung. Egal, ob es darum geht, das Team gegen Managemententscheidungen zu verteidigen, fehlende Mittel zu organisieren oder dem Team zu helfen, sich besser zu organisieren, der Scrum-Master ist die Seele des Scrum-Prozesses.

Der Product Owner dagegen vertritt die Perspektive des Kunden. Er hat die Produkt-Vision und ist dafür zuständig, dass bei jedem Sprint ein Ergebnis mit Geschäftswert zustande kommt. Wie die Tasks, die er vorgibt, umgesetzt werden, zum Beispiel „Man kann auf der Web-Plattform nach Restaurants in einer Stadt suchen“, ist ihm egal. Darüber kann und soll das Team ganz allein entscheiden. Er muss nur die Aufgaben formulieren und priorisieren. Das Team wählt dann, basierend auf den priorisierten Tasks, die der PO im Backlog festgehalten hat, selbstständig die Aufgaben aus, die konkret in einem Arbeitsabschnitt, dem Sprint, angegangen werden.  

Am Ende jedes Sprints erfolgt ein Sprint Review, in dem das Ergebnis dem PO und/oder Kunden präsentiert wird, und eine Sprint-Retrospektive, in der der Prozess im Sprint selbst analysiert wird: Ist alles gut verlaufen? Was war noch verbesserungswürdig? Das kann von einfachen Faktoren wir fehlenden Post-It-Blöcken bis hin zu grundsätzlichen Überlegungen gehen, wie sich das Team besser organisieren und erfolgreicher arbeiten könnte.

Das Regelwerk von Scrum ist damit weitgehend, wenn auch nicht in allen Details, beschrieben. Als schlankes, agiles Framework schreibt Scrum zum Beispiel nicht vor, wie programmiert werden soll. Extreme Programming gibt zum Beispiel Pair Programming vor, bei dem Programmierer in Paaren arbeiten, sowie testgetriebene Entwicklung (Test-driven Development, TDD), also die Programmierung von Unit-Tests, um das Funktionieren des Codes stets zu gewährleisten. Scrum dagegen schreibt keine solchen Regeln vor.

Scrum schreibt auch nicht vor, wie das Product Backlog, das der PO führt, auszusehen hat. Es hat sich als praktisch erwiesen, die Aufgaben in so genannte Requirements zu fassen, also etwa „Auf der Webseite kann man nach Restaurants suchen“, und diese Requirements herunterzubrechen in so genannte User Stories. Eine User Story folgt dabei dann meist dem Schema „Als <Benutzerrolle> will ich <Wunsch>, um <Nutzen>“, also zum Beispiel „Als eingeloggter User will ich Restaurants nach Sorte der Küche sortieren können, um schneller das Richtige zu finden“. Oft werden solche Tasks oder User Stories auf einem White Board veranschaulicht, vor dem dann der Daily Scrum stattfindet. So hat jeder schnell einen Überblick, was ansteht und wo die Probleme liegen. Aber auch hier macht Scrum keine Vorgaben – wer ein Scrum Board hilfreich findet, benutzt es, gerade verteilte und verstreute Teams aber müssen sich natürlich mit Online-basierten Lösungen organisieren.

Im Alltag des Projektgeschäfts ist die Durchführung, geschweige denn die Einführung von Scrum natürlich nicht ganz so einfach, wie die o. g. Darstellung das glauben machen könnte. Auf Seiten des Managements mag es Widerstände geben, weil man dem Entwickler nun plötzlich nicht mehr sagen darf „Du machst X bis zum Datum Y“ – er sucht sich seine Arbeit selbst. Auf Seiten des Teams mag es zunächst ungewohnt sein, sich allein zu organisieren und völlige Freiheit in der Durchführung zu haben, dafür aber die Verantwortung für das Endprodukt ganz und gar selbst zu übernehmen und als gesamtes Team für die Qualität der Ergebnisse gradezustehen (Stichwort: Collective Ownership). Und auf Seiten des Kunden schließlich mag die (hier etwas überspitzte) Botschaft „Wir legen los, bevor wir alles genau wissen, Sie kriegen in vier Wochen etwas, wir wissen aber noch nicht was“ für Irritation sorgen.

Es ist deshalb Aufgabe des Scrum-Masters und des Product Owners, die Qualität des Prozesses und der Ergebnisse zu steuern und dem Team dabei zu helfen, optimale Ergebnisse zu erzielen. Weil das nicht immer einfach ist, tut man gut daran, für den Start auf die Erfahrung und Expertise ausgewiesener Scrum-Experten zurückzugreifen. Um die Qualität auf dem Markt sicherzustellen, bieten die Scrum Alliance und Scrum.org deshalb Zertifizierungen an, so dass sich kompetente Berater besser finden lassen.

Wer also das Wagnis eines Umdenkens weg vom klassischen Projektmanagement nicht scheut, sollte in Betracht ziehen, Scrum als agile Methodik zu testen. Nicht umsonst nutzen viele große, namhafte Firmen und Projekte Scrum und versprechen sich davon mit Erfolg höhere Effizienz, schnellere Output-Zyklen, verbesserte Produktivität und nicht zuletzt einen befriedigenderen, reicheren Arbeitsalltag für alle Beteiligten.

eStrategy-Redaktion

Sacha Storz