ruynk

Systemanalyse - Software Entwicklung - Qualitätssicherung - Projektmanagement - FlePA



Interne Links



Inhalt

Was soll man unter "Agile" verstehen?

Analyse des "Agilismus"

Das Irrlicht "Agile"

Die bizarre Mythologie der SW-Entwicklung

Missgeburten der "Agilen" - Ausblick

Getting Real: Einige Gedanken bezueglich SW-Entwicklung

Das Projekt: Warum ist die Projektarbeit unberechenbar

Wer ist "ruynk"?

FlePA (Flexibles Planen und Arbeiten)

Mit ruynk zusammen arbeiten

Downloads und externe Links

Impressum - Kontakt








Ich distanziere mich nicht: Unsinnige Rechtslage in der BRD.






Das Wort "Agil" hat folgende Bedeutungen:

  • Gelenkigkeit ("gelenkige" Entwicklung?)
  • Aufgewecktheit ("aufgeweckte" Entwicklung?)
  • Gewandtheit ("gewandte" Entwicklung?)
  • Lebendigkeit ("lebendige" Entwicklung?)
  • Mobilität ("mobile" Entwicklung?)
  • Regsamkeit ("regsame" Entwicklung?)
  • Wendigkeit ("wendige" Entwicklung?)
  • Flinkheit ("flinke" Entwicklung?)

Mehr dazu hier, geschrieben am 30.10.2015.


Das Paradoxon: Agiles Dogmatismus

Die heutigen Wirklichkeit, wie sie sich aus den "Prinzipien" ableitet, sieht folgendermaßen aus:

1. [...] kontinuierliche Lieferung [...] => Wird zu einem Dogma, oft durchgesetzt ohne vernünftige Gründen (...weil "Alle" das machen, wollen wir auch...)

2. [...] Änderungen der Anforderungen, auch spät [...] => Unvernünftig. Das hier ist echt Gift für einem Projekt (Merke: "SW-Entwicklung = Projektarbeit").

3. [...] häufig funktionierende Software liefern [...] => Dogmatisch ausgelegt, auch ohne es zu müssen wird versucht, stets funktionierende Software zu liefern.

4. [...] müssen täglich zusammen arbeiten [...] => Dogma. Starr. Unvernünftig.

5. [...] motivierte Individuen [...] => Mythos (siehe Mythen) des motivierten Mitarbeiters, außerdem ist die Idee keine Errungenschaft der Agilen.

6. [...] Konversation von Angesicht zu Angesicht [...] => Dogmatisch, wird oft als Glaubensbekennung erwähnt und verlangt.

7. [...] Fortschritt ist funktionierende Software [...] => Eben nicht. Es wird auch nicht erwartet, dass ein Haus während des Baus bewohnbar ist. Wird jedoch oft dogmatisch abverlangt.

8. [...] sollten ein gleichbleibendes Tempo ohne Unterbrechung [...] => Starr und dogmatisch. Keine Unterbrechung zu erzwingen ist nicht selten kontraproduktiv.

9. [...] fortwährende Beachtung verbessern [...] => Keine Exklusivität der "Agilen". Jedoch propagandistisch ausgedrückt und oft dilettantisch implementiert.

10. [...] Einfachheit [...] => Eben auch nicht immer. Nicht zu einfach und nicht zu kompliziert. Inhaltsloser Punkt.

11. [...] selbst organisierte Teams [...] => Mythos der "Selbstorganisation" von Teams (siehe Mythen). Wird gerne dogmatisch angewendet, denn es klingt so schön "mystisch". Das 'Management' liebt das, weil sie sich dann "entlastet" fühlt.

12. [...] reflektiert in regelmäßigen Intervallen [...] => Die Idee ist zwar gut (ursprünglich stammt die Idee aus dem "Toyota Way"), sie wird aber starr und dogmatisch, unvernünftig also, umgesetzt.


Weitere Überlegungen zu den Prinzipien vom 13.05.2015.


Das Wort "Agil" scheint mir auch nicht zutreffend zu sein, denn aufgrund des Dogmatismus der Anwendung der Methoden sind sie nicht mehr "agil" im positiven Sinne.


Folgende Begriffe könnten aus meiner Sich besser passen:

  • Agiles Glaubensbekenntnis (Wegen des Dogmatismus)
  • Agiles Entwicklungsmärchen (Wegen der "wundersamen Heilung" der Softwarekrise durch "Agile")
  • Agiles Mythologiegebilde (Wegen den vielen mystischen Begriffen -auch als Buzzwörter bekannt-, welche die agile Welt schmücken)

Meiner Meinung nach wäre "agiles Glaubenbekenntnis" die zutrefendere Benennung.


Der Begriff der "Agilität" dürfte aber erhalten bleiben, denn die durch die agilen Prinzipien bedingte SW-Entwicklung besitzt oft folgende Eigenschaften:

  • Änderungen kommen vor: In Design, Architektur, Anforderungen, ... (Gelenkigkeit)
  • Das bedingt oft ein umfassendes Refactoring (Gewandtheit)
  • Lebendigkeit (z.B. durch lustige Spielchen bei Meetings - auch bekannt als "Motivationspusher" -)
  • Mobilität (gute Mitarbeiter versuchen durch Arbeitsplatzwechsel diese Agilität zu entgehen)
  • Regsamkeit (durch viele Meetings u.a. befinden sich die Entwickler ständig in innerer Unruhe)
  • Wendigkeit (das Ziel der Entwicklung wird nicht selten aus den Augen verloren)
  • Flinkheit (Entwickler nehmen schnell und unsauber - quick 'n dirty - Änderungen vor - und zurück - )


"Agile" mutiert zu einem Glauben

Mittlerweile fällt es mir wirklich schwer, von "agilen" Entwicklungsmethoden zu schreiben (sprechen), denn diese Konstrukten sind einerseits keine "Methoden" im Sinne des Wortes, andererseits sind sie auch nicht wirklich "agil".


Bedingt durch das Manifest und die Prinzipien entsteht ein dogmatisches Glaubensgebäude, bisweilen fundamentalistisch, welches eigentlich nicht wirklich "Agil", im (positiven) Sinne des Begriffes, ist:

  • Sieht "agil" aus (von Außen nimmt man viel "Regsamkeit" wahr).
  • Mitarbeiter können die "Agilität" sogar fühlen (durch innere Unruhe, zerhackte und zeitbegrenzte Arbeitsbatzen, Sprint-Stress).
  • Trotzdem sind diese Erscheinungen, so wie ich sie sehe, oberflächlich. Das, was ich auf der Arbeit sehen durfte lässt glauben, dass sich etwas tut. Doch die Ergebnisse sind oft, meiner Ansicht nach, (aufgrund der geleisteten Arbeit), geringer als zu erwarten wäre.


Ist "Agil" wünschenswert?

Die Frage an dieser Stelle, ob "Agilität" tatsächlich eine erwünschte Eigenschaft für die SW-Entwicklung ist, ist legitim.

Als Analytiker, Mathematiker und Qualitätsicherer ist es meine Pflicht, diese Frage zu stellen und mögliche Antworten zu untersuchen.

"Agile" kann funktionieren, muss es aber nicht. Somit sind für mich "agile" Methode keine Lösung. Eine Option, ja, doch keine wünschenswerte, denn wünschenswert wäre es doch, optimale und voraussagbare Ergebnisse zu bekommen.

Folglich kann ich aussagen:

1. Starr und Rigide ist nicht gut
... und
2. Durchgehend "Agil" ist ebenfalls nicht gut.

Eine Lösung soll:

  • So starr wie nötig,
  • So agil wie nötig,
  • So sicher wie möglich sein. (Mit "Sicherheit" als Ergänzung zur "Starrheit" und "Agilität")

Die Implementierung einer solchen Lösung ist die höhe Kunst der Projektdurchführung.

FlePA ist eine solche Lösung.




Design und Realisierung: ruynk - November 2016

Verlinkung zu diesen Seiten erlaubt.

Zuletzt Bearbeitet: Ruy C. N.-Kuhlmann, Feb. 2017