“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.

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

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.)