Einleitung

Wiederholt haben wir in der jüngeren Vergangenheit in Projekten mitgewirkt, in denen unter Verwendung der SCRUM Methodik Software entwickelt wird. Doch was sich erst mal wie eine gute Idee anhört, entpuppt sich vielerorts als ein mehr oder weniger große Farce.

Aus nüchterner Perspektive betrachtet stellt SCRUM den Versuch dar, einige Probleme klassischer Softwareentwicklungmethoden zu lösen. Zum Beispiel wird das Schreiben umfangreicher Spezifikationen zu Gunsten kürzerer Entwicklungszyklen aufgegeben. Kürzere Entwicklungszyklen erzeugen eine besser Sichtbarkeit von Teilergebnissen. Nicht mehr das große Ganze in all seiner Komplexität steht bei SCRUM im Vordergrund, sondern die iterative Erbringung von Kundennutzen. Deshalb ist ein Kunden oder Zwischenkunde auch meistens Teil des SCRUM Teams.

Beschreibung der Methode

SCRUM-Entwicklungsteams haben typischerweise 7-10 Mitglieder von denen ein Teammitglied die Rolle des SCRUM Master und ein weiteres Mitglied die Rolle des Product Owner inne haben. Der SCRUM Master ist als „primus inter pares“ zu verstehen. Er steht in keinem hierarchischen Weisungsverhältnis zum Rest des Teams, sondern hat eine Problemlöserfunktion innerhalb des Teams inne. Der Product Owner fungiert in der Role eines fiktiven (oder auch echten) Kunden. Daher wird die SCRUM Methode auch gerne dort genutzt, wo die Entwickler mit den End- oder Zwischenkunden zusammen Software entwickeln sollen und die Erbringung eines Kundennutzen im Vordergrund steht.

Die Entwicklungszyklen in SCRUM heißen Sprints. Sie sind typischerweise 3 Tage bis zu 4 Wochen lang und sind Iterationen an deren Ende eine stabile und funktionsfähige Version des zu entwickelnden Produkts steht. Idealerweise werden die Länge der Sprints und die Inhaber der Rollen zu Beginn eine Projekts festgelegt und während des Projekts nur bei vorliegen zwingender Gründe gewechselt. Ein solcher liegt jedoch NICHT vor, wenn die Sprintziele einmal oder widerholt nicht erreicht worden sind.

Weitere wichtige methodische Elemente von SCRUM sind eine Liste unbedingt umzusetzender Eigenschaften eine Produkts. Diese Liste nennt sich Work Backlog. Zu Beginn eines jeden Sprints gibt es das Sprint Planning. Dieses Meeting dient zunächst dazu die Tasks, die im nächsten Sprint umgesetzt werden sollen, vom Work Backlog auszuwählen und zu bewerten. Die Aufwandsbewertung erfolgt im ganzen SCRUM Team. Danach werden die Tasks vom Product Owner priorisiert. Anschließend werden alle Tasks, die in der insgesamt zur Verfügung stehenden Entwicklungsszeit entwickelt werden können auf die einzelnen Teammitglieder aufgeteilt.

Hierbei ist darauf zu achten, dass alle Teammitglieder eine etwa gleiche Auslastung während des Sprint haben. Jeden Tag findet ein kurzes Meeting im Team statt, an welchem der Product Owner jedoch nicht teilnimmt. Im Rahmen dieses Meetings hat jedes Teammitglied typischerweise 3 Fragen zu beantworten:

1. Was habe ich gestern getan ?
2. Was werde ich heute tun ?
3. Welche Probleme sind aufgetreten / Was hat mich behindert ?

Die Probleme sind im Anschluss an jedes „Daily Scrum“ möglichst zeitnah vom SCRUM Master zu beseitigen bzw. abzustellen. Er ist daher gewissermaßen der Winston Wolf des SCRUM Teams und sorgt mit seiner Arbeit dafür, dass das Team möglichst reibungsarm arbeiten kann. Am Ende des Sprints findet das „Review Meeting“ statt. In diesem Meeting nimmt der Product Owner wiederum teil und es werden die Arbeitsergebnisse des letzten Sprints besprochen. Typischerweise findet deshalb auch nach dem Review Meeting das „Sprint Planning“ für den nächsten Iterationszyklus statt.

Eine der wichtigsten Regeln des Sprint ist, dass as Sprintziel nur dann erreicht ist, wenn ALLE geplanten Arbeitspakete im Rahmen des Sprint abgearbeitet wurden.
Einen Teilerfolg gibt es also bei Anwendung der SCRUM Methode nicht. Dies impliziert, dass ebenfalls bereits zu Projektbeginn eine sehr klare Definition für die Frage, wann etwas wirklich erledigt ist, erfolgen muss. Ken Schwaber, einer der Erfinder von SCRUM nennt dies „The definition of done“. Wer unter den geneigten Lesern dieses Blogs sicht nicht vorstellen kann, dass das Wort „erledigt“ verschiedentlich interpretierbar ist, dem seien die drei Youtube Videos vom Ken Schwaber selbst persönlich ans Herz gelegt.

Kritische Diskussion

SCRUM ist eine sehr durchdachte Methode. Mich persönlich fasziniert immer wieder, wie häufig es amerikanischen Wissenschaftlern und Pratikern gelingt, komplexe Sachverhalte in überschaubare Methoden herunterzubrechen. Neben der SCRUM Methode ist zum Beispiel die Portfolioanalyse ein sehr effektive Methode, um komplizierte, multidimensionale Sachverhalte in einfache, nachvollziehbare Visualisierungen zu transformieren. SCRUM führt jedoch nicht ohne Einsatz zu guten oder besseren Ergebnissen als die klassischen Entwicklungsmethoden wie z.B. Wasserfall oder das V-Modell.

Eine akribische Beachtung der methodischen Grundsätze (Daily Scrum, Scrum Review Meeting), Einhaltung der Rollenzuordnungen (SCRUM Master, Product Owner) und eine klare a-priori Festlegung der „definition of done“ sind wesentliche Grundsätze der Methode, die gelebt und verstanden werden müssen. Zwar setzt SCRUM Agilität durch kleine, überschaubare Teams, kürzere Entwicklungszyklen und Kundenpartizipation methodisch um, ob am Ende aber eine gutes und für das Team und den Kunden zufriedenstellendes Ergebnis steht, hängt wesentlich von der Einhaltung des Methodenfundaments ab. Jede Abweichung von der radikalen Vereinfachung des Entwicklungsprozesses nach SCRUM birgt die Gefahr am Ende mit schlechteren und vor allem teureren Ergebnissen konfrontiert zu werden, als sie klassische Methoden hervorgebracht hätten.

Auch wenn SCRUM das Lernen und Problemlösen im Team und damit das Gruppenziel in den Vordergrund stellt, ist es absolut notwendig ein SCRUM Team so zu besetzen, dass die Chance des Niveausausgleichs grundsätzlich gegeben ist bzw. das notwendige Spezialkenntnisse durch entsprechende Kompetenzträger abgedeckt werden. Teammitglieder die nachhaltig die Schätzwerte hinsichtlich des Zeitaufwandes für die Ihnen zugeteilten Aufgaben überreizen sind langfristig demotivierend und eine Belastung für den Rest des Teams sowie eine Gefahr für den Projekterfolg. SCRUM nur als Modewort zu verstehen und zu einer leeren Hülle verkommen zu lassen, weil die grundlegenden Regeln keine Beachtung mehr finden, ist jedenfalls keine gute Idee.

Interessieren auch Sie sich für Projektmanagement? Dann informieren Sie sich doch einfach hier. Oder Sie melden Sie sich bei uns, entweder telefonisch unter +49 4105 135 03 99, per Mail an [email]sales@initos.com[/email] oder über unser Kontaktformular.