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.