Scrum ist ein phänomenologischer Ansatz, die Probleme sitzen immer tiefer!

So z.B. neigen Java/C# Projekte wegen des Klassensystems (Vererbung / Encapsulation) grundsätzlich zur "Verfestigung" der inneren Strukturen. Da tendieren bereits übergroße Klassen dazu, sich noch mehr Funktionalität einzuverleiben.

Sog. "Bottom-Up" Programmiersprachen (Traits, Mixins) haben solche Probleme grundsätzlich nicht.

Als Softwarearchitekt hole ich mir z.B. mit dem Sourcecode Visualisierungs - Toolkit Roassal die Klassen ran, analysiere deren inneren Abhängigkeiten und kann lange im Vorhinein bereits sicher vorhersagen, wann die innere Reibung ansteigen, der Kommunikationsoverhead explodieren wird. Und die Meetings, wo sich die Leute nur noch gegenseitig die Zeit stehlen, immer länger dauern werden.

Und ab da wir's erfahrungsgemäß teuer, ab da wird mächtig Geld verbrannt. Da kann auch jeder Sprinten, so schnell er will. Wenn jeder in eine andere Richtung sprintet, kommt nix dabei heraus! Die Technischen Schulden wachsen ins Unermessliche, obwohl jeder einzelne wirklich sein Bestes gibt, gegeben hat:

"Alle arbeiten zielgerichtet vorwärts, das Projekt bewegt sich dennoch rückwärts"

Und ab da explodiert dann auch erfahrungsgemäß die Kündigungsrate. Da hilft dann auch kein Scrum mehr, eher im Gegenteil. Durch die Einführung von Scrum werden Hoffnungen geweckt, die nicht erfüllbar sind. Zusätzlich rausgeschmissenes Geld.

Metaprozesse, wie Scrum, starten nur völlig verzweifelte Manager, und zwar erfahrungsgemäß immer dann, wenn's bereits zu spät ist.