Scrum: Die nächste Generation des Projektmanagements?

von Tom am 11. Juli 2009

Agile Softwareentwicklung ist in aller Munde, und Scrum scheint eine wesentliche Rolle zu spielen, die dem klassischen Projektmanagement den Rang abzulaufen „droht“, wenn man so in die Web 2.0-Welt hineinhorcht. Tatsächlich aber ist Scrum wie auch das früher recht populäre Spiralmodell nicht für alle Softwareprojekte geeignet. Der Scrum-Ansatz ist außerdem eine Eigenheit der Softwareentwicklung, denn für den Bau einer Brücke oder eines Flugzeugs kann man sich Scrum als Ansatz kaum vorstellen. Aber warum eigentlich nicht?

Schauen wir uns Scrum genauer an. Die darin üblichen Rollen sind der Product Owner (im Projektmanagement der Sponsor), das Team (im Projektmanagement das Projektteam) und der Scrum Master (im Projektmanagement dann wahrscheinlich am ehesten der Projektmanager). Der grosse Unterschied ist, dass die Entwickler direkt mit dem Product Owner sprechen und das Team selbst bestimmt, wie es arbeitet, dieses also nicht von dem Projektmanagement auferlegt bekommt. Dass es einem Softwareprojekt zum Vorteil gereichen kann, wenn der Kunde von Anfang an miteinbezogen wird, das ist keine neue und erst mit Scrum verstandene Information. Und dass das Team die Vorgehensweise bestimmt, auch das sollte in einem klassischen Unternehmen nicht unmöglich sein.

Warum dann überhaupt ein anderer Ansatz? Weil die Scrum-Begründer der Ansicht sind, dass die Produktion von mancher Software zu komplex ist, als dass sie sich in einzelne Arbeitspakete splitten und planen lässt. So ganz unrecht haben die Scrum-Befürworter damit nicht, denn die Zukunft ist nunmal ungewiss, und bei manchen Projekten hat man so gut wie keine Ahnung, ob und wenn ja, wie genau etwas umgesetzt werden soll (eventuell ist hier der Fehler aber bereits in der Projektinitialisierung zu sehen, wo man Verfahren hätte testen können?).

Wie sähe es denn nun aus, wenn man ein Flugzeug bauen wollte mit Scrum? Das Team käme täglich zum Daily Scrum vorbei, maximal 15 Minuten, und würde sich befragen, wodurch man gerade aufgehalten wird und womit man fertig geworden ist. Offensichtlich könnten hier einige Team-Mitglieder noch gar nicht mitarbeiten, denn um das Flugzeug zu bauen, benötigt man erst mal ein Design, das sich auf das Material, die technischen Anforderungen usw niederschlägt. Erst wenn dieses vorhanden ist, kann die Materialbeschaffung angegangen werden. Und erst wenn das Material da ist, kann das Flugzeug gebaut werden. Klingt nach einem typischen Wasserfallprozess, der sich dadurch ergibt, dass jemand erst anfangen kann, wenn jemand anders etwas abgeschlossen hat. Ähnlich sieht es mit dem Bau einer Brücke auch aus.

Heisst das nun, dass Scrum für andere Bereiche als Software absolut sinnlos wäre? Nein, denn tatsächlich ist Scrum sogar durch einen anderen Bereich inspiriert: Die Schlanke Produktion, die bei japanischen Autobauern eingeführt wurde und die zum Beispiel die teilautonome Gruppenarbeit hervorgebracht hat. Dadurch, dass eine Gruppe notwendige Kompetenzen für Entscheidungen bekommen hatte und dadurch autonom arbeiten konnte, wurden Arbeitskräfte wesentlich flexibler und mit Hinblick auf die Wertschöpfung eingeteilt. Dies ist ein nicht zu unterschätzender Faktor. Doch eine Sache stimmt hier nicht. Bei der Autoproduktion handelt es sich gar nicht um ein Projekt! Denn nur das erste Auto, das neu entworfen und gebaut wird, entstammt einem wirklichen Projekt, der Serienwagen danach entstammt der operationalen Arbeit. Natürlich kann in so einem Kontext wieder flexibler agiert werden, schließlich ist das Endprodukt und die Schritte dorthin bekannt.

Würde man das Projekt „Neues Auto entwerfen und bauen“ nun mit dem Scrum-Ansatz angehen, so würde sich wahrscheinlich kein Autohersteller damit zufrieden geben, wenn man ihm sagte, dass dies ein so komplexes Unterfangen sei, dass man nix genaues sagen könne, wann es denn fertig wäre. Schließlich gibt es Erfahrungen (Lessons Learned), und gut ausgebildete Projektmanager haben gelernt, auch in unbekanntem Terrain voller Unsicherheiten den richtigen Weg einzuschlagen und pünktlich am Ziel anzukommen.

Nein, Scrum soll hier nicht niedergeredet werden. Scrum ist ein toller Ansatz, und er macht für manche Projekte absolut Sinn. Aber eben nicht für jedes. Beim Projektmanagement kommt es darauf an, immer das richtige Werkzeug für die Aufgabe zu wählen, und manchmal könnte es Scrum sein, ein anderes Mal auch ein klassisches Wasserfall-Modell.

{ 1 Trackback }

Agiles Projektmanagement mit Scrum « comSysto.com
16. Juni 2010 um 17:46 Uhr

{ 3 Kommentare… unten lesen oder hinzufügen }

surfguard 12. Juli 2009 um 10:34 Uhr

Hallo Tom,

ein lesenswerter Artikel, der, obwohl er doch ein bisschen danach riecht, Scrum mal nicht nur als Fricklermethode hinstellt.

Zwei Dinge möchte ich dennoch gerne klarstellen.

Zum ersten: Die Methode Scrum wurde auf der Basis von Beobachtungen bei der Entwicklung besonders innovativer eletronischer Konsumgüter (Kameras, Kopierer etc.) entwickelt. Scrum kommt also keineswegs aus der IT-Welt, sondern aus der Konsumgüterwelt der 80er Jahre: http://apln-richmond.pbworks.com/f/New+New+Prod+Devel+Game.pdf

Das alleine sollte schon klarmachen, dass die Prinzipien von Scrum sehr wohl zur Herstellung physikalischer Artefakte geeignet sind, auch wenn das nicht die Hauptdomäne ist.

Aber ein wirklich schlimmes Gerücht über Scrum verbreitet dein Artikel wie viele andere: Scrum-Projekte zeichnen sich keineswegs dadurch aus, dass man nicht sagen kann oder (der Unterstellung nach) will, wann sie enden. Zu Beginn eines Scrum-Projekts kann man eine genauso gute oder schlechte Schätzung über die Gesamtdauer des Projekts machen wie vor einem Wasserfall-Projekt, wann es enden wird. Und man sollte das auch tun. Scrum liefert während des Projekts dann aber über die Iterationsergebnisse die Möglichkeit, die Gesamtschätzung zu konkretisieren. Und das ist eine Möglichkeit, die in einem Wasserfallprojekt nicht einmal existiert.

Warum? Weil im Wasserfall immer Tätigkeiten in der Zukunft liegen, die man in dieser Art im Projekt noch nicht durchgeführt hat, während die Iterationen von Scrum untereinander relativ ähnlich sind. Ich kann also aus der Menge von Produktfeatures, die ich in Iteration 1-4 hergestellt habe, auf die Menge der Iterationen 5-n schließen, weil mindestens die Arbeitsweise und die beteiligten Personen gleich sind und immer durch alle Produktschichten hindurch implementiert wird. Aus der Dauer der Wasserfall-Konzeption kann ich dagegen nur sehr indirekt auf die Dauer der Implementierung schließen. Aus der Dauer der Front-End-Konzeption nur sehr indirekt auf die Dauer der Workflow-Konzeption.

Tatsächlich ist es sogar so, dass „Accountability“ (also etwa: der Willen, sich an Versprechen messen zu lassen) in Scrum auf jeder Ebene und Zeitskala eingefordert wird, bis hinunter auf jeden einzelnen Tag. Beim Wasserfall ist die Schicksalsergebenheit der Beteiligten viel größer. Meine Kunden fühlten sich in Scrum-Projekten deshalb immer besser als in Wasserfall-Projekten. (Und die Ergebnisse waren auch besser.)

Tom 12. Juli 2009 um 12:42 Uhr

Danke erst einmal für den langen und vor allem wichtigen Kommentar sowie für den Verweis auf den Harvard Business Review-Artikel, sehr interessant!

Ich freue mich, wenn es bei Deinen Kunden mit Scrum sehr gut funktioniert hat, und eventuell haben meine bisher eher nicht so guten Erfahrungen damit zu tun, dass die Scrum nutzenden Entwickler weniger Programmiererfahrung hatten und sich deswegen komplett verschätzten. Läge man völlig falsch mit der Aussage, dass Scrum nur bei Teams mit erfahrenen Entwicklern belastbare Zeitabschätzungen erlaubt?

Mein Nachhaken ist damit begründet, dass für mich hier logisch etwas hakt. In dem klassischen Projektmanagement-Modell erstellt man zunächst die Work Breakdown-Structure, wo man das Projekt aufteilt in kleine Einheiten, die ein einzelner Entwickler in einem überschaubaren Zeitrahmen bewältigen kann. Wie lange er dafür braucht, schätzt der Entwickler selber und muss sich daher zunächst damit auseinandersetzen, was er genau tun muss, um das Ziel zu erreichen. Ich frage meistens dann auch noch nach einem optimistischen, einem realen und einem pessimistischen Wert und nutze die PERT-Formel. Damit habe ich sehr gute Ergebnisse erzielt. In Deiner Aussage wird anhand der Ergebnisse einer Iteration auf die Länge folgender Iterationen geschlossen, aber wer weiß denn, ob sich in einer Iteration ein Feature befindet, das vielleicht doch sehr viel aufwändiger ist?

Ich sehe Scrum übrigens keinesfalls als Frickler-Ansatz, und eine solche Duftmarke im Artikel war nicht beabsichtigt. Was mich stört ist allein die Aussage, dass das alles neu sei, denn viele Punkte in Scrum sollten auch bei anderen Modellen längst befolgt werden, sei es die Kundeneinbindung, die freie Wahl des Entwicklungsansatzes, aber auch der Launch einer Minimal-Version und darauf aufbauende Releases. So gesehen habe ich auch schon Scrum genutzt, nur dass der Durchlauf des Wasserfall-Modells eine Iteration war 🙂

surfguard 12. Juli 2009 um 15:21 Uhr

Die Fragen, die du stellst, sind die geradezu klassischen, die Scrum-Propaganden wie mir immer gestellt werden. Aber im einzelnen.

„Läge man völlig falsch mit der Aussage, dass Scrum nur bei Teams mit erfahrenen Entwicklern belastbare Zeitabschätzungen erlaubt?“
Nein. Und man läge nicht völlig falsch mit der Aussage, dass jedes beliebige Projektvorgehen nur bei Teams mit erfahrenen Entwicklern belastbare Zeitaussagen erlaubt. Jeder Mensch kann nur aufgrund von Erfahrung schätzen. Wenn er die nicht hat, wird seine Schätzung schlechter, in Scrum wie im Wasserfall. Einziger Unterschied: Scrum ermöglicht es, schneller zu lernen, nämlich über Iterationen hinweg, manchmal sogar schon über Tage, aber nicht erst über ganze Projekte.

„In dem klassischen Projektmanagement-Modell erstellt man zunächst die Work Breakdown-Structure, wo man das Projekt aufteilt in kleine Einheiten, die ein einzelner Entwickler in einem überschaubaren Zeitrahmen bewältigen kann. Wie lange er dafür braucht, schätzt der Entwickler selber und muss sich daher zunächst damit auseinandersetzen, was er genau tun muss, um das Ziel zu erreichen.“
Das ist in Scrum fast exakt genauso. Zwei Unterschiede: Es gibt keine Work-Breakdown-Structure, die in Scrum durch das Product Backlog und das Scrum Board ersetzt wird. Und ToDos werden nicht für das ganze Projekt vorab erstellt, sondern nur für die anstehende Iteration, und ihre Zuordnung zu Personen wird erst endgültig festgelegt, wenn die Aufgabe konkret ansteht.

„In Deiner Aussage wird anhand der Ergebnisse einer Iteration auf die Länge folgender Iterationen geschlossen…“
Die Iteration ist eine Feedbackschleife. Das heißt sie ersetzt nicht die Schätzung, sondern sie ermöglicht ihre Optimierung während der Projektlaufzeit. Schätzungen gibt es also auch Scrum.

„…aber wer weiß denn, ob sich in einer Iteration ein Feature befindet, das vielleicht doch sehr viel aufwändiger ist?“
Wenn du meinst, dass sich ein Feature während der Iteration aufwändiger herausstellt als gedacht: Das kann passieren, aber das kann auch im Wasserfall passieren.
Wenn du irgendwie den Eindruck hast, in Scrum würden nicht alle Features vorab geschätzt: Dieser Eindruck ist falsch. Selbstverständlich müssen alle Einträge des Product Backlogs geschätzt sein, typischerweise in Punkten, um mindestens ihre relative Größe zu kennen. Es wird ja nicht immer die gleiche Zahl von Features in eine Iteration gepackt, sondern die gleiche Zahl von Punkten (bspw. Story Points).

„mich stört ist allein die Aussage, dass das alles neu sei…“
Das sagt kein ernstzunehmender Scrumverteidiger. Aber Scrum folgt völlig anderen Paradigmen als Wasserfall, sprich, es rückt ganz andere Kompetenzen und Verpflichtungnen in den Vordergrund.

„denn viele Punkte in Scrum sollten auch bei anderen Modellen längst befolgt werden…“
‚Sollten‘ ist richtig. Dass sie es aber oft nicht werden, das liegt eben daran, dass andere Methoden diese Punkte nicht fordern, sondern dass der PM sie noch daneben stellen muss.

„…sei es die Kundeneinbindung…“
Ein zentraler Punkt! Zweiwöchentliche Abnahmen vorführbarer Produktteile sind einfach ein unschlagbares Werkzeug zur Kundeneinbindung. Wie viel Konzeptpräsentationen habe ich im Leben gemacht und entweder gelangweilte Gesichter oder oberschlaue Bemerkungen gehört, mit denen ein goldenes Schleifchen um ein hinreichend konzipiertes Feature gebunden werden sollte? Sowas passiert in einer Sprint-Demo mit einem „potentially shippable product“ einfach nicht.

„die freie Wahl des Entwicklungsansatzes“
Das ist nun tatsächlich kein besonderer Punkt der Scrum-Philosophie. Allerdings würde es schwierig werden, in einem Wasserfall-Projekt Extreme Programming einzusetzen.

„aber auch der Launch einer Minimal-Version und darauf aufbauende Releases.“
Da widerspreche ich wie bei der Kundeneinbindung. Der Kunde versucht im Wasserfall immer, in der Konzeptphase soviel Leistung wie möglich in eine Minimalversion zu drücken. Wenn du aber nach zwei Monaten die vierte funktionierende Produktversion hast (natürlich nciht mit allen Features), und dem Kunden klarmachst, dass er diese Version binnen sehr kurzer Zeit in Betrieb nehmen könnte, dann fällt ihm eine positive Antwort einfach viel leichter.

Und ganz zum Schluss auch noch dein letzter Punkt: „So gesehen habe ich auch schon Scrum genutzt, nur dass der Durchlauf des Wasserfall-Modells eine Iteration war.“
Ich gehe davon aus, dass dir klar ist, dass eine Iteration eben kein kleiner Wasserfall ist? Wenn innerhalb eines Scrum-„Sprints“ Konzept, Design, IT und Tester alle gleichzeitig loslaufen, dann hast du in einer zweiwöchigen Iteration in der Regel nach einem oder zwei Tagen das erste funktionierende Feature. In einem zweiwöchigen Wasserfall hättest du das aber erst nach ca. einer Woche.

Wer Iterationen zu kleinen Wasserfällen macht, vergibt sich sehr viele Vorteil agiler Entwicklung.

Vorheriger Post:

Nächster Post: