vielen Dank für den Kommentar.
Scrum ist interdisziplinär wenn man es auf Softwareentwicklung beschränkt – hier stimme ich zu. Ein Produkt oder ein Service besteht aber nicht nur aus Software. Das wird meist vergessen.

Beste Grüße
Jürgen

viele Grüße
JP

Ich möchte Scrum durchaus keine Absage erteilen, sondern deutlich machen, wann ein Einsatz sinnvoll ist.

Pflege der Systeme:

Die Dokumentation über Testergebnisse kann ein Entwickler sicherlich gut nachvollziehen. Meines Erachtens kann dies aber dazu führen, dass der “rote Faden” auf der fachlichen Seite verloren geht. Viele der Probleme, die ich mit Scrum (aber auch mit anderen Methoden ) hatte, lassen sich darauf zurückführen (wenn man einmal ein System prüfen muss, das seit Jahren in Betrieb ist, versteht man möglicherweise eher, was ich meine). Naturgemäß finden bei Scrum häufig inhaltliche Änderungen statt. Gerade der intensive Kontakt zwischen Entwicklern und der Fachseite eröffnet Möglichkeiten, die man zuvor nicht immer wahrnimmt.

Es erfordert einen hohe Disziplin diese Änderungen immer in fachlichen Dokumentationen nachzuhalten, weswegen dies oft unterbleibt. Ich meine, dass die Gefahr dazu bei Scrum noch höher ist als sonst schon, weil es eigentlich der Regelfall sein dürfte, dass fachliche Texte mehrfach überarbeitet werden müssen.

Die technische Dokumentation ist wichtig, wenn aber nur diese existiert ist die fachliche Seite bei der Pflege der Systeme immer auf Entwickler angewiesen, die diese übersetzt. Hier habe ich schlechte Erfahrungen gemacht, denn Entwickler haben meist anderes zu tun.

Kreativität und disruptive Innovation:

Im Prinzip bin ich bei Dir, genau darum geht es in dem Artikel von Hirotaka Takeuchi, Ikujiro Nonaka . Nach meinem Wissen beschränkt sich der Anteil verschiedener Disziplinen bei Scrum aber auf einen Product Owner und verschiedenen technische Ausrichtungen. Nach meinem Dafürhalten geht dies viel weniger weit, als im Artikel vorgeschlagen. Dort waren im Entwicklungsteam auch fachlich unterschiedlichste Disziplinen vertreten, oder nicht?

danke für diesen Artikel. Es ist gut, Scrum nicht immer und überall blind anwenden zu wollen, nur weil es gerade Mode ist . Allerdings kann ich zwei Deiner drei genannten Fälle für eine Absage an Scrum als Prozeß nicht nachvollziehen:

“Komplexe Sachverhate”
Hier bin ich bei Dir. In solchen Fällen ist eine Trennung zwischen fachlicher und technischer Lösung sinnvoll. Ich sehe diesen Fall vor allem zu Beginn komplexer Projekte. Im späteren Verlauf kann man evtl. zu Scrum übergehen.

“Pflege der Systeme”
Die Dokumentation im Scrum findet vor allem über Tests (am besten BDD) statt. Werden diese Tests gewissenhaft erstellt – nicht nur als Alibi-Tests -, so stellen sie eine sehr gute und verständliche Dokumentation dar. Jeder Entwickler (auch ohne Scrum-Erfahrung) versteht diese Dokumentation und kann sie verwenden.

“Kreativität und disruptive Innovation”
In meiner Auffassung sind interdisziplinäre Teams gerade ein Kernbestandteil von Scrum – es gibt explizit keine Trennung nach fachlichen Gesichtspunkten. Das Einkalkulieren von Fehlschlägen ist ebenfalls Kern der agilen Philosophie, in der man für das “Unplanbare plant” – ein Stichwort: Rapid Prototyping. Ich persönlich sehe Scrum sogar besonders geeignet nicht nur für die Entwicklung, sondern für die grundlegende Organisation von Unternehmen, um eben disruptive Innovationen zu unterstützen. Gerade bei disruptiven Innovationen geht es um Neues und Unvorhergesehenes, dem mit agilen Strukturen super begegnet werden kann – Stichwort: Agile Enterprise.

Falls Du Anmerkungen zu meinen Kommentaren hast, würd ich das Thema gern weiter diskutieren. Denn auch ich bin stetig auf der Suche nach Verbesserungen von Entwicklungsprozessen .

Viele Grüße aus dem Zelt,

Matthias