Ein sehr guter Artikel, aber...

[TheBodo]

... leider geht er aus meiner Sicht doch etwas am Problem vorbei.
Und das Problem lautet: Agilität ist die Antwort, und nicht die Frage!

Was bedeutet das? Ganz häufig nehme ich war, dass man die Frage
stellt: "Entwickeln wir agil?". Wenn die Antwort dann "ja" lautet, folgt
die Aussage: "Dann brauchen wir das ja nicht.". Leider handelt es sich
bei "das" in diesem Kontext häufig um Dinge wir Testkonzepte, eine
Architekturübersicht oder Dokumentation. Teilweise sogar um Tests!
Kurzum: Um Pläne.

Ja, Agilität ist die prozessuale Antwort auf sich ändernde Anforderungen
und komplexe Probleme. Es funktioniert aber nicht, wenn jeder vor der
Komplexität die Augen verschließt und mantra-artig betet: "Wir sind
ja agil, die Agilität macht das schon!". So werden nämlich Probleme
schliechtweg ignoriert und die komplette Komplexität auf die
abgewälzt, die am Ende für die technische Umsetzung verantwortlich
sind: Die Entwickler.

Es fehlt der Austausch auf Augenhöhe, ein Verständnis für die Probleme
und die Bereitschaft die Komplexität anzuerkennen. Denn Agilität kann
zwar der Weg zur Lösung sein, nicht die Lösung selbst. Sie wird aber
häufig so eingesetzt.

Eigentlich müsste man sich also die Frage stellen: Ist das Ganze wirklich
komplext oder vielleicht doch nur sehr kompliziert? Sehr viele
Anforderungen sind nämlich oft nicht.

Und denkt dran: In der Iteration ist eigentlich alles wieder Wasserfall oder V-Modell,
halt nur in ganz ganz klein.

[herrmausf]

Kann deinen Post zu 100% unterschreiben.

[patka]

Ich stimme zu, weil ich das auch schon gesehen aber am Ende sind das aber Probleme, die aus der Disziplin der Personen heraus kommen, die beim Projekt involviert sind und nicht Probleme der genutzten Methode.

Das ist ähnlich zu der Zeit als alle Clean Code gelesen haben und in dem Buch stand, dass Clean Code sich selbst dokumentiert. Daraus haben alle abgeleitet, dass sie keine Doku mehr schreiben müssen, weil sie ja Clean Code schreiben.

Wenn man ein Interesse daran hat, funktionierende Software abzuliefern, wird man die auch testen und, dass manuelles Testen auf Dauer sehr zeitintensiv ist, wird hoffentlich auch jedem irgendwann klar. Wenn nicht, dann wäre das Projekt auch mit jeder anderen Methode gescheitert weil man Leute hat, die nur Zeit gegen Geld tauschen, ohne Anspruch an die eigene Arbeit zu haben.

[TheBodo]

Ja, das stimmt. Bei der aktuellen Arbeitsmarktsituation gehen die Leute mit Qualtitätsanspruch aber einfach woanders hin, wenn das Management versagt...

[Lord Gamma]

So ist es, die Abschaffung von Management sollte nicht die Antwort darauf sein, dass es so viele schlechte Manager gibt.

[Analysator]

Stimmt schon.
Daraus darf aber auch nicht "hey wir haben so viele tolle automatisierte Test-Cases geschrieben, das langt. Das muss kein Mensch mehr selbst testen, alle Test-Cases laufen ja mit passed durch!" werden...

[Lefty83]

Neben all den komischen Kommentaren mal ein guter dazwischen… hatte fast die Hoffnung aufgegeben. ;)

Der Autor beschreibt Scrum nicht als Heilmittel, sondern flexible Denkweisen und damit eine Fehlerkultur, sowie ausprobieren dürfen als notwendiges Mittel.
Ich kann sagen, ich tue mich in den klassisch deutschen Unternehmen extrem schwer. Alles muss 110% sicher vorgeplant sein, bloß kein Risiko. Das die Vorplanung ewig dauert und ehh da Ressourcen ohne Ende verschlingt ist egal. Viel mehr Sicherheit hat man auch nicht und bei laufenden Kosten, Support und Weiterentwicklung hört der Spaß dann ganz auf. :P
Bei Amerikanischen oder Koreanischen Unternehmen wird nicht lange diskutiert. Da wird ein Goldsack hin gestellt und gesagt in drei Monaten ist da nen neuer Shop.