welt-verstehen/

Unsere Welt zu verstehen:



 Beitrag 0-145
 
 

 
Was SCRUM
 
— von nur wenigen Ausnahmen abgesehen —
 
verdammenswert macht

 
 
In Reaktion auf die Ende der 60-er Jahre eingetretene Software-Krise kam es — zur immerhin ganze drei Jahrzehnte währenden — Blütezeit des Software Engineerings.
 
Ich bin heute noch dankbar, dass ich sie miterleben durfte als jemand, der einige ihrer Pioneere gut gekannt hat: Insbesondere F.L. Bauer und Ernst Denert.
 
Wofür ich sie — aber auch Parnas, Dijkstra und Boehm — heute immer noch bewundere, ist, welche unglaublich große, wirklich durchschlagende Wirkung sie mit ihren Lösungsvorschlägen erzielten:
 
    Jede dieser fünf Personen hat eine wichtige Schlüsselidee erfolgreichen Software Engineerings in die Welt gesetzt bzw. wurde — wie z.B. Ernst Denert —
    nicht müde, sie zu propagieren.
     
    Welch gewaltige, nachhaltige Wirkung gerade Denert damit erzielt hat, das Prinzip der Datenabstraktion auch in der Praxis hoch zu halten, konnte ich als damaliger Mitarbeiter von Softlab hautnah miterleben: Denert war nur etwa 5 Jahre für Softlab tätig (so etwa 1975-1980), hat jene Firma durch sein Wirken
    aber auf die richtige technologische Schiene gesetzt, was bewirkt hat, dass sie noch bis hin zur Jahrtausendwende deutlich erkennbar davon profitiert hat — natürlich auch in Mark und Pfennig, wie man so schön sagt.
     
    Denerts Prinzip » Die beste Praxis ist eine gute Theorie « fand und finde ich immer wieder bestätigt.

 
Gegeben also die großen Methodiker der Jahre 1965-2000, war es kaum zu verstehen, dass keiner von ihnen — ausgenommen vielleicht Tom Gilb — irgendwelche Versuche unternahm, die beispiellose Naivität des Agilen Manifests und all derer, die es wörtlich nehmen, als  p u r e s  G i f t  zu identifizieren.

     
    Sie alle haben tatenlos — und wohl sprachlos vor Verwunderung — zugesehen, wie alles, was sie an methodischem Fortschritt über gut 30 Jahre hinweg erarbeitet hatten, plötzlich unter Berufung auf das Agile Manifest als nicht weiter akzeptabel erklärt wurde.
     
    Unangetastet blieb nur, was schon eingeflossen war in die Konzepte moderner Programmiersprachen.
     
    Erst heute, etwa 20 Jahre nachdem die Agilisten, die Erfinder von SCRUM und die vielen Trainer, die "Agile" und SCRUM zu propagieren als ihre persönliche Goldgrube entdeckt haben, wird so manchem langsam klar, in welch beispiellose Sackgasse uns die unausgegorenen Ratschläge der Agilisten bereits geführt haben:

    Die agile Bewegung nämlich hat bewirkt, dass ein Großteil dessen, was in der Blütezeit des Software Engineerings an methodischem Fortschritt erarbeitet worden war — insbesondere das Wasserfallmodell — heute unter jungen Software-Entwicklern geradezu als  A n t i p a t t e r n  gilt.
     
    Ihnen wird nicht mehr klar, dass Kritik am Wasserfallmodell sich nicht auf das Modell selbst bezieht, sondern lediglich auf seine allzu starre Anwendung, die dann gegeben ist, wenn man sich weigert, einmal abgenommene Teilergebnisse bei Bedarf noch  v o r  Projektende zu revidieren.
     
    Die durch die agile Bewegung in ihrer Naivität verursachte "Entsorgung" methodischen Knowhows geht so weit, dass selbst die Vertreter der jungen Generation, die SCRUM inzwischen als  k o n t r a p r o d u k t i v  erkannt haben — der niederländische Informatik-Dozent Erik Meijer etwa, der mehrfach für seine gute Arbeit als Systemarchitekt bei Microsoft ausgezeichnet wurde —, heute genau das als Abhilfe propagieren, was Mitte der 60-er Jahre die damalige Softwarekrise ausgelöst hatte: der Glaube nämlich, dass es genüge und wünschenswert sei, einfach nur Code zu schreiben.

 
Michael O. Church — heute Manager von Entwicklungsteams bei Google — hat es geschafft, treffend zu charakterisieren, was speziell SCRUM — von seltenen Notfallsituationen mal abgesehen —  v e r d a m m e n s w e r t  macht. Er schreibt (im Juni 2015):
 
    So what are Scrum and “Agile”? I could get into the different kinds of meetings (“retrospective” and “backlog grooming” and “planning”) or the theory, but the fundamental unifying trait is violent transparency, often one-sided. Programmers are, in many cases, expected to provide humiliating visibility into their time and work, meaning that they must play a side game of appearing productive in addition to their actual job duties.
     
    Instead of working on actual, long-term projects that a person could get excited about, they’re relegated to working on atomized, feature-level “user stories” and often disallowed to work on improvements that can’t be related to short-term, immediate business needs (often delivered from on-high). Agile eliminates the concept of ownership and treats programmers as interchangeable, commoditized components.
     
    In addition to being infantilizing and repellent, Scrum induces needless anxiety about microfluctuations in one’s own productivity. The violent transparency means that, in theory, each person’s hour-by-hour fluctuations are globally visible– and for no good reason, because there’s absolutely no evidence that any of this snake oil actually makes things get done quicker or better in the long run. For people with anxiety or mood disorders, who generally perform well when measured on average long-term productivity, but who tend to be most sensitive to invasions of privacy, this is outright discriminatory.

 
Seine ausführliche, das Problem genau identifizierende Analyse schließt mit der Feststellung:
    It’s time for most of "Agile" and especially Scrum to die. These aren’t just bad ideas. They’re more dangerous than that, because there’s a generation of software engineers who are absorbing them without knowing any better. There are far too many young programmers being doomed to mediocrity by the idea that business-driven engineering and "user stories" are how things have always been done. This ought to be prevented; the future integrity of our industry may rely on it. "Agile" is a bucket of nonsense that has nothing to do with programming and certainly nothing to do with computer science, and it ought to be tossed back into the muck from which it came.


 


aus  Notizen  zu:

Kommt es zu einer neuen Softwarekrise?


Impressum