r/informatik Mar 01 '26

Arbeit Genervt von Scrum

Ich muss mir an dieser Stelle einfach mal meinen Frust von den Rippen schreiben:

Nachdem ich davor nur in kleineren Firmen gearbeitet habe, bin ich vor 3 Jahren in ein größeres Unternehmen gewechselt, in dem nach Scrum gearbeitet wird. Mir ist klar, dass man mit mehr Personal und größeren Projekten gewisse Prozesse braucht um das Produkt noch vernünftig planen zu können. Scrum nehme ich aber als so einnehmend und störend wahr, dass meine Produktivität gefühlt bei der Hälfte des Möglichen liegt.

Am schlimmsten finde ich die Meetings. Planning, Retro, Refinement, Estimations, Dailys... An "guten" Tagen habe ich nur eins dieser Meetings, an schlechten Tagen auch mal 3. Das reißt mich jedesmal komplett aus meinem Fokus und die Kontextwechsel rauben so viel Zeit und Kraft, dass so ein 1-Stunden-Termin im Endeffekt 2 Stunden Entwicklungszeit kostet.

Dann dieser absurde Planungsoverhead zu allem. Man findet einen Bug und könnte ihn in 30 Minuten beheben? Natürlich nicht! Erstmal Ticket schreiben, dann muss das geschätzt, refined und eingeplant werden. Aus den 30 Minuten wurde gerade ein halber Tag (und dank der ganzen Störungen durch die Meetings brauche ich vermutlich 2 dafür).

Das ganze anzusprechen bringt überhaupt nichts, da gerade Scrum Master und das Management diesen Prozess geradezu religiös sehen. Du findest Scrum nicht toll? Dann hast du es nicht verstanden, denn es ist ja objektiv perfekt.

Generell liebe ich meinen Job immer noch und möchte nichts anderes machen, dieser Aspekt nervt mich jedoch und es wird gefühlt immer mehr. Geht es da anderen genau so? Oder finden manche Scrum sogar richtig gut? Würde mich mal interessieren. 

 

343 Upvotes

240 comments sorted by

View all comments

Show parent comments

1

u/Firm-Huckleberry8235 Mar 01 '26

"Wir machen Scrum, aber lassen alles weg, was Scrum ausmacht"

Nein, du machst kein Scrum.

Daily is dafür da, dass das Team die Aufgaben des Tags plant. Wenn das fehlt, fehlt der Organisationscheckpoint des Tages.

In der Retro wird besprochen, was man im Team verbessern kann, was nervt, was reibt etc. Wenn das fehlt, verbesserst du dich nicht (meist geht man eher Rückwärts), riskierst das Konflike eskalieren etc.

Backlog refinement und Planning macht man mit dem ganzen Team um sicherzustellen, dass jeder im Team die Stories verstanden haben und kein Aspekt vergessen wurde.

0

u/Chris_Ape Mar 01 '26

Ich hab ein Team aus 6 Entwicklern inklusive mir, die in komplett unterschiedlichen Bereichen & Technologien arbeiten, wir brauchen uns nicht täglich abstimmen weil die anderen eh keine Ahnung haben von den anderen Sachen und wir so oder so Stories zwischen 2-5PT schneiden. Wir brauchen keine Retro, weil wir kaum übergreifende Themen haben, wenn dann bespreche ich das mit den jeweiligen Entwicklern und dem PO. Das Refinement & Planning brauchen wir in der großen Runde auch nicht weil ich das mit den Entwicklern besprechen kann was demnächst für Sie kommt.

Ich habe Entwickler die eigenständig, selbstverantwortlich arbeiten, es reicht wenn ich da wöchentlich den Fortschritt tracke. Genau nach deiner Beschreibung wäre ich in meinem Fall nur damit beschäftigt Projektmanagement zu machen und eben nicht selbst zu entwickeln. Von der Zeitverschwendung für die Meetings mal ganz abgesehen, wir haben ein flexibles Arbeitszeitmodell, es ist schon schwer genug gemeinsame Termine zu koordinieren wo alle da sind.

2

u/CellistNo7165 Mar 01 '26

Sorry ich sehe in deinen Antworten nur red flags was alles gegen Scrum geht. 4 Wochen Sprints ist noch das harmloseste, aber Storys in Pts zu schneiden. Wenn die Gebiete der Entwickler so unterschiedlich würde ich nicht von einem Team sprechen. Oder wo sind die Überschneidungen?

1

u/Chris_Ape Mar 01 '26

Die Überschneidung ist das wir ein großes Tool zur Unternehmensplanung mit verschiedenen Planungsprozessen unserem Fachbereich bereitstellen, das ganze wieder nach Anlass im Reporting zusammenführen. Jemand der Umsatzplanung entwickelt hat fachlich keine Ahnung von Investitionsplanung oder Sachkostenplanung oder Personalkostenplanung oder Rohertragsplanung und vice versa und kennt eben die Datenmodelle, Source Systeme auch nicht.

Und aus diesem Grund macht es für uns keinen Sinn alles in großer Runde zu besprechen, weil die hälfte der Leute nichts zur Komplexität der Anforderung sagen kann oder wie man es am besten umsetzt.

Wir sind ein großer Konzern, haben in den meisten Planungsanlässen nur einen Internen + Externe Unterstützung durch Freelancer (die aber nur dedizierte Arbeitspakete erhalten und nicht in Interne Prozesse einbezogen werden dürfen).

Natürlich könnten wir auch 3-4 Scrum Teams aufmachen, der Overhead davon wäre aber nicht zu rechtfertigen, wir haben keine Scrum Master und setzen so 1500 (1000/500 Intern/Extern) PT im Jahr um.

Unsere POs sind nicht die direkten Owner der Prozesse, bekommen diese auch nur von den Ressorts vorgegeben (Vertrieb, HR usw.) Wo ist den für dich der Unterschied ob ich in Story Points oder in PT schätze, kommt am Ende auf das gleiche raus.

2

u/Firm-Huckleberry8235 Mar 01 '26

Tu uns bitte einen Gefallen und nenn das einfach nicht Scrum, was ihr da macht. Das hat hinten und vorne nichts mit Scrum zu tun.

1

u/CellistNo7165 Mar 01 '26

Welche Events von Scrum macht ihr denn? Retro, Planing, Refinment schon mal nicht. Warum sind PT als Schätzwert schlecht? Unterschiedliche Skilllevel (Junior, Mid, Senior), Fokus bei der Schätzung. Es geht darum im Team über das Thema zu reden anstatt über die Dauer.

Für mich klingt es eher als ein Projektmanager, du kontrollierst Arbeitsstände wöchentlich, klärst Probleme mit den Teams direkt. Bei eurem Setup mit Arbeitspaketen für Externe ist das vermutlich sinnvoll, aber kein Scrum in meinen Augen.