Hallo zusammen,

die Frage richtet sich an Entwickler wie eurer Arbeitsablauf aussieht.

Früher habe ich als SAP-Entwickler Aufgaben bekommen, habe ich ggf. mit Anforderer zusammen gesetzt, das Thema besprochen und abgearbeitet. Ich war auch zum Teil bei Analyse und Anforderung-Erstellung dabei (macht es technisch so Sinn? gibt es bessere Möglichkeit?), Brainstorming, etc. Auch war ich bei komplexen technischen Themen wo ich als Entwickler mich gut auskenne (da selbst (teil)entwickelt und man den Prozess technisch sehr gut versteht) als Berater gefragt.

Jetzt ist alles anders. Wir arbeiten in Sprints, wo man Tickets bekommt die man abarbeiten sollte. Ich den Tickets in das Problem (im Normallfall) beschrieben und wie man es reproduzieren kann.
Keine Meetings außer mit Entwicklerteam (wo man seinen Stand täglich mitteilt), keine Konzeption, Analysetätigkeiten, Beratung , Support, etc.
Dazu läuft dieser Spring 2 Wochen - entweder es wird nicht alles fertig, da wenn man mit erster Aufgabe fertig ist, kaum Zeit bleibt zweite Aufgabe fertig zu machen wo Tester es erfolgreich testen können.
Oder wenn weniger Tickets freigegeben werden, wird man teilweise nach einer Woche fertig und hat kaum was in der zweiten Woche zu tun. Obwohl genug neue Tickets da sind, wartet man auf den nächsten Sprint.

1. Ich fühle mich nicht mehr als Softwareentwickler, sondern nur als Programmierer - meine Aufgaben sind nicht mehr so abwechsungsreich

2. Sprints erzeugen mir mehr Druck und Streß und sind mMn. weniger effizient. Der Punkt den TL hier posiviv hervorruft, ist dass Tester schneller testen würden, damit es bis zum bestimmten Zeitpunkt ins Produktivsysten transportiert wird.

3. Dazu sind wir jetzt für alles zuständig. Früher hat Enwickler die Tätigkeit übernommen, wo er sich fachlich und techschnich gut auskannte. Das hatte auch den Vorteil, dass man so nicht an falscher Stelle was einbaut obwohl eine bessere Lösung gibt. Das entscheiden jetzt aber auch Andere für uns. Wenn Tickets unklar formuliert sind und Abstimmung erforderlich sind, führen es alleine unsere 2 TL es durch (wir haben 2 Entwicklerteams, arbeiten aber zusammen). Ich fühle mich als erfahrener Enwickler wie ein Blödmann der downgegradet wurde und nicht fähig ist von Anfang bis Ende ein Thema zu übernehmen. Dazu viel Fremdsteuerung, mal muss ich warten bis ich anfange, obwohl ich besser meine Zeit einschätzten kann, wann und was ist erledige. Dann wird was weggenohmen, wo ich schon arbeite, obwohl auch hier Zeit gibt alles zu erledigen.

Was sagt ihr dazu?

Mein Mitgefühl für Frustration über schlecht eingeführte agile Prozesse, bei denen nur die Meetings und Rituale übernommen werden (Daily, Sprint Review, etc.), aber nicht die eigentlichen Prinzipien wie Iterationen, Feedbackzyklen oder technische Qualität.

SCRUM =
Schön
Chaotisch
Rennen
Und
Machen

Ich kenne das Problem als "DevSecOps"'ler auch... Beim jetzigen AG ist das deutlich besser, als beim Alten. Aber beim Alten war das Problem auch so. Da war "agil" eher, ich kann "agil" von Problem A zu B zu C zu D springen und fange dann bei A wieder an. Das hat man dann "Iterationsschleife" genannt :D Wie ich damit umgegangen bin? Ich hab den AG gewechselt :D

Ich arbeite in meiner liebsten Arbeitsweise: Es gibt ein grobes Themengebiet was implementiert werden soll, ich hab (fast) täglich spontane Meetings mit meinem Kunden der seinen Input gibt zu den umgesetzten Themen & neue Impulse gibt.

Wenn wir kein Budget mehr haben gibts einen neuen Auftrag.

Keine Sprints, kein Fake-Agiles handeln, kein Overhead. Ich bin zu 100% in der Arbeit.

Die Arbeit läuft iterativ bis der Kunde zufrieden ist.

Am 5.3.2026 um 12:11, hund555 hat gesagt:

Was sagt ihr dazu?

Wenn man Scrum falsch umsetzt, dann kommt halt murcS raus. ;)

Das scheint bei euch ja der Fall zu sein. Scrum hat nicht das Ziel, dem Entwicklern Scheuklappen aufzusetzen, sondern sich mit den Kunden, in einem Dialog, auszutauschen. Das Team ist dabei interdisziplinär. Der PO soll dabei auch nicht entscheiden, wie etwas umgesetzt werden soll. Dafür ist das Team zuständig. Der PO soll nur die Prioritäten anhand des sog. business value vorgeben. Also was bringt dem Unternehmen am meisten? Er entscheidet also das was, und nicht das wie.

Allerdings scheitert Scrum in den meisten Firmen, weil Scrum verlangt, dass man die Kontrolle den Teams gibt, aber gerade Manager werden dann gerne zum PO ernannt und die wollen natürlich die Kontrolle nicht abgeben und fangen dann mit Micromanagement an. Daily Meetings werden dann zu PO Status Meetings. Dazu sind sie aber nicht gedacht. Sie dienen für das Team, ihre tägliche Arbeit abzustimmen, wobei ich mich auch immer gefragt habe wozu? Ein Team kann sich auch auf kurzen Dienstwegen abstimmen. Ein Meeting ist dazu überhaupt nicht notwendig. Auch sind die Teams meist nicht interdisziplinär, sondern sind dann von anderen Teams abhängig und dadurch entsteht ein Wasserfall. Die Teams sind dann keine Scrum-Teams, sondern nur Komponenten-Teams, die Komponenten am Fließband produzieren, ohne zu wissen, für wen sie was produzieren und ob sie überhaupt das richtige produzieren.

Das Video zeigt sehr gut das Problem: Why "Scrum" Isn't Making Your Organization Agile: Harmful Misconceptions About Product Owner Role

Auch sind die Videos von Allen Holub sehr aufschlussreich (Er ist ein Scrum-Hasser): War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile

Auf Papier arbeiten wir auch nach Scrum, aber Scrum ist bei uns aus den gleichen Gründen gescheitert. Die Teams arbeiten inzwischen immer mehr nach Kanban. Wir haben auch keine interdisziplinären Teams, aber wir stimmen uns untereinander mit den anderen Teams ab, was wir brauchen und sie planen es dann bei sich ein. Die Sprints sind nahezu aufgelöst. Wir haben zwar noch Sprints, aber ob in zwei Wochen die Aufgaben fertig werden, oder in China fällt ein Sack Reis um. Das interessiert eh keinen, da wir eh nur alle drei Monate ein Release veröffentlichen. Das hat wieder eine ganze Menge Ruhe ins Unternehmen gebracht.

Bearbeitet vor 11 Stunden11 h von Whiz-zarD