Der "SW-Entwickler als Fabrikarbeiter" vs. der "SW-Entwickler als Kreativitaetsmanager"

In meiner Untersuchung ("Untersuchung bezüglich der SW-Entwicklungsmethoden im Unternehmen mit dem Schwerpunkt 'Agil' und ansatzweise Suche einer Lösung für die Unzulänglichkeiten der gegenwärtigen SW-Entwicklungsmodelle", hier können Sie sie downloaden: http://www.ruynk.com/downl/SW_Entwicklung_Untersuchung.pdf) ist zu lesen, dass eine gute Möglichkleit, das Beste aus der SW-Entwicklung als Prozess heraus zu kriegen ist indem man den Entwickler erklärt, was man haben will, und sie dann gewähren lässt.

Diese Vorgehensweise ist stark vereinfacht und hat sowohl einige Vorteile als auch gravierende Nachteile (Stichwörter: Vergoldung, falsch verstandene Anforderungen, Änderungen ausser jedwede Steuerung, usw usf).

Dennoch hat die Vorgehensweise zweifelsohne wichtige Vorteile für das Ergebnis der SW-Entwicklung.

Die Grundlage dieser Vorgehensweise ist die Auffassung der Entwickler selbst, sie sehen sich als seien sie kreative Experten und Wissenmitarbeiter in einem.

Dagegen finden wir auf der anderen Ende der Skala Methoden wie Scrum, wo die SW-Entwickler wie Fabrikarbeiter behandelt werden und die zu bauenden SW als Mauer aus Steine, die die SW-Entwickler zusammen zu kleistern haben; mit Hilfe von schlauen Tools und unzähligen Meetings (Stichwort Mikromanagement) sollen diese Fabrikmitarbeiter nun in der Lage verstezt werden, die SW zu konstruieren.

Es dürfte klar sein, dass diese "Scrum" (Gedränge) Vorgehensweise auch weit entfernt von einem Optimum ist.
Vorteile: Mikromanagement; das Management ist jederzeit in der Lage den aktuellen Stand zu wissen.
Nachteile: Die Entwickler arbeiten weit unter ihre eigentlichen Fähigkeiten.
Ist nun ein SW-Entwickler ein Fabrikarbeiter oder ist er ein Kreativitätsmanager? Beide Ansätze sind falsch!
Ein SW-Entwicler ist ein SW-Entwickler und kein Designer, Architekt, Tester, oder was auch immer ein Modell aus ihm machen will!

Mit FlePA jedoch, als Nachfolge der sogenannten "Agilen", werden die SW-Entwickler wieder zu dem, was sie sind und somit die Entwicklung von SW selbst, als solche, optimiert.

Kann "Planen" flexibel sein?

Bei FlePA (Flexibles Planen und Arbeiten) kommt doch ein "flexibles Planen" vor.

Nun, daraus ergibt sich eine durchaus berechtigte Frage:
Wie kann man das "flexible" Planen verstehen?

Planen ist doch, sagen wir mal, sehr "rigide"... Man plant und daran soll man sich halten. Oder?

Von einem "flexiblen Planen" zu sprechen klingt wirklich so, als würde ich von einer "lebendigen Leiche" oder von "trockenem Wasser" reden. Richtig?

Nun; Planen ist nicht das Gleiche wie Planung.

Dadurch, dass ich (mit flexiblem Denken) Planung und Planen auseinander definiert und das Planen durchexerziert habe, habe ich eine Lösung gefunden und diese in FlePA eingearbeitet.

Die "Agilen" (Methoden) als notwendiges Uebel

Vielleicht haben Sie, werter Leser, aus meinen Blogeintraegen den Eindruck gewonnen, dass ich ganz und gar gegen die sogenannten "agilen" Methoden bin.

So ganz stimmt das nicht.

Ich halte die sogenannten "agilen" Methoden fuer einen ersten Schritt in der richtigen Richtung... leider hat man mit diesem 1. Schritt (nicht zuletzt wegen Missgeburten wie Scrum) richtig fett im Haeufchen getreten, dennoch haben wir, so wie ich es sehe, mit einem Schritt in der richtigen Richtung zu tun.

Der Softwareexperte Erik Meijer bezeichnet agile Methoden als "Krebsgeschwuer":
http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/management/articles/471509/

Ich habe einen grossen Respekt dem Kollegen Erik Meijer gegenueber, er sagt aus meiner Sicht eine Wahrheit aus: die "Agilen" seien ein Krebsgeschwuer, so wie sie zurzeit wuchern, ist die Aussage wohl zutreffend.

In meiner Meinung sind sie, die "Agilen", giftig, ruhen auf falschen Praemissen, sind unkontrollierbar und, durch eine Aura an Esoterismus bedingt (wegen des Dogmatismus der verschiedenen "Methoden"), zersplittern sie in einer Vielzahl an "Sekten" (Methoden, Techniken oder wie man das Ganze, das uns blueht, nennen mag). Die vielen "Sekten" zeigen deutlich, und das kann Niemand zweifeln, dass jegliche "agilen" Methode weit entfernt davon sind, eine Loesung oder gar ein Patentrezept zu sein.

Aber... die "Agilen" sind nicht aus Jux und Tollerei entstanden, sondern als Antwort auf bestimmten und ganz konkreten Problemen, und diese sind unbedingt zu adressieren, wenn wir eine Loesung fuer die SW-Entwicklung wollen und suchen.

Folglich halte ich die sogenannten "agilen" Methoden ein (zurzeit noch, aber nicht mehr lange) notwendiges Uebel in der SW-Industrie.

Zum Glueck gibt es schon einen Nachfolger: FlePA.

Kommentare zum "Status-Quo-Agile-2016_17-Abschlussbericht_Studienteilnehmerversion_1.0.pdf"

Vor wenigen Tagen bekam ich diese Studie und las sie, da mir das Thema natürlich interessiert ;-)

Folgende Punkte möchte ich gerne kommentieren

Auf Seite 26:
Gründe für und gegen die Verwendung agiler Methoden
Gründe sich für agile Methoden zu entscheiden (1/2)

"61% der Teilnehmer sagen, dass sie die Produkteinführungszeit optimieren möchten, 47% wollen die Qualität optimieren und 42% die Risiken im Projekt reduzieren."

Meiner Meinung nach haben sich die Herren, die sich das wünschen, sich nicht wirklich richtig mit der Thematik auseinandergesetzt: Ausgerechnet Produktivität und Risiken... Wunschdenken, anders kan nich es mir nicht erklären.

"Während die meisten Teilnehmer eine bessere Betriebsleistung anstreben, gibt es nur einige, die es wegen sonstiger/ externer Gründe tun: 27% sind mit klassischem Projektmanagement frustriert und einige wenden agile Methoden an, weil es von Geschäftspartnern gefordert wird."

Das man mit dem klassischem Projektmanagement frustriert ist, kann ich gut verstehen. Da muss sich aber das 'Management' an die Nase fassen...
Und wenn Geschäftspartnern das nun fordern... na, da soll man sich sehr genau ausrechnen, in was man da reingezogen wird...

Seite 98: Anwendungsformen - Nutzung agiler Tehniken: Lean Nutzer benutzen
"Daily Scrum: 87%
Sprint Planning 81%
User Stories: 80%
Sprint Review: 79% (also auch "Sprints")
... usw usf"
Dabei ist mir aufgefallen, dass ausgerechnet "Lean", (das sich eigentlich bemühen sollte, "schlank" zu bleiben, mit wenig "Overhead" und überflüssigen Verwaltungsarbeiten), solchen Techniken mit starker ZeitVerlustCharakter wie "Daily Scrum", "Sprint Planning", "Sprint Review" usw anwenden... da haben sie sich die "Leans" (zumindest die, die an dieser Studie teil genommen haben), ins Knie geschossen.
Das ist, in meinen Augen, kein "Lean " mehr, sondern eine (giftige) Mischform.

Und noch ein bisschen Nachdenken am Rande der Studie:

Wenn ich mir die Anzahl an verschiedenen "Methoden" anschaue, so habe ich den Eindruck, dass ich mit Sekten zu tun habe.
Besonders augenfällig (für mich zunächst, wegen Mangel an Bodenständigkeit) sind Methoden wie: "Design Thinking", "Lean Startup", "Agile Modeling", "Adaptive Software Development", ...

"Design Thinking": https://de.wikipedia.org/wiki/Design_Thinking
"Lean Startup": https://en.wikipedia.org/wiki/Lean_startup (englisch nur)
"Agile Modeling": https://en.wikipedia.org/wiki/Agile_modeling (englisch nur)
"Adaptive Software Development": https://de.wikipedia.org/wiki/Adaptive_Software_Development - Insbesondere auffällig: "Dabei wird alle vier Wochen geprüft, ob eine neu erstellte Programmversion einen Fortschritt zur Vorgängerversion darstellt. Dies geschieht gemeinsam mit dem Kunden. Zwischen jedem der Treffen werden die Phasen 'Spekulieren', 'Zusammenarbeiten' und 'Lernen' durchlaufen". Tja... man muss sich doch diesen Satz auf der Zunge zergehen lassen... ganz langsam, ganz genüsslich!

Meinen Eindruck über die vielen mehr oder minder definierten agilen Methoden ist:
Es handelt sich um ein wirrwarr an Sekten, die viel (viel zu viel) Text produzieren, jedoch nichts Konkretes: Die Produktion liegt auf einem sehr - sehr - niedrigen Niveau.
Ich persönlich lese die ganzen Artikel gar nicht mehr; ich überfliege sie, suche nach Ergebnissen, finde sie nicht, denke mir "schon wieder Überflüssiges...".

Anmerken muss ich, dass ein grosses Teil der Studie "Status Quo..." auf "Einschätzugen" von Teilnehmern basiert; leider ist das einerseits nicht sehr wissenschaftlich und andererseits nicht wirklich aussagekräftig, in meinen Augen...

Noch eine Anmerkung (die 2.): Wie ausagekräftig die Statiskiken aus einer mathematischen statistischen Betrachtungsweise sind, damit habe ich mich nicht auseinandergesetzt. Ich will die Studie doch nicht zerpflücken (nur kommentieren).

3. Anmerkung: Es ist leider nicht möglich zu wissen wie viele der Teilnehmer an die Studie eigentlich z.B. (externe) Berater bzw Mitarbeiter sind, die allgemein von dem "agilen" Hype leben oder leben wollen, und dementsprechen fallen die Aussagen in dem Sinne: positiv für die "agilen" Methoden. Die ganze Studie ist folglich aus meiner Sicht mit sehr viel Vorsicht zu geniessen.

Die Autoren der Studie sprechen diesen Punt auch auf Seite 188 an: "Ein Bias (eine Verzerrung) in der Stichprobe, der die Ergebnisse beeinflusst hat, kann somit nicht ausgeschlossen werden - ist sogar wahrscheinlich. Auch beruhen die Ergebnisse auf Eigeneinschätzungen der Teilnehmer. Es ist nicht auszuschließen, dass einige Angaben nicht der Realität entsprechen."

Interessante, ergänzende Information auf Seite 169:
"27% der Teilnehmer, die eine Angabe zur Zertifizierung gemacht haben, haben eine Scrum Alliance oder Scrum.org Zertifizierung."

Also hatten 80% der Teilnehmer eine agile Zertifizierung:
Seite 170:
Scrum.org: 27%
Scrum Alliance: 27%
Sonstige Zertifizierung für agile Methoden: 13%
Kanban Zertifizierung: 7%
Andere Scrum-Zertifizierung: 6%

Noch eine interessante, ergänzende Info: Die Teilnehmerstruktur. Hierauf will ich nicht mehr eingehen, wer Interesse hat, soll sich die Studie beschaffen und lesen.

Eine zusätzliche, interessante und ergänzende Info zu berücksichtigen ist auf Seite 191 zu lesen; die Liste der bedankten Unterstützer der Studie. ...Einfach als Hintergrundinformation.

Und die letzte interessante und ergänzende Info: Der Studieninitiator, Prof. Dr. A. Komus ist u.a. auch (Mit)Initiator der Praxiswerkstatt Agilität, Consultant und Coach in agilen Methoden, hat u.a. auch eine Studie "agiles PMO" (PMO: Projekt Management Office) geschrieben. Infos aus der Seite 189.

Honi soit qui mal y pense. Interessant ist die Studie allemal.

Ein Paradies auf Erden: agiles Wunschdenken

Ich habe etwas interessantes gelesen!

Aus
https://deutscherarbeitgeberverband.de/aktuelles/2017/2017_01_23_dav_aktuelles_wissen-nicht.html
folgenden Text:
"Es ist oft gesagt, aber selten gehört worden, dass der abstrakte Wunsch, allen Menschen das Paradies zu bereiten, der beste Weg zur Erzeugung einer konkreten Hölle ist. Das hängt mit den "guten Absichten", die auch ohne jede Kompetenz zum Handeln antreiben, eng zusammen."
Dörner untersuchte experimentell auch, ob die Gruppe, also die "Weisheit der Vielen", positiven Einfluss auf die Qualität der Entscheidungen hat. Dem war allerdings nicht so, vielmehr ergaben sich negative Gruppendynamiken, z.B. das sogenannten Gruppendenken, welche die Gruppe am Erfolg hinderten."

Daraus lässt sich folgern, dass sowohl eine Arbeitsweise nach "Wasserfall" (also nach einem wie auch immer gestaltenen hierarchischen System) als auch nach den "agilen" Merthoden (das Team als Leistungsträger) nicht wirklich, in der Praxis, funktionieren können.
Warum?
Weil:

1. Handeln ohne Kompetenz - Kompetenz im Wissen und Kompetenz im Treffen von  Entscheidungen - (typisch fuer die "agilen" Methoden)
2. Eine "Weisheit der Vielen" gibt es nicht, nur das Durchsetzen der Lautesten
3. Aus einer fehlenden Ordnung ergeben sich "negative Gruppendynamiken".

Alle 3 Punkte entspringen dem Wunschdenken, Menschen (Mitarbeiter) ein Paradies auf Erden anbieten zu wollen. Auch das agile Manifesto postuliert klar ein Paradies, welches sich aus eben ähnlichem Wunschdenken ableiten soll.

Die Lösung? FlePA.

Warum "FlePA"

Hier ein bisschen Information, zum Runterladen:

http://www.ruynk.com/downl/Warum_FlePA.pdf

"Agile" Methoden vergleichen: Anstoße zum Nachdenken

Hier:

Gedanken zu einem Vergleich zwischen "Agile" und "nicht Agile" (Version vom 25.01.2017)

und

Vergleich zwischen agilen Entwicklungsmethoden (Version vom 25.01.2017)

Viel Spaß beim Lesen!

ruynk

'Copy und Paste' beim Buchschreiben - ein kurzer Kommentar

Irgendwie schaffen die "Agilen" von sich reden zu lassen, wenn auch der Autor eigentlich besser täte, sich nicht zu äussern... So entstehen falsche Eindrücke, Dogmatisches und 'Hören-Sagen', wenn man ungeprüft Text durch Kopieren entstehen lässt. Oder soll ich die Aussagen vom Autor im Buche einfach als "Modererscheinungen" gelten lassen?

Im Buch "Projektmanagement" von Patzak und Rattay, 6. aktualisierte Auflage, Seite 703, kann man einen Vergleich zwischen Agilen und Klassischen Entwicklungsmethoden lesen. Hier meine Kommentare, nicht in Tabellenform sondern als Liste:

1)
Agiles Wert: Vertrauen
Klassisches Wert: Misstrauen/Kontrolle
Meine Meinung dazu: Man hat es sich hier viel zu einfach gemacht (m.a.W. einfach die "agile" Propaganda übernommen). Die Aussage stimmt nicht: Unter Scrum z.B. kommt es häufig zu einem unerträglichen Mikromanagement. In den "klassischen" andererseits spricht nichts dagegen, dass das Management in dem, was die Entwickler tun (entwickeln halt), Vertrauen hat.

2)
Agiles Wert: Verantwortung des Teams
Klassisches Wert: Gesamtverantwortung Projektleiter
Meine Meinung dazu: Das mit der Verantwortung des Teams ist Wunschdenken.

3)
Agiles Wert: Selbstorganisation im Team
Klassisches Wert: Führung durch den PM
Meine Meinung dazu: Das mit der Selbstorganisation des Teams ist Wunschdenken (kann funktionieren, muss aber nicht).

4)
Agiles Wert: Schätzungen/Entscheidungen im Team
Klassisches Wert: Vorgaben/Entscheidungen durch Projektleiter/Auftraggeber
Meine Meinung dazu: Mitarbeiter im Team sind dazu da, ihre Arbeit zu machen, nicht (r)um zu schätzen. Entscheidungen waren schon immer eine Domaene des Managements. So eine Vorgehensweise macht nicht immer Sinn (eher ausnahsweise, gebe ich zu - wenn das Management ein 'Management' ist, sie meine "Untersuchung...": Downloadseite bei www.ruynk.com)

5)
Agiles Wert: Auftraggeber-Koordination durch das Umsetzungsteam
Klassisches Wert: Auftraggeber-Koordination durch Projektleiter
Meine Meinung dazu: Das Team als solches ist dazu da, die Arbeit zu erledigen, nicht um Auftraggeber zu koordinieren.
Der Gedankenfehler hier scheint mir der zu sein, dass die "Agilen" das Team als eine Person (Entität) betrachten, anstatt, wie es tatsächlich ist, als eine arbeitende Menge von Individuen.

6)
Agiles Wert: Prozessoptimierung durch das Team
Klassisches Wert: Prozessoptimierung angestossen durch den Projektleiter
Meine Meinung dazu: Um ein Prozess zu optimieren, soll man es gut kennen und die angrenzenden Prozesse sollen auch noch berücksichtigt werden; selten wird es der Fall sein, dass ein Team das notwendige Know-How hierzu hat.

7)
Agiles Wert: Teamprozessreflexion durch das Team selbst
Klassisches Wert:  Teamprozessreflexion auf Initiative des Projektmanagers
Meine Meinung dazu: In der Wirklichkeit kann man aber deutlich beobachten, dass der "Prozess Master" (Name verwendet für die Rolle des 'Scrum Master' in dem o.g., Buch so fern ich das verstanden habe) die ominöse "Reflexion" anstosst, regelmässig, auch ohne Notwendigkeit, aus dem "Prozess" heraus, oft mit Null Zugewinn, also eher Zeitverlust (solange lustige Spielchen nicht als Zeitgewinn zu verbuchen sind).

Ein schneller Blick auf die agilen Methoden aus Sicht der Qualitätssicherung

Aus Sicht der Qualitätssicherung sind die agilen Methoden NICHT TRAGBAR.

Anmerkung: "Testen" ist NICHT Qualität sichern!

Folgende wichtigen Punkte der Qualitätsicherung sind in den "Agilen" nicht berücksichtigt:

1. Qualitätsmanagement ist nicht existent

2. Risikomanagement ist nicht berücksichtigt

3. TDD: Hierbei wird i.A. nur der "Gutsfall" getestet.

Dazu kommen noch weitere Probleme, wie z.B.

1. automatisierte Tests die wenig testen und einen riesigen zu Wartungsaufwand haben,

2. Bugs die übersehen und vergessen werden,

3.die Wartbarkeit von Code wird, langsam aber sicher, mit jedem Sprint durch unbedachtes Design (und keine Planung) erschwert.

… und noch Einiges, aber nichts Gutes.

Schrecklich, was wir IT Leute uns antun im Namen der „agilen“ Religion.

5 Schwachpunkte von Scrum

Hier zu lesen:

http://www.ilker.de/funf-schwachpunkte-von-scrum.html

Finde ich gut.

Aberglaube bei den SW-Entwicklungsmethoden

Der Glaube, dass eine "Entwicklungsmethode" ueber das "nicht Scheitern" oder ueber die Qualitaet oder gar "Geschwindigkeit" einer Entwicklung bestimmen kann,

ist so abstrus als wuerde man glauben,

ein Motor im Auto soll in der Laengst- oder in der Querrichtung der Fahrrichtung liegen, um den Wirkungsgrad erheblich zu ändern.

Dummes Zeug. Maßgebend sind die Menschen (Mitarbeiter); Erfahrung, Umgebung (Fehlerfreiheit), und so weiter und so fort: Viel eher als eine bestimmte Entwicklungsmethodik...

Warum "agile" Methoden nicht "Lean" sind

Agility/Velocity: Schnell und oft Fehler erzeugen

Gut: Man lernt mehr aus Erfahrung

Schlecht: Zeitverschwendung, anstatt zu denken (Vorsicht walten lassen) produziert man Fehler. Das is Muda (Verschwendung, Lean Prinzipien), somit gegen "Lean"

Die "agilen" Methoden zielen nicht darauf, Verschwendung zu vermeiden sondern viel mehr setzen darauf, diese zu produzieren. Durch:
- Meetings (ohne klare Ziele, mit Kollegen, die nicht nötig sind, usw); die überflüssige Verschwendung
- Wenig Planung und somit überflüssige, doppelte Arbeit, und Arbeiten, die zu spät oder zu früh erfolgen; die dumme Verschwendung
- Nie endende Änderungen; die reinste Verschwendung
- Teams, die sich selbst organisieren sollen; die umständliche Verschwendung.

Über das V-Modell XT

Habe interessiert gelesen.
Irgendwie scheint die BRD hier, (also zu einem Modell!), Eigentumsansprüche erheben zu wollen.

Schon Software-Patente sind ein "Unding". Dummes Zeug. Eine Möglichkeit, höchstens, arbeitslosen Juristen zu Geld zu verhelfen.

Wie bereits erwähnt, ist ein "Wasserfall" Modell in der Software-Entwicklung eher unmöglich: Das gab noch nie.
Der Glaube, dass so etwas existiert, verbreitet sich durch Hören-Sagen. Bei der "oose" in Hamburg gab mal ein Artikel über das Thema, den ich aber nicht mehr finden kann :-(
Es ist aber auch nicht so schlimm: Inhalt; Wasserfall gab es nie, es war nur ein Name für eine Modellierung bei einer Studie.

Das V-Modell XT ist nichts anderes, in meinen Augen, als die Ausarbeitung eines "Wasserfalls" Modell mit den Folgerungen, die dieses inexistentes Modell logischerweise haben müsste/hat.

Und von daher also, ist das ominöse V-Modell XT nichts anderes als das wirkliche, lebende, anwendbares "Wasserfall"-Modell :-D

Meiner Meinung nach, nicht schlecht, gut sogar bei einer Vielzahl von Anwendungen. Besser auf jeden Fall als die berühmten "agilen" Methoden.

Vielleicht würde sich ein V-Modell XT, kombiniert mit "Lean"-Prinzipien, eines Optimum nähern.
Und sicher für viele Projekte die bessere Lösung darstellen.

Software-Entwicklung: Ist Chaos eine positive Eigenschaft bei der Entwicklung?

Chaos aus Kundensicht

Zunächst ist es wichtig zu betonen, dass ein "Kunde" für sein "gutes Geld" eine ordentliche Ware oder DL (Dienstleistung) erhalten will, die eine Qualität aufweist, wie der Kunde sie erwartet.

1. Eine Ware, die ordentlich produziert worden ist, dürfte in den meisten Fällen die Erwartungen des Kunden entsprechen.
2. Eine Ware oder DL jedoch, die in einer chaotischen Produktionsumgebung entwickelt worden ist, dürfte in einer beträchtlichen Anzahl der Fälle nicht die Erwartungen des Kunden erfüllen, ganz einfach, weil in einer chaotische Umgebung Details ignoriert, vernachlässigt oder gar vergessen werden.

Hand aufs Herz: Würden Sie eine Buchhaltungs-Software kaufen, die eine Gruppe von Chaoten zusammen geschrieben haben mit wenigen bekannten Software-Fehler - oder doch lieber die Software von einem Entwicklungs-Team bei dem ganz genau geplant wurde, was zu tun ist, haben aber jedoch mehr Software-Fehler entdeckt, doch keine bekannten gravierenden Fehler enthalten sind?

Chaos als Ausrede

Es gibt Menschen, die stets versuchen auf dem "Schreibtisch" Ordnung zu haben; kämpfen gegen das Chaos.
Wiederum gibt es andere Menschen, welche die Meinung vertreten, sie seien "kreative Chaoten". M.a.W. bedeutet das, dass sie nur aus einer chaotische Umgebung heraus eine kreative Arbeit erledigen können.

Organisieren

Organisieren ist doch der Versuch, Ordnung in einer ungeordneten Umgebung zu schaffen, um zu einem kontrollierten Ergebnis zu erlangen.
Das Organisieren tut man nicht aus Spaß oder Langeweile, sondern weil man dadurch einen geplanten und durchdachten Ergebnis erzielt und somit die Kundenwünsche besser abdeckt.

Anmerkung

Ich möchte hier noch betonen, dass meine heutige Ausführungen sich nicht gegen die sogenannten "agilen Methoden" im Allgemeinen richtet; vielmehr beziehe ich mich auf alle Entwicklungs-Umgebungen die mehr chaotisch als geordnet arbeiten.
Sowohl unter Anwendung von XP, Scrum, Kanban (ist das Agil?) usw kann eine stabile, organisierte Arbeitsweise statt finden.
Alles kann man organisieren.
Nur die sogenannten "agilen Methoden" lassen nicht nur mehr Freiraum (mehr Freiraum ist nicht schlecht, man muss ein bisschen mehr organisieren) -wo Chaos entstehen kann (nicht muss)- nein, das Problem ist, dass manchmal postuliert wird, das Chaos kreativ macht, produktiv ist.
Das mag für einzelnen Menschen vielleicht zutreffen, -obgleich nur unter sehr begrenzten Bedingungen- in den meisten Fällen jedoch (meiner Meinung nach) ist das eine Ausrede, um Schlampigkeit gut zu heißen.
Bei Teams dürfte die "Produktivität" unter chaotischen Umgebungen sehr, sehr rar sein... wenn sie überhaupt vorkommt, und wenn sie vorkommt, nur für eine ganz kurze Zeit.

Lösung

An der Lösung wird gearbeitet.

Ich wollte heute nur einige Gedanken zur Dekonstruktion des Mythos des "Kreativen Chaos" beitragen.

Und wie gefährlich diesen Mythos für die Qualität ist, die ein Kunde erhält.




Leser: Habt Ihr Kommentare?

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.