Post-Agile... ein Begriff von Kritekern des "Agilismus"...

Einige Seiten, die sich mit "Post-Agile" auseinandersetzen:

Interessanter Vergleich klassisch-agile mit vielen Anmerkungen:
https://www.artefactgroup.com/articles/post-agile-a-design-thinking-approach-to-software-development/

Startseite des Blogs:
https://postagilist.wordpress.com/

"Scrum" als magisches Werkzeug:
https://postagilist.wordpress.com/2011/04/05/the-flawed-rhetoric-about-scrum-and-organizational-dysfunction/




"Agile" als kommunistisches Regime:
https://postagilist.wordpress.com/2011/04/09/scrum-as-the-new-command-and-control/

Interessant, viele Punkte, die ich selber schon bemängelt habe, hier:
http://www.ruynk.com/downl/SW_Entwicklung_Untersuchung.pdf

Zwei Kommentare zu zwei bei den "Agilen" verwendeten Begriffen

Zunächst möchte ich auf einen Vergleich verweisen:

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

Hier geht es um eine Untersuchung über die verschiedenen agilen Methoden (es wurden 26 verschiedene Methoden bewertet und aufgrund dieser Bewertung habe ich den Vergleich durchgeführt). Wobei ich muss schon sagen; das Ergebnis fiel mehr oder minder wie erwartet. Dennoch interessant.

Doch eigentlich wollte ich auf auf 2 Begriffe eingehen.

1. Kanban

Ich wundere mich immer wieder wenn Menschen (insbesondere Leute der IT Branche, die es eigentlich besser wissen sollten) meinen, Kanban wäre eine agile Entwicklungsmethode.
Ich weiß leider nicht wie "lazy" die Kollegen mit den Wörter umgehen, aber Kanban ist keine Entwicklungsmethode:
KanBan ist ein Tool (Werkzeug) zum Visualisieren der Arbeitspaketen!
Nicht mehr und nicht weniger.
Oder sind Sie, werter Leser, über "Kanban" eine andere Auffassung?

2. Scrum

Mein Lieblings Punchingball: Das Gedränge    :-)
Scrum ist meiner Meinung nach ein Sammelsurium an Praktiken, keine Methode. Natürlich lässt sich schon streiten, in wie weit Scrum eine Methode ist.
 Wikipedia ("https://de.wikipedia.org/wiki/Methode_(Softwaretechnik)") liefert uns folgende Definition:
"Als Methode – „wörtliche Bedeutung: Der Weg zu etwas“ (Duden) – bezeichnet man in der Informatik und der Softwaretechnik eine „systematische zielgerichtete Vorgehensweise, sowie planmäßiges Verfahren, welches für eine Vielzahl von Problemen zu einer sinnvollen Lösung führt“ und/oder „eingeübte oder formalisierte Abläufe, die sich als zweckmäßig und erfolgreich erwiesen haben
Die 1. Definition trifft für Scrum nicht zu, denn Scrum ist nicht "planmäßig" (Klar! Scrum - und die "Agilen" im Allgemeinen - wollen keine Planung). Und ich halte Scrum auch nicht für "systematisch" - es ist dahinter kein System zu erkennen.
Die 2. Definition könnte schon  gelten, dies liegt daran, dass die Definition zu ungenau ist: "... als zweckmäßig und erfolgreich erwiesen haben" - ja... wie weit zweckmäßig und wie genau erfolgreich?
Aber jetzt will ich es kurz machen, abgesehen von allen Erklärungen, Methode ist "der Weg zu etwas" und das reicht mir und ist genau genug für mein Geschmack;
Scrum ist nicht der Weg zu etwas, sondern lediglich ein loser Haufen an mehr oder minder brauchbaren Praktiken. Einen "Weg" stellen sie nicht dar.

Auch hier bin ich an Kommentare über die Methode-Eigenschaften des Scrums gespannt: Meinungen...?

Bis bald
ruynk

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.