Freitag, 27. Oktober 2017

Gedankenfehler im Ansatz bei den Agilen - Teil 3 von 3

Von:
https://de.wikipedia.org/wiki/Agile_Softwareentwicklung

Hier:
Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung

Das ist noch ein Meeting.

Die Idee dahinter ist wie immer eine gute Idee, stammt eigentlich von dem Toyota Production System und wird "Hansei" genannt. Hansei ist viel mehr als einfach eine Selbstreflexion; Hansei ist das Anstreben einer totalen Ehrlichkeit bezüglich der eigenen Schwächen; es geht darum, diese Schwächen auszumerzen.

Das ist was ganz anders als das, was man bei den "Agilen" vorfindet.

Bei den Retrospektiven, so wie sie normalerweise ausgeübt werden, werden Spielchen gespielt (so offensichtlich mit dem Ziel, die Leuten zu unterhalten, als wären sie im Kindergarten), bestenfalls werden hier ansatzweise wunde Punkte angesprochen, wobei meistens ohne jegliche Kommentare (Schweigen im Walde) oder gar Konsequenzen (wer sich bewegt hat verloren, m.a.W. wer zugibt, dass tatsächlich Probleme existieren - Postbote schlechter Nachrichten - wird [symbolisch] exekutiert); Keiner wagt "unangenehm" auf zu fallen oder mehr als nur dezent (leichte) Probleme anzusprechen.
Somit ist der ganze Sinn und Zweck einer solchen Retrospektive für die Katz.

Dazu kommt, dass diese Retrospektiven als fester Bestandteil eines Sprints betrachtet und handhabt werden, dergestalt, dass sie als notwendige Zeremonie angesehen werden, ...und die normalen Mitglieder eines Teams lassen das Ganze - geduldig - über sich ergehen. Sie wissen doch, dass es sich um (noch) eine Zeremonie ohne Folgen handelt.

Der Leitgedanke hinter dieser Retrospektive ist, wie fast alles, was aus der Toyota kommt, richtig und wichtig.
Leider, wie bei so vielen positiven Ideen, bei den Agilen ins Gegenteil umgewandelt.

Man soll berücksichtigen, dass die "agilen" als Antwort auf die Probleme der klassischen Methoden entstanden sind und ein gewichtiges Teil dieser Problemen ist nun mal ein unfähiges Management (daher so viele Meetings, um das Management zu ersetzen), leider und aus Gründen die mir unbegreiflich sind, werden alle gute Ideen, die die Agilisten anfassen, zu unnützlichen, hemmenden Brocken, die am Halse der Projektmitarbeiter hängen und ihr Handeln zu lahmen drohen.

Montag, 23. Oktober 2017

Gedankenfehler im Ansatz bei den Agilen - Teil 2 von 3

Hier:

2. The team is authorised to take decisions (Das Team hat die Befugnis, Entscheidungen zu treffen).

Within a cycle, the project team must be authorised to do what they think is best. If
the project team does not have this power, the cyclical model of project management will not work.
(Im Laufe eines Zyklus muss das Team die Befugnis haben, das zu tun, was sie als das Beste erachten.
Sollte das Team diese Erlaubnis nicht haben, so wird das zyklische Modell des Projekt Managements nicht funktionieren
).

Das ist noch so eine Idee, die in Teile richtig ist aber dadurch, das sie nicht zu Ende gedacht ist, nicht wirklich dienlich (zweckdienlich) ist.
Die Leute, die Ahnung haben, sollen Entscheidungen treffen können.
Menschen müssen die Macht haben, Fehler anzusprechen und Probleme bekannt zu geben, doch nicht jeder muss sich die Freiheit nehmen, irgendetwas zu ändern nur weil es ihm so besser gefällt, ohne zu wissen was er genau macht.
Das mündet doch in der Verantwortungslosigkeit, wenn alle Fehler machen dürfen und keiner muss für Fehler gerade stehen.

Darüber hinaus sind die Teams - aus der Sicht der Agilisten gesehen - überbewertet. Die Agilisten scheinen zu glauben, dass alles durch die Selbststeuerungsfunktion eines Team geheilt und in die richtige Bahn gebracht werden kann. Das ist: Überbewertung.

Die Aussage "[...] Team diese Erlaubnis nicht haben, so wird das zyklische Modell des Projekt Managements nicht funktionieren" ist auch nicht richtig: ein zyklisches Modell ist unabhängig von 1. Teams und 2. von den Befugnissen des Teams.

Man soll jedoch nicht vergessen, dass die "agilen" als Antwort auf die Probleme der klassischen Methoden entstanden sind, wo Teams eigentlich einzelne Mitarbeiter waren, mehr oder minder isoliert von dem Rest der Mitarbeiter gearbeitet und von dem Management als "Ressource" betrachtet wurden. Daher ist dieses (agile) Umdenken, wenn auch radikal, schon gewissermaßen gerechtfertigt.

Das "Richtige" ist es aber noch nicht...

Mittwoch, 18. Oktober 2017

Gedankenfehler im Ansatz bei den Agilen - Teil 1 von 3

Hier:

1. Users/customers are actively involved (Benutzer und Kunden nehmen aktiv im Entwicklungsprozess teil).

Das bringt nicht wirklich viel und es macht für den Kunden überhaupt keinen Sinn, ständig bei dem Lieferanten antanzen zu müssen. Die Idee ist gut, die Implementierung ist mangelhaft (bisweilen eine Katastrophe).

In der Praxis sieht das so aus, dass der "Kunde" einmal pro Sprint (oder so; nicht "täglich", das ist Nonsense) bei dem Auftragnehmer erscheint, ihm wird das vorgeführt, was funktioniert, der "Kunde" sagt; 'hübsch hübsch!' und geht wieder.
Eigentlich ein Zeitverlust für alle, das Schlimmste aber ist es, dass es für den AG keine wirkliche Verpflichtung gibt, sich mit dem Entwicklungsstand auseinander zu setzen.
Aussagen sind mündlich und somit nicht bindend.
Die Einstellung des AG ist in Allgemeinen so, dass er sowieso vom AN erwartet, dass die SW erstellt wird; seine Anwesenheit ist eine zu "leichte" Sache; er testet nicht, lässt sich lediglich die SW vorführen.
Es gibt natürlich Firmen, wo das etwas anders abläuft.

Also...
Vorteile:
  • Der Kunde gibt Rückmeldung (Wichtig).
  • Die Entwickler könnten einen Eindruck erhalten, wie der Benutzer mit der SW umgeht (Wichtig!) - wenn es einigermaßen gut durchgeführt wäre... eher seltener als die Ausnahme -.

Nachteile:
  • Zeitverlust für die Teilnehmer die an Meetings teil nehmen, die nichts zu melden haben
  • Zeitverlust für den Kunden, denn oft fahren mehrere Personen zum AN und verschenken die eigene Zeit, sowohl in Meetings als auch bei den Fahrten - ohne konkretes Ergebnis (nichts spezifiziert => kein Ergebnis) -.
  • Dass der Kunde vor Ort ist garantiert in keiner Weise, dass die SW fehlerfrei ist.
  • Kommunikationsschwierigkeiten können auftreten, die Möglichkeit und Einfluss von Missverständnissen erhöht sich durch die eher nicht strukturierte Vorgehensweise - im Gegensatz zu dem, was postuliert wird -.

Scheint mir so eine wischi-waschi Lösung zu sein für das Problem "Anforderungsmanagement" zu sein, welche mittels einer Art "Meeting" eine Pseudo-Lösung herbeizuführen wünscht.



Und überhaupt; sieht ganz so aus, als würden die "Agilen" versuchen, alle Schwierigkeiten mittels Meetings zu lösen.

Man soll immer bedenken, dass die "agilen" als Antwort auf die Probleme der klassischen Methoden entstanden sind. Das heißt nicht, dass sie nicht ihre eigene Probleme herbeiführen und auch nicht, dass die Lösung auch eine ist.


Samstag, 30. September 2017

Das "agile Manifesto": Ein Manifesto der Frust?

"Agil" sollte eigentlich bedeuten, dass man die SW-Entwicklung an die Menschen anpasst (Manifesto!). Leider ist wieder mal das Gegenteil von dem geschehen, was man sich vollmundig versprochen hat: Die Menschen werden in Wirklichkeit an einem (nunmehr "agil" genannten) Prozess (stark bis sehr stark) angepasst.

Eine Entwicklungsmethode muss mit den Menschen, die man hat, klar kommen.

"Nehmen Sie die Menschen, wie sie sind, andere gibt es nicht", so hat ein Politiker, Konrad Adenauer, mal gesagt.

Sowohl die klassischen Methoden als auch die sogenannten "agilen" (insbesondere Scrum - das Gedränge) wollen die Menschen an einem Prozess anpassen. Vielleicht soll man sich Gedanken machen, ob dieses "Wollen" nicht in Wirklichkeit ein "Sollen" sein soll: Ist es nicht so, dass ein Prozess gegeben sein muss, um eine bestimmte Arbeitsleistung zu erbringen?

Wenn dem so ist, so brauchen wir tatsächlich einen Rahmen (Methode), der uns ein Prozess definiert, wo aber die Mitarbeiter sich so weit entfalten können wie möglich. Das ist weder mit den klassischen noch mit den sogenannten "agilen" der Fall.

Auch "KanBan" [das "agile" KanBan, hat mit dem wirklichen (Toyota-) KanBan wenig zu tun] will die Menschen an einem bestimmten Prozess angepasst haben.

Das kann funktionieren, muss aber nicht, und auf jeden Fall funktionieren solche Methoden dann "suboptimal":
Klassische Methoden haben den Manko, dass sie ziemlich starr sind und die Mitarbeiter die Freiheit nicht haben, seine Arbeit zu verbessern (Stichwort Kaizen).

Die sogenannten "agilen" Methoden auf der anderen Seite haben aber den Manko, dass sie eine falsche Freiheit versprechen. Dies hat wahrscheinlich seinen Ursprung in der Tatsache, dass normale (schlichte) Entwickler das "Manifesto" geschrieben haben.

Siehe meine Homepage und die alten Blogeinträge:
- http://www.ruynk.com/ruynk_agilismus_analyse.htm
- http://ruynk.blogspot.de/2015/03/wie-agil-ist-eigentlich-agil-was-kann.html
- http://ruynk.blogspot.de/2015/05/agile-prinzipien-schwammig-schwach-lahm.html
 
Das "Manifesto" wurde aller Anschein nach aus Frust geschrieben (die "klassische" SW-Entwicklung kann ser frustrierend sein!) und mangelt sowohl an wissenschaftlicher Stringenz als auch an der notwendigen Flexibilität um es an die wirklichen Gegebenheiten in den Firmen anzupassen.

Zwar wird behauptet, dass die "agilen" Teams die "agilen" Methoden anpassen können und sollen, doch... das ist zu viel der Freiheit; der "falschen" Freiheit (Stichwörter: Chaos, Willkür, Unverantwortlichkeit, Dogmatismus u.a.).

Eine echte Lösung muss versuchen, die Menschen (MA) jeder für sich optimal einzusetzen.  FlePA verfolgt diesen Ansatz.

Dienstag, 20. Juni 2017

Über die magische Entstehung von "Agilität" durch den Einsatz von Tools

In der "agilen" Welt, so wie ich sie in den letzten Jahren bewundern durfte, ist einen lustigen Ansatz zu beobachten:
Erstens: Es existieren eine Serie an Tools, die "agil" sind und diese Agilität auch gewährleisten sollen, darunter z.B. "Jira"; den Einsatz solchen Tools wird nun erzwungen.
Zweitens: Es existieren eine Serie an Praktiken, die "agil" sind und diese Agilität auch gewährleisten sollen, darunter z.B. "CI/CD" (Continuous Integration / Continuous Deployment); den Einsatz solchen Praktiken wird nun erzwungen.

Der Ansatz wird wohl in der Hoffnung oder dem Glaube verfolgt, dass lediglich eine geistlose Anwendung einer Mechanik ausreichend ist um ein Ergebnis herbeizuzaubern.

Das ist ein Glaube an einer (einfachen) mechanischen Kausalität.

Doch wir haben es eigentlich hier mit sehr komplexen Interaktionen in einem sozialen Gebilde (kein "System" sondern eher ein "Organismus") zu tun. Hieraus erklärt sich der Denkansatz der überwältigen Wichtigkeit des "Teams" als solches: Deshalb schwafelt man gerne von den sich selbst organisierenden Teams und dass das Ergebnis mehr sein soll als den Beitrag jeden einzelnen usw.

Nun, es sieht so aus, als würden die sogenannten "agilen" Methoden erwarten, dass durch die mechanische Anwendung bestimmter Rituale (Praktiken) und Tools ein organisiertes (organisches) Team entstehen soll: Das kann (könnte) passieren, muss aber nicht. Und wenn Jemand erwartet dass etwas passiert, was passieren "könnte", pflegt diese Person eigentlich nichts anderes als "Wunschdenken".

Nehmen wir z.B. CI/CD als Untersuchungsobjekt:

CI/CD scheint eine Technik zu sein, die in Zusammenhang mit den sogenannten "agilen" Firmen mehr und mehr eingesetzt wird.

Dazu möchte ich auf 2 Punkten aufmerksam machen, die mir bei der Arbeit in den letzten Jahren aufgefallen ist.

1) CI/CD ist eine Technik die eigentlich für Projekte weniger bis gar nicht anwendbar ist: Viele 'Manager' wollen sie jedoch haben, weil sie scheinbar "agil" ist. Doch eigentlich sollte sie nur für die Serienproduktion einzusetzen sein. Die Idee stammt doch von der Toyota Serienautoproduktion. Als solche erzeugt sie bei der Projektarbeit eine schwer zu beherrschenden Overhead-Verwaltung. Vor Allem im Zusammenhang mit den ach so wichtigen automatischen Tests (mehr dazu lesen Sie hier: http://www.ruynk.com/ruynk_irrlicht_agil.htm - unter "Negative Eigenschaften der agilen Methoden" den letzten Punkt, über automatische Tests).

2) Bei vielen Firmen, die sich "agil" benennen wollen, werden Tools zur CI/CD eingeführt und eingesetzt, ohne wirklich verstanden zu haben, was CI/CD bedeutet. Und was bedeutet CI/CD? Die Idee hinter CI/CD ist wohl, das man ständig Änderungen und Verbesserungen (quasi in einem immerwährenden Prozess) im fertigen "Produkt" einfließen lassen kann.

Ich denke, dass man als erstes das Prozess so anpassen und optimieren soll, dass eine CI bzw CD Sinn macht. Das wird selten gemacht: Das wäre doch eher die Arbeit von Analysten, doch Analysten werden von den Firmen nicht mehr nachgefragt.

Davor jedoch sollte man sich Gedanken machen, was für einen Sinn CI/CD hat, sowohl für die Entwickler als auch für den Kunden. Solche Überlegungen werden auch (sehr) selten, manchmal gar nicht durchgeführt.

Vielleicht hofft das 'Management', dass CI/CD sich beim bloßen Anwenden von Tools einstellt.

Vielleicht hofft das 'Management', dass die "Agilität" sich beim bloßen Anwenden von Tools (und Praktiken) einstellt.

Das wird selten vorkommen. Das ist Wunschdenken.

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

Neue Homepage für "AMTRS"

Neue Homepage für "AMTRS" (Analysieren - Modellieren - Trainieren - Reorganisieren - Systematisieren)

Hier: http://www.amtrs.de

Die Seite über "Systemanalyse" ist wert zu lesen, und
Downloads sind interessant!

Neue Homepage für "RyuSui"

Neue Homepage für "RyuSui" (IT-Wissen; Kurse und Seminare)

Hier: http://www.ryusui.de

Einige der Downloads sind interessant, aber nicht nur!


Donnerstag, 25. Mai 2017

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

Donnerstag, 6. April 2017

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.

Mittwoch, 15. März 2017

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.


Samstag, 11. März 2017

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.

Mittwoch, 8. März 2017

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.


Montag, 6. März 2017

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.

Freitag, 6. Januar 2017

'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).