Genau so muss man agile / hypride Projektarbeit angehen. Immer angepasst an das jeweilige Team und an die jeweilige Aufgabe. Und auch während der Projektlaufzeit kann man reagieren und Scrum-Elemente verändern. Ich bin Scrum Master und handhabe das seit einigen ahren so auch in der Mechanischen Produktentwicklung mit den Entwicklungsteams.
Sehr guter Artikel, den sich andere zu Herzen nehmen sollten!

Zu dem Artikel fällt mir so viel ein, dass es ein eigener Artikel würde. Ich beschränke mich mal auf die wichtigsten Punkte.

1. Ich bin dabei, dass Dogmatismus schädlich sein kann und meist falsch ist. Andererseits erlebe ich in der Praxis sehr oft, dass gerade diejenigen Vorgaben von Methoden missachtet oder angepasst werden, die eine echte Veränderung in der Arbeitsweise verursachen würden - also besonders wirkungsvoll wären. Wenn man in solchen Fällen darauf hinweist, dass diese missachtete Vorgabe besser befolgt werden sollte, wird man gerne mal als Dogmatiker beschimpft.

"Dogmatiker" ist nämlich auch der Kampfbegriff derjenigen, die jede Veränderungen vermeiden wollen. Craig Larman hat wunderbar beschrieben, wie das funktioniert: https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Org…

2. "Unseren Scrum" gibt es nicht. Man muss nichts von Scrum machen, man kann alles anders machen und damit erfolgreich sein. Aber es ist dann nicht mehr Scrum. Der Scrum Guide ist eindeutig: "Scrum exists only in its entirety". Was mich wundert ist: Warum wollen so viele Menschen von Scrum abweichen, es dann aber dennoch Scrum nennen? Nennen Sie es doch einfach "unser agiles (oder hybrides) Vorgehen". Aber nein, es heißt dann "unser Scrum", und wenn es nicht funktioniert, dann "funktioniert Scrum nicht". Die eigenen Anpassungen können ja schließlich unmöglich zum Misserfolg beigetragen haben... (siehe Punkt 1)

3. Wirklich schmunzeln musste ich bei dem Satz "Kein Unternehmer würde doch Geld ausgeben, ohne dafür einen Gegenwert zu bekommen." Wenn ich sehe, was Unternehmer alles machen und dafür viel Geld ausgeben, ohne auch nur zu überprüfen, ob sie dafür einen angemessenen Gegenwert bekommen, kann ich dieses Argument einfach nicht ernst nehmen. Warum sollte eigentlich irgendein Unternehmen jemals pleite gehen, wenn Unternehmer ja nur Dinge tun, für die sie einen Gegenwert bekommen? Weil Unternehmer eben manchmal doch den größten Unfug machen.

Ihr Artikel hat mir aus der Seele gesprochen. Aus meiner Erfahrung kann ich jeden Gedanken von Ihnen unterschreiben! Danke dafür, Herr Eberspächer, dass Sie die "hybride Welt" so auf den Punkt gebracht haben!

Ich habe mich gefragt, was den "Dogmatismus" auslöst? Wieso wird aus einem Modell, dass Orientierung bieten möchte, ein dogmatisches Vorgehensmodell? Worin liegt der der Nutzen zu dogmatisieren?
Ein paar Fragen zu Hypothesen-Ansätzen:
Vielleicht ist es eine vermeindliche Sicherheit durch ein vorgeschriebenes Prozesskorsett?
Möglicherweise ist zum Lernen einer Vorgehnsweise es erst einmal gut, eine enge Prozessführung zu haben?
Oder ist es mangelnde Erfahrung oder fehlende Souveränität der Projektbeteiligten?
Vielleicht ist auch die noch weitverbreitete tayloristische Arbeitskultur in Organisationen die Grundlage, wo Kontrolle eine wichtige Rolle spielt?
Darüber würde ich gerne eine Diskussion führen.

Im Übrigen hat die Helena-Studie ergeben, dass Software auf der ganzen Welt "hybrid" entwicklet wird. https://helenastudy.wordpress.com/
Das, was Sinn macht, wird in der Realität umgesetzt - ganz pragmatisch!
Die Forscher hat dies überrascht.
Mich nicht!

Hallo Herr Eberspächer,
ich hatte auch mal diese Einstellung, inzwischen denke ich anders. Vor 10 Jahren bin ich mit Pragmatismus und agilen Ansätzen in der Automobilindustrie und im Maschinenbau aufgebrochen. Scrum mochte ich damals nicht besonders gerne, es schien nur schwer zu passen. Inzwischen bin ich der Meinung, dass Scrum einfach nur so konsequent ist, dass es schmerzt. Scrum ist keine Religion, sondern ein seit 30 Jahren in Millionen Organisationen gereiftes Rahmenwerk. Meine Erfahrung: Alle Punkte in Organisationen, die sich mit Scrum reiben, sind Dysfunktionalitäten in den Organisationen und keine Defizite von Scrum. Scrum ist die schonungsloseste Problemsuchmaschine in Organisationen, die ich kenne.
Beispiel: Die von Ihnen beschrieben Inkompatibilität mit Projekten rührt unter anderem daher, dass Projekte ein denkbar schlechtes Vehikel sind um in einer komlexen Umgebung zu bestehen. Auch bei den erwähnten Aspekten Risikomanagement, Phasen- oder Release-Planung sehe ich keine Probleme mit Scrum, die Diskussion würde jedoch den Rahmen hier sprengen.
Pragmatismus und Hybride Ansätze sind für mich Anzeichen, dass die Organsisationen kein Interesse daran haben sich zu grundlegend verändern und zur Höchstleistung zu kommen. Das finde ich auch nicht schlimm, manche sind in Umgebungen in denen Agilität bisher nicht notwendig ist. Andere möchten schlicht so ähnlich weitermachen wie bisher. Das ist ja auch alles OK. Ich mache auch weniger Sport als ich könnte. Und solange die Wettbewerber ähnlich unterwegs sind, gibt es keine Probleme.

Nur in einem Punkt möchte ich meine persönliche Meinung und Erfahrung noch einmal klar herausstellen:
"Hybride pragmatische Ansätzen" als Übergangszone sind das eine. Auf keinen Fall sind solche Ansätze jedoch der Zielzustand oder gar "das Beste aus zwei Welten" wie es manche nennen, es sei denn, die Organisation ist mit sich selbst zufrieden.

Viele Grüße
Joachim Pfeffer

PS: zur Verortung: Bin weder Fundamentalist noch Missionar. Nur ein Organisationsoptimierer. Und wenn ich was besseres als Scrum finde, bin ich offen. ;)

Winston Royce hat vor 50 Jahren in seinem berühmten Paper 'Managing the Development of Large Software Systems' eine Menge intelligenter Dinge gesagt, unter anderem zur originalen Treppendarstellung OHNE Rücksprünge: "I believe in this concept but the implementation described above is risky and invites failure"!
Und etwas hat er ausdrücklich nicht gesagt: er hat den Begriff 'Waterfall' nie (n-i-e) erwähnt. Den Begriff 'Waterfall' bzw. 'Wasserfall' im Zusammenhang mit Projektmanagement müssen deutlich weniger intelligente Wesen später dazu erfunden haben.
Wie sagt man so schön: Lesen bildet! (Und verstehen noch vel mehr!)

„Mittlerweile gibt es seit einigen Jahren festgeschriebene, agile Vorgehensmodelle. Diese entstanden auf Basis des Agilen Manifests (Beck et al., 2001).“

Nach meinen Kenntnissen basiert das Agile Manifest auf den Erfahrungen, die die Verfasser des Manifests mit ihren neu entwickelten Methodiken (ich verwende hier absichtlich nicht den Begriff „Vorgehensmodelle“ – das sind sie nicht) gemacht haben. Und so wurde mit dem Agilen Manifest der Begriff „Agile“ erstmals hierfür verwendet. Die Methodiken jedoch, die zuvor als „lightweight methods“ bekannt waren, sind bereits früher entstanden (z.B. erste Publikation zu Scrum - noch „SCRUM“ geschrieben - stammt aus 1995; zu XP aus 1999).

Fazit: Das Agile Manifest entstand aus Erfahrungen mit agilen Methoden und nicht umgekehrt.