Wie ist Scrum entstanden?

Software-Projekte haben sehr viele Beteiligte, die sehr viele verschiedenen Sachen wollen. Weiterhin hat die Software viele Aspekte und Ausprägungen. Es ist wirklich komplex. Und diese Komplexität gilt es zu meistern.

Der Lösungsansatz von Scrum wäre die Komplexität der Software mit folgenden Punkten zu reduzieren:

Zeiträume überschaubar machen
Zunächst einmal werden die Zeiträume überschaubar gemacht. Es gibt nicht mehr den Anspruch, jetzt schon zu wissen, was in einem Jahr ist. Es werden stattdessen kleine Zyklen von zwei Wochen, drei Wochen oder 4 Wochen vorgenommen, die überschaubar sind. Die Ergebnisse dafür werden gleich richtig fertiggestellt.

Ständiger Kundenfeedback
Ein weiterer Schritt um Komplexität zu reduzieren, ist das Einholen von Feedback. Der Kunde wird also frühzeitig ins Boot geholt und nicht erst am Schluss, wenn das Projekt schon abgeschlossen ist. Es wird immer wieder beim Kunden nachgefragt, ob es das ist, was er sich gewünscht hat.

Effektive Kommunikation
Das Einholen von ständigem Kundenfeedback erfordert eine effektive Kommunikation. Man spricht miteinander, anstatt sich Anwaltsbriefe zu schreiben.

Teilergebnisse regelmäßig liefern
Die Teilergebnisse werden regelmäßig geliefert. Es wird also nicht nur einmal am Schluss geliefert, wenn die Software komplett umgesetzt ist, sondern immer wieder kleine abgeschlossene Elemente oder Funktionen. So hat man auch die Möglichkeit Fehler oder falsche Umsetzungen schneller zu beseitigen.

Änderungen möglich machen
Änderungen, die es immer wieder gibt und geben wird, sind im Gegensatz zu linearen Vorgehensmodellen, jetzt leichter und schneller möglich umzusetzen. Bei Scrum geht man davon aus, dass es Änderungen geben wird, da es bei Software-Projekten üblich ist. Bei linearen Vorgehensmodellen wie beim Wasserfallmodell ist man der Meinung, dass man zuerst Packet 1, dann Packet 2, dann Packet 3 komplett fertigstellt. Wenn man an Packet 3 arbeitet, gibt es einfach keine Änderungen bei Packet 2 oder Packet 1 mehr. In der Realität sieht das aber leider anders aus.

Transparent sein
Bei Scrum weiß man genau, wo das Projekt steht, da alle Projektstände transparent sind. Alle Projektbeteiligten wissen immer, was gut läuft und was schlecht läuft.

Zusammenfassend bedeutet es, dass man agil sein muss. Scrum ist eine agile Methode um Software zu entwickeln. Die Komplexitätsverringerung ist das wichtigste Rezept dafür.

 

Ursprünge von Scrum

Der Name Scrum ist ein Begriff aus dem Rugby. Auf Deutsch bedeutet Scrum „Rangeln“ oder „Gedränge“. Es die Situation im Rugby, wenn die Teams die Schulter senken, die Köpfe zusammenstecken und miteinander rangeln. Das ist der Grundbaustein von Scrum. Die Spieler bzw. die Teammitglieder werden immer wieder ihre Köpfe zusammenstecken und den nächsten Zug besprechen.

Rugby Scrum

 

Ikujiro Nonaka und Hirotaka Takeuchi greifen in ihrem 1986 erschienen Artikel „The New Product Development Game“ den Begriff Scrum auf, um einen neuartigen Produktentwicklungsprozess zu beschreiben. Basierend auf der Idee von Nonaka und Takeuchi beschrieben die Autoren Peter DeGrace und Leslie Hulet-Stahl 1991 in ihrem Buch „Wicked Problems, Righteous Soutions – A Catalogue of Modern Software Engineering Paradigms“, wie man für die Entwicklung von Software statt eines wasserfallartigen Produktentwicklungsprozesses einen „All in one“-Ansatz wählen könnte.

Namen wie Projektleiter, Teamleiter und Chef-Architekt gibt es bei Scrum nicht mehr. Diese Begriffe kommen bei Scrum bewusst nicht mehr vor, um dem Management zu signalisieren, das etwas Neues kommt.

 

Prinzipien agiler Softwareentwicklung

Im Folgenden werden die vier Prinzipien der agilen Softwareentwicklung erläutert, die die Grundlage von Scrum bilden:

Prozess und Werkzeuge vs. Menschen und Interaktion
Es ist wichtig einen Prozess und Werkzeuge zu haben, aber letztendlich kommt es auf die Menschen an, die diese Werkzeuge und Prozesse nutzen. Es ist also wichtiger, dass die Menschen gut miteinander agieren.

Umfassende Dokumentation vs. funktionierende Software
Software-Projekte müssen natürlich dokumentiert werden. Die Anforderungen müssen im Vorfeld dokumentiert werden und die Software-Architektur muss dokumentiert werden. Funktionierte Software ist aber wichtiger als eine vollständige Dokumentation, da der Kunden kein Stapel voller Papier bestellt hat, sondern eine Software.

Verträge vs. vertrauensvolle Zusammenarbeit
Es werden natürlich Verträge mit den Details benötigt. Aber wäre es nicht noch schöner, wenn man den Vertrag nicht bräuchte, weil wir vor Gericht stehen, sondern ein Software-Projekt vor einen Gerichttermin schon fertig hätten.

Festhalten am Ursprungsplan vs. Umgang mit neuen Erkenntnissen und Änderungen
Es ist gut, wenn man ein Plan hat. Aber man sollte nicht blind auf den Ursprungsplan festhalten. Falls neue Erkenntnisse oder Änderungen gewonnen werden, sollte der Ursprungsplan änderbar sein.