alle Punkte die Du genannt hast können passieren. Ich frage mich nur, wie Ihr in der Retrospektive darauf reagiert. Auch bei uns hat es ähnliche Situationen wie “5 Leute an einem Feature sind zu viel”. Es vergeht aber keine Retro bei der wir aus solchen Erfahrungen keine Konsequenzen ziehen würden.

Das ist doch genau der Punkt. Das Team macht keine Überstunden aus Rücksicht auf den Projekterfolg. Denn wir wissen alle, wohin Überstunden führen: Übermüdung, steigende Fehlerzahl, sinkende Motivation, steigende Kosten, Verzögerung.

Knackpunkt ist, dass einfach falsch priorisiert wurde und daher der Termin nicht eingehalten wird. Ob dem Kunden fälschlicherweise zuviel versprochene wurde oder zu viel verkauft wurde ist dabei nebensächlich. :)

bin froh endlich auch mal von Leuten zu lesen, die Scrum durchaus auch kritische Seiten abgewinnen können. Wenn man sonst im Web von Scrum liest, ist das fast auschließlich positiv.
Bei uns in der Firma wird seit ca. 2,5 Jahren nach Scrum gearbeitet. Vor der Scrum Ära war ich für bestimmte Module verantwortlich. Man kannte sich in seinen Sachen sehr gut aus und konnte schnell etwas neu entwickeln. Ich habe eine bestimmtes Feature “begleitet” von der Formulierung der Anforderungen bis hin zur Doku schreiben am Ende. Mir hat es Spaß gemacht.
Seitdem wir Scrum eingeführt haben, habe ich das latente Gefühl, das wir im Grunde genommen, neue Features langsamer entwickeln. Also, das wir insgesamt stark an Effizienz verloren haben. Scrum setzt ja irgendwie voraus, das die Teammitglieder sich in allen Themen Bereichen gleich gut auskennen. Da wir jedoch sehr unterschiedliche Module verwalten müssen, hat das in den letzten Jahren eher dazu geführt, das man von vielen Dingen wenig weiß. In meinem “ehemaligen” Modul bin ich noch immer der Experte. Zweimal habe ich Teammitgliedern eine Einführung gegeben, damit das Wissen weiter gestreut wird und sie mir helfen können. Die Einarbeitung hat Zeit gekostet. Dann jedoch wurde wieder über längere Zeit kein Item von meinem ehemaligen Modul eingeplant. Das führte dazu, das meine Teamkollegen, das kürzlich erworbene Wissen wieder vergessen haben!

Im letzten Sprint hatten wir ein großes Item eingeplant, das wir mit 5 Teammitgliedern bearbeiten sollten. Leider hat man dabei vergessen auch zu bedenken, daß man nicht jede Arbeit endlos parallelisieren kann. Es war also ein Riesenproblem alle 5 Leute sinnvoll zu beschäftigen. Hätte man die Aufgabe mit 2 Personen abgearbeitet, wäre es vermutlich genauso schnell gewesen. Man kann eben nicht die Fenster einbauen, bevor die Wände stehen.

Ein Riesenproblem ist auch, uns zu einigen. Früher hat man als Modulverantwortlicher technische Entscheidungen selbst treffen können. Wenn man das Bedürfnis hatte, hat man sich mit Kollegen ausgetauscht, von denen man geglaubt hat, das sie einem hinreichend gut beraten können. Dabei sind auch immer ganz gute Entscheidungen rausgekommen. Jetzt ist es so, daß wir manchmal selbst über Kleinigkeiten endlos diskutieren, ohne das oftmals ein greifbares Ergebnis raus kommt.

Fazit: Nach 2,5 Jahren Scrum bin ich ziemlich demotiviert. Es ist für mich nur noch ein Job zum Geld verdienen geworden. Der Spaß ist dabei verloren gegangen.

Das entspricht wohl nicht der schönen neuen Welt, die Scrum schaffen soll!

Du sprichst hier wirklich die richtigen Dinge an. Auch mit deinem wichtigen Hinweis auf die Kosten.

Manchmal frage ich mich, ob es nicht effektiver wäre, einfach noch ein oder zwei Entwickler einzustellen, als die ganze Firma nach Scrum umzubauen. Irgendwo habe ich den Verdacht, dass die in der Entwicklung gewonnene Produktivität von den anderen Abteilungen bezahlt wird. Das kann der PO sein, der jetzt eine Verantwortung trägt, die ein Mensch alleine kaum tragen kann. Der Überstunden macht um pünktlich zum Meeting das priorisierte Backlock vorweisen zu können. Das können die Supporter oder Verkäufer sein, die die Kunden bis zum nächsten Sprint vertrösten müssen, denn eine Zeitschätzung zwischendurch gibt’s halt nicht….

Und… der mise Deal des Managements: So zugespitzt hatte ich das noch nicht gelesen. Aber recht hast du.

Ich bin ganz klar von Scrum überzeugt – allerdings darf man vor den ganzen Herausforderungen nicht die Augen verschließen und verlangen, dass sich die ganze Organisation oder die Kunden gefälligst ändern sollen.

In manchen Konstellationen macht Scrum auch keinen Sinn. Vielleicht kann noch der eine oder andere Ansatz übernommen werden, aber dies ist im Einzelfall zu prüfen.

Zu den Arbeitszeiten:
Ich bin der Meinung, dass hier eine gute Arbeitszeitregelung hilft. Diese erlaubt dann problemlos in einer Periode etwas mehr zu arbeiten und in einer anderen die Mehrarbeit wieder abzubummeln. Damit gibt es Flexibilität ohne erhebliche Mehrkosten (was bei echten Überstunden der Fall sein kann).

Diesem Ansatz steht Scrum nicht im Weg! Wenn beispielsweise Urlaubstage in die Planung der Velocity (dere Grundlage die Team-Verfügbarkeit sein sollte!!!!) einfliessen, dann können auch freie Ausgleichstage einbezogen werden. Nicht Scrum ist schuld sondern die Arbeitszeitregelung bzw. das Management, welches wohl mehr Entwicklungskapazität benötigt als vorhanden ist.