Freitag, 30. Oktober 2015

Was ist ( eigentlich ) "Agil"?

Zunächst einmal bin ich der Meinung, dass Software-Entwicklung IMMER agil ist, weil man die Software, die "weiche Ware" auch sehr schnell ändern kann.

Das ist ein Vorteil (man kann schnell anpassen) gleichzeitig aber ein Nachteil (man kann die Software "ad infinitum" ändern ("Änderitis"). Doch auf keinem Fall ist Software-Entwicklung nicht agil, egal welche Methode man anwendet.

Solche ständige Änderungen sind wohl auch Verschwendung im Sinne der "Lean"-Prinzipien (also gegen die "Lean" Prinzipien, die grundsätzlich gegen Verschwendung sind: also müsste eine Lean-Entwicklung grundsätzlich gegen Änderungen sein, somit aber auch gegen das, was eine SW-Entwicklung ausmacht...).

Und es sind aber auch solche Änderungen, die diese "agilen" Methoden befürworten, die dann auch zu aller Überfluss von vielen Menschen, Gruppen von Menschen und "Berater" sogar aller Couleur, gerne "Verkauft" werden; und dabei schießen sie sich, meiner Meinung nach, selbst ins Knie. Oder verdienen sich eine goldene Nase, je nachdem.


Scrum: agil oder nicht agil?
Es gibt außerdem auch Menschen, die behaupten, dass "Scrum" nicht agil sei.
Wieso?
Weil, zum Beispiel, täglich ein "Stand up" abgehalten wird. Sehr Starr. Nicht agil.
Dazu sehr feste Riten, wie zum Beispiel Retrospektiven, Planungsmeetings, usw.
Man kann eigentlich ohne weiteres postulieren, dass Scrum eine Art "Wasserfall" ist (wenn tatsächlich eine solche Konstruktion existieren würde), bei dem anstatt nach Funktionen nach "Timeboxing" entwickelt wird.
Schlicht und ergreifend "das Gleiche in Grün".

Und... sind andere "agile" Methoden auch "das Gleiche in Grün" ?

Mal sehen...


Nun stellt sich die Frage: Was ist "Agil"?
Zunächst gilt es, Abstand von dem unnützlichen "Manifesto" zu nehmen.

Nach der Definition von "Agilität":
- Gelenkigkeit {1}
- Aufgewecktheit {2}
- Gewandtheit {1}
- Lebendigkeit {2}
- Mobilität {1}
- Regsamkeit {2}
- Wendigkeit {1}
- Agilität {1}
- Flinkheit {1}

Es ist klar somit, dass jegliche Software-Entwicklung "agil" per se ist.
Vielleicht sollte eher das Ziel darin bestehen, zu versuchen, die Software-Entwicklung in Wirklichkeit "unagiler" zu machen, um nicht in des Teufels Änderungsküche zu geraten... (und bedanken wir uns hier bei den Lean Prinzipien ;-)


Was spricht eigentlich gegen die "Agilität" der "agilen" Methoden
Es handelt sich offensichtlich um ein Paradoxon:
Durch die "agilen" Methoden wird die Software-Entwicklung (welche natürlicherweise die weiter oben mit {1} aufgelisteten Eigenschaften inne haben) in einem Korsett von Richtlinien und Prinzipien eingepresst, und gleichzeitig wird behauptet, das sei "agil".
Pustekuchen ist das "agil" :-)
Es ist Verschwendung auf höchster Ebene, ganz im Gegenteil zu den Lean Prinzipien.


XP: Praktisch, ja, einige Wochen; wenn ein Anfänger hinter einem "Senior" sitzt. Sonst liegt die Produktivität bei ca 10 bis 20 % mehr von dem, was ein Entwickler alleine schafft: Also ein Wirkungsgrad von... 60% ?.

Nach meinem Wissen sind es gar nicht so viele "agile" Methoden im Umlauf (wenn man die -vielen- Variationen von "Scrum" außer Acht lässt: ein "Scrum" wo jedes Team irgend einer Abart von Scrum einsetzt, als "Scrum-But" bekannt, was schon zeigt, was man davon halten soll), doch wirklich funktionieren tut keine aus inhärenten Eigenschaften; Es sind immer die Teams, die etwas zum Laufen bringen.

Also das Dogmatismus um die "agilen" Methoden setzt auf den falschen Prinzipien. Offensichtlich.