Category Archives: Agile Methodik

Ü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

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:

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:

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).
 

Fehlende Software-Qualität kann auch große Unternehmen gefährlich stolpern lassen!


Dass fehlende Qualität von Software ein Unternehmen in Krisen führen kann, bestätigt sich auf jeden Fall dann, wenn anhaltende Probleme mit einen unter­nehmenskritischen neuen System den CFO zu einer Gewinnwarnung zwingen und so auch die Aktionäre beunruhigen.

Sie glauben nicht, dass so was passiert? Nun, hier ist ein Beispiel:

Wie die Computerwoche berichtet, droht das misslungene neue Computersystem “New Forwarding Environment” (NFE) die Deutsche Post im Frachtgeschäft um Jahre zurückzuwerfen.

Deteils finden sich auf FinanzNachrichten.de in einer Meldung vom 29.10.2015:
 

    Larry Rosen, der Finanzchef der deutschen Post, erklärt, NFE sei zu fehleranfällig und müsse wohl ersetzt werden, was Jahre dauern könne, denn eine neue, weniger komplexe Lösung stehe kurzfristig nicht zur Verfügung.

    Man überlege nun, schrittweise neue Komponenten zu integrieren und habe Rückstellungen in Höhe von 37 Millionen Euro gebildet für Ausgaben zur erwarteten Rückabwicklung des Systems in den bereits umgestellten Pilotländern.

    Der Bonner Konzern schätze die Wahrscheinlichkeit, aus dem derzeitigen System positive Effekte erzielen zu können, als sehr gering ein und habe deshalb auch Abschreibungen in Höhe von 309 Mio. Euro vorgenommen.

    Die bereits nach dem zweiten Quartal 2015 schon einmal korrigierte Prognose sei nun nicht mehr zu halten.

 

Nachdenklich macht: NFE basiert auf Software von SAP und wurde mit IBM Global Business Services als Implementierungspartner umgesetzt.

Da sollte man sich schon fragen, wie es zu einem solchem Unglück kommen konnte.

Eines dürfte klar sein:

Obgleich zu akzeptabler Software-Qualität weit mehr gehört als nur die Abwesen­heit von Programmierfehlern, wird sie doch (vom Software-Lieferanten) gerne auf genau solche reduziert gesehen. Dem Auftraggeber fällt das zunächst gar nicht auf.

Doch können denn wirklich nur Programmierfehler so ein Desaster verursachen, wenn das System auf Code beruht, den SAP und IBM entwickelt haben (Firmen also, von denen man erwartet, dass sie kompetentes Personal einsetzen)?

Meine etwa 30-jährige Erfahrung mit Software-Entwicklung sagt mir, dass ein System, dessen Anforderungen vor Beginn der Programmierung genau und vollständig schriftlich spezifiziert und entsprechend gründlich durchdacht worden sind, von erfahrenen Programmierern auf keinen Fall derart verkorkst werden kann, dass es nicht gelingt, alles wesentliche Fehlverhalten innerhalb weniger Monate, wenn nicht Wochen, beseitigen zu können.

An was aber mag es denn dann liegen, dass selbst weltweit bekannte Software-Lieferanten wie IBM — solche, denen man größtmögliche Erfahrung unterstellt — ein System abliefern, welches seine Anwender und Betreiber als kaum nutzbar, auf jeden Fall aber als nicht länger tragbar einstufen?

Mein Verdacht: Man wird wohl versucht haben, nach dem Agilen Manifest zu arbeiten — nach dem Vorgehensmodell also, das seit der Jahrtausendwende unter dem Label “Agile” hochgelobt wird, weil junge Entwickler sich nicht mehr die Mühe machen wollen, die klassischen Verfahren des Software-Engineerings wirklich zu verstehen und der inzwischen neu hinzugekommenen Notwendigkeit, maximal flexibel zu sein, erfolgreich anzupassen — auch und gerade unter der Neben­bedingung, dass heute fast alle Entwicklungsaufträge zum Festpreis vergeben werden.

Wenn die Deutsche Post jetzt plant — und sich sogar gezwungen sieht — “eher evolu­tionär” vorzugehen (wie Rosen sich ausdrückt), klingt mir das schon fast nach einer Wiederholung des von mir vermuteten Fehlers.

Will man wirklich riskieren, dass ich recht habe? Will man nicht zuerst über die Ursachen des Mißerfolgs nachzudenken?

Oder will man einfach nicht einsehen, dass der klassische Weg, Software zu ent­wickeln, eher Erfolg garantiert als SCRUM-artig gestaltete Prozesse in Kombination mit dem blinden Glauben an die Effektivität der allzu naiven Prinzipien des Agilen Manifests?

Ist uns denn nicht bewusst, dass Agile, SCRUM und dieser ganze verhängnisvolle, viel zu wenig durchdachte Trend auf eine kleine Gruppe von Wartungsprogram­mieren zurückgehen, die dachten zu wissen, wie man wirklich große Software-Entwicklungsprojekte so durchführt, dass (fast) nichts mehr schief gehen kann?

Wer glaubt, man könne die Wahl des Prozessmodells zur Entwicklung einer umfangreichen IT-Lösung einfach der Mode oder nur an ihren Code denkenden Programmierern überlassen, der irrt gewaltig.

Dem CIO der Deutschen Post jedenfalls kann man nur raten, die Ursachen seines Desasters genau zu identifizieren.

Versäumt er das, könnte die Deutsche Post in einer eher noch folgenreicheren IT-Sackgasse landen. Ob es dann noch reichen würde, einfach nur eine Gewinn­warnung herauszugeben, kann bezweifelt werden.
 

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 Erfahrungmit 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.