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.