Allgemein kommt es mir reichlich merkwürdig vor, Agilität zu verlangen und die Möglichkeit, einen sich selbst optimierenden Prozess zu implementieren, mit dem Hinweis auf mangelnde Vorgaben abzutun.

Bzgl. Sprint-Planung: Natürlich soll nicht alles genau durchentworfen werden. Was man jetzt nicht weiß, sollte man nicht festnageln. Auch das ist Agilität. Dazu braucht man natürlich eine gewisse Orientierung, wohin die Reise geht. Das verlangt Scrum. Auch die “dutzenden Anforderungen” kann ich nicht wirklich nachvollziehen: Bei uns passen selten mehr als fünf Stories in einen Sprint für 4-6 Leute. Es geht ja auch “nur” darum abzuschätzen, ob etwas in einen Sprint passt oder nicht. Das ist an einem halben Tag durchaus machbar. Für Dinge, die nicht sicher in einen Sprint passen, gibt es ja immer noch Timeboxen.

Auch die mangelhaft umgesetzte Rolle des Scrum Masters in Unternehmen ist kein Schwachpunkt von Scrum, sondern von diesen Unternehmen. Tut mir leid, aber hier wird ganz offensichtlich Ursache und Wirkung verwechselt.

Die Skalierung kann ich nicht beurteilen, aber auch hier finde ich: Scrum muss keine Antworten liefern. Die muss jedes Unternehmen für sich finden. Scrum kann in unterschiedlichen Unternehmen ganz unterschiedlich gelebt werden. Ist es wichtig vorzugeben, ob mehrere Teams synchron sprinten müssen? Was sollte Ziel einer solchen Vorgabe sein?

Ob Scrum scheitert oder nicht, liegt nicht an Scrum selbst. Sonst würde es niemand mehr einsetzen.

SCRUM ist ein Framework für Projektmanagement?
Als zertifizierter Projektmanager (IPMA) und SCRUM Master möchte ich dem wiedersprechen. SCRUM ist viel zu wenig beschrieben, als dass es als PM Framework dienen kann. Meiner Meinung nach.

Die “leichtgewichtige” Methodik ist keine Schwäche, sondern DAS Grundprinzip. Genau deshalb wurde SCRUM erfunden.

Bei der Beurteilung diverser Dinge (Aktien, Prozessmodelle, Autos usw.) tue ich mich immer schwer pauschal von Vor- und Nachteilen zu sprechen oder Stärken und Schwächen.

Alle diese Dinge haben Eigenschaften. Für den einen sind diese Eigenschaften von Vorteil, für den anderen von Nachteil. In der einen Situation sind diese Eigenschaften von Vorteil, für die andere Situation von Nachteil. Kommt drauf an…

Die Sprintdauer passt nicht? Pass es an! Das ist doch das Tolle an SCRUM. Also keine Schwäche. Andere Methoden erlauben das höchstmaß an Flexibilität nicht.

Daß das Design in den Planungs Meetings durchgeführt werden soll, höre ich zum ersten Mal. Design wird während der Sprints durchgeführt. Iterativ und nicht phasenweise.

Wenn der SCRUM Master nicht die Rolle einnimmt, für die er vorgesehen ist, wittere ich eine Schwäche in der Personalführung und der Ausbildung. Ist definitiv keine SCRUM Schwäche.

Bei wem SCRUM nicht funktioniert, sollte es nicht machen.
Nehmt doch XP oder RUP oder …

Natürlich kann man einen Nagel auch mit einem Schraubenzieher in die Wand schlagen. Es geht. Ein Hammer ist meist besser dafür geeignet.
“Wenn man nur einen Hammer hat, sehen alle Probleme aus, wie Nägel.”

Ich mache das so, dass ich in meinem Werkzeugkasten diverse Tools vorhalte und je nach Situation und Problemstellung versuche, das richtige Werkzeug auszuwählen.

Ich unterstelle, wenn Sie alle anderen Entwicklungsmodelle ansehen, werden Sie auch Schwachstellen finden!

@Joe: Hmm, Schade dass Dich offensichtlich die Satzkonstruktionen etwas vom Inhalt abgelenkt zu haben scheinen. Am Ende des Artikels steht es meiner Meinung nach ziemlich deutlich, dass ich noch meine konstruktiven Vorschläge einbringen werde. Zunächst war für mich eine Sachdiskussion über die Feststellung der Schwachpunkte im Fokus.

Wie dem auch sei, heute habe ich mich in einen konstruktiven Beitrag zum Thema Sprintdauer geübt:
http://www.gmbsg.com/scrum-die-bessere-sprintdauer/

Danke Dimi für den konstruktiven Beitrag, eine Eigenschaft, die ich trotz vieler Worte und komplexer Satzkonstruktionen im Original-Post leider völlig vermisse.

Es ist die Frage ob man von Scrum erwartet, dass alle Aktivitäten bis zu den kleinsten Detailen geregelt sind.

Laut Scrumt heisst es “Es soll ein Planungsmeeting geben, wo der Entwurf besprochen wird” es heisst aber nicht “Es ist verboten den Entwurf nachher wieder zu besprechen”.

Scrum ist für mich eine Set von Basisregeln, die aber auf keinen Fall statisch sind und nicht erweitert werden können, Stichwort “constant improvement”

Die Länge des Sprints sollte meiner Meinung nach für jedes Unternehmen individuell bestimmt werden. Sprints von einer Woche sind aber in einem Unternehmen wo z.B. das Deployment 2 Tage dauert nicht sehr sinnvoll.

Zu dem Punkt “Scrum Master” gebe ich dir voll Recht, er soll meiner Meining nach nicht als ein klassischer Projektmanager agieren. Das ist aber in Scrum auch nicht so beschrieben, also keine Schwachstelle von dem Prozess.

bzgl. Uncle Bob: Ich kenne den Post von UncleBob und habe mich, nach dem ich seine Thesen gelesen habe, nochmal für mich selbst reflektiert, ob ich Analogien für mich sehe. Im Endeffekt stimmt vieles mit den Thesen von UncleBob ein. Ich hatte den Literaturverweis zum Post von UncleBob nicht in den Artikel integriert, excusé moi. Ich habe es jetzt natürlich nachgetragen.

Ich persönlich sehe jedoch Dinge als Schwachpunkte, die UncleBob unerwähnt lässt:
1) Die Planung & Das Design
2) Der Scrum Master

Im Übrigen konzentriert sich UncleBob stark auf Agile / XP und geht nur partiell auf die Spezifika von Scrum ein.

Ich finde Deinen Beitrag mit dem Continuos Improvement sehr treffend – aus dieser Perspektive hatte ich daß noch nicht betrachtet