Über falsch verstandene “Agile” Methodik

Wer mich kennt der weiß:

Ich bin ein erklärter Gegner der im Agile Manifesto postulierten Methodik und der daraus entstandenen — völlig ungeeigneten — Software-Entwicklungs-Modelle, für die heute SCRUM schon fast als repräsentativ gilt.

Am deutlichsten habe ich meine Warnung vor solch verwerflichen Formen von Agile wohl zusammengefasst auf den beiden Seiten

• Nimm Kritik am WIE der agilen Bewegung ernst und
• Warum SCRUM — und undurchdachtes “Agile” — uns in den Abgrund führen.

Man sollte daraus nun aber nicht schließen, dass ich ein Gegner heute notwendig gewordener Agilität wäre.

Ganz im Gegenteil: Mir ist klar, dass spätestens ab der Jahrtausendwende agiles Vorgehen unverzichtbar geworden ist — die im Manifesto vorgeschlagene Lösung allerdings kann nur ins Verderben führen (denn sie ist undurchdacht und beispiellos naiv).

Meine Ansicht darüber, wie Agilität verstanden und gelebt werden sollte, ist definiert auf den beiden Seiten:

• Was agile Projektdurchführung sein sollte und
   
• Ein erprobtes Vorgehensmodell hierfür ist das SST-Modell: Specify, Subcontract, Test, wenn man es spiralartig anwendet.

Um zu zeigen, dass ich keineswegs der einzige bin, der “Agile” und SCRUM für absolut ungeeignet — ja sogar gefährlich — hält, seien hier Links hin zu Meinungen Dritter aufgelistet, die ebenso denken wie ich und die aus eigener negativer Erfahrung heraus zu dieser Einstellung kamen:

• Gartner fand heraus …
   
• Michael O. Church — heute bei Google — sah durch Umstieg auf SCRUM ein schon börsen-notiertes Startup-Unternehmen zugrunde gehen. Er schreibt wörtlich: “This shit is toxic, it needs to die yesterday.”
   
• Erik Meijer, ein mehrfach preisgekrönter Fachmann für Software-Entwicklung, nennt SCRUM ein “Krebsgeschwür”.

Weitere Meinungen:

• Warum man SCRUM auch als Saboteur notwendiger Agilität sehen kann.
   
• Mögliche Gründe für den (unerklärlichen) Siegeszug von “Agile”
   

• Camon Hamilton (2015, Zitat): “Viele einflussreiche Denker stellen die Relevanz oder den “Gesundheitszustand” von Agile in Frage”.

Historisch gesehen, gilt:

Die extrem bürokratisch angelegten Vorgehensmodelle, die

• zunächst in den USA durchs DoD (Department of Defence) zur Pflicht gemacht wurden,
• dann aber — in Nachahmung davon — auch in Deutschland als sog. V-Modell (entwickelt von der IABG) sogar Behördenstandard wurden,

mussten irgendwann zu einer Gegenreaktion, zu einem Befreiungsschlag führen. Er kam in Form der Agilen Bewegung, war aber nicht durch entspre­chende Forschung unterstützt, und hat daher zu einem geradezu lächer­lichen Modell geführt, dessen Aushängeschild sich SCRUM nennt und fast schon als verdammenswert einzustufen ist).

Erst nach 2000 wurde einigen wenigen klar, wie ernst man die Gefahren dieser neue Bewegung nehmen muss. Weltweit anerkannte Methodiker des Software-Engineerings, die ihre Stimme hätten erheben können, waren da aber just schon alle aus dem aktiven Berufsleben ausgeschieden.

Nur so ist erklärbar, dass diesem ganzen Unsinn bis heute kein Einhalt geboten wurde …

Erfahrene Software-Entwickler wissen: Um agil zu sein, reicht es völlig

• das klassische Wasserfallmodell spiralförmig anzuwenden (sprich: zuzu­geben, dass jede seiner Phasen erst zu Projektende abgeschlossen sein kann)
• und allzu bürokratische Regeln des V-Modells einfach zu ignorieren (es also projektspezifisch zu verschlanken).

Natürlich wird, damit der Auftragnehmer auch im Kontext von Festpreisprojekten nicht ungebührend benachteiligt wird, jede Abänderung einer durch beide Parteien als zunächst fertig akzeptierten Version des Pflichtenheftes einer geeigneten Vertragserweiterung bedürfen (Change Management).
 

Advertisement

Wirklich Trauriges zu Agilität im Software Engineering

Obgleich die Diskussion um sog. Agile Software-Entwicklung heute heftiger wird denn je, hat man den Eindruck, dass vor allem die Entwickler und Programmierer selbst nicht wirklich verstehen, über was sie da im Detail nachzudenken haben: Jeder glaubt, den Begriff zu verstehen, aber kaum noch jemand geht ihm wirklich auf den Grund.

Wer nachliest, was Gartner uns sagt, wird sofort erkennen, was ich meine und dass es an der Zeit ist, zu handeln: Wir, die Software-Ingenieure, müssen lernen, wieder mehr wissenschaftlich zu denken: eben wie Architekten und Ingenieure und über den gesamten Lebenszyklus dessen hinweg, was wir bauen.

Stattdessen scheinen wir inzwischen zu denken wie Handwerker oder angehende Programmierer in der High School (!).

Versuchen wir’s mal richtig:

Ja, es sollte heute selbstverständlich sein, dass im Zuge der Entwicklung neuer Software alle Beteiligten gewillt und in der Lage sind, höchst agil zu reagieren — weit flexibler jedenfalls, als das noch bis vor etwa 15 Jahren notwendig war oder auch nur denkbar erschien.

Richtig ist aber auch, dass der agile Ansatz noch häufig zu wenig verstanden wird:

Wer angehenden Software-Entwicklern eine SCRUM-Schulung bezahlt und glaubt, sie könnten dann schon in sinnvoller Weise agil sein, der irrt gewaltig:

Im positiven Sinne agil zu handeln erfordert Können und viel Erfahrung — mit dem Agile Manifesto allein gelassene Lehrlinge werden stets nur Schaden anrichten (Schaden, der nicht sofort jedem sichtbar wird, der aber durchaus gravierend sein kann, siehe z.B. Agile is ignoring CIO’s Interest).

Das zu wissen lohnt sich vor allem für die Betreiber, Nutzer und Eigentümer von Software, weniger für die Entwickler (denn die haben, wenn der Schaden offen­kundig wird, die Verantwortung längst abgegeben und ihr Geld schon kassiert).

Wer als Methodiker die Diskussion um agile Prozesse verfolgt, der sieht, dass sich jeder Diskussionsteilnehmer schnell erkennbar einer der folgenden drei Gruppen zuordnet:

• Gruppe 1: Das sind alle, die um jeden Preis "agil" sein wollen — den Ansatz in seiner ganzen Tiefe aber noch lange nicht wirklich verstanden haben.
   
• Gruppe 2: Jene, die schon nachdenklich wurden (da ihnen auffällt, dass die Diskussion um wünschenswerte Agilität immer lauter wird, aber doch nun schon gut 10 Jahre lang nur gebetsmühlenartig die immer gleichen Halb­wahrheiten aus dem Manifest zitiert.
   
• Gruppe 3: Dazu zählt, wem längst klar ist, dass Entwickler und Berater aus Gruppe 1 eine Zeitbombe nach der anderen produzieren.

Eine Schande für unseren ganzen Berufsstand ist, dass auch viele gut bezahlte Berater und Trainer sich in Gruppe 1 tummeln. Diese Gruppe ist allzu groß und scheint kaum zu schrumpfen.

Dass Leute aus Gruppe 3 sich selten oder nur allzu vorsichtig zu Wort melden, ist schade (und eigentlich unverantwortlich). Einer der wenigen, den diese Kritik nicht
trifft, ist Mike Gualtieri, der in Forrester’s Blog, schonungslos Kritik übt und dann zum Schluß kommt: " … we need a new software development methodology. Agile is not it."

Was er uns damit sagen will ist wohl: « Die — ja nun wirklich — zu wenig flexible klassische Vorgehensweise muss fortentwickelt werden zu einer neuen, besseren. Die aber darf nichts zu tun haben mit dem, was in den Köpfen zu wenig umsichtig denkender Agilisten an unausgegorener Vorstellung so alles existiert. »

Ich sehe die Situation ebenso, bin aber der Meinung, dass wir da erst vorankommen werden, wenn wir Agilität über ihren Zweck definieren, nicht aber, wie bisher, über das zu kurz gedachte und mißverständlich formulierte Manifest aus dem Jahr 2001.

Sich Tom de Marcos resignierender Feststellung anzuschließen I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone scheint mir (noch) zu früh — hoffen wir, dass es nicht so kommt.

 

Zur Informatik Theoretischer Physik

Wer sich für informationstechnische Grundlagen Theoretischer Physik interessiert (vor allem aus rein logischer, grundsätzlicher Sicht heraus), der sei auf folgende Kurzartikel aufmerksam gemacht:

• Hawkings Denkanstoß
• M-Theorie
• Physikalisches Wissen extrapolierende Modelle
• Die Kernfrage

In den letzten Jahren scheint scheint die Stringtheorie (M-Theorie) einen Konkur­renten bekommen zu haben, den man mehr und mehr erst zu nehmen hat: die sog. Schleifen-Quantengravitation.

Wer sich als Abiturent überlegt, ob sein Studienfach nicht vielleicht Theoretische Physik sein könnte, dem sei empfohlen zu lesen, was Prof. Andreas Engel schreibt.